- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Wed, 02 Mar 2016 17:03:08 +0000
- To: HTTP WG <ietf-http-wg@w3.org>, Mark Nottingham <mnot@mnot.net>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
| 3. Server Authentication | | [I-D.ietf-httpbis-alt-svc] Section 2.1requires that an alternative | service only be used when there are "reasonable assurances" that it is | under control of and valid for the whole origin | | For the purposes of this specification, there are two ways to achieve | this: | | • Using TLS with a certificate that validates as per [RFC2818], or | • Confirming that both the origin and the alternative service support | this specification by obtaining a 200 (OK) response for the "http-tls" | well-known URI (section X). | | The latter approach allows deployment without the use of valid | certificates, to encourage deployment of opportunistic security. | Therefore, in these cases the alternative service can provide any | certificate, or even select TLS cipher suites that do not include | authentication. 1) This seems not specify that alternative is same host than origin in case when valid certificate is not required There fore "http-tls" well-known URI on _alternative_ must include origin -name (method, host, port) 2) If origin does not filter Alt-Svc: -headers, http://origin/~attacker/ skript can still produce Alt-Svc: h2=":8000" and if origin runs it own real alternative on port 81 then it will have "http-tls" well-known URI There fore "http-tls" well-known URI on _origin_ must include alternative (host and port). Because it is alternative "http-tls" well-known URI on _origin_ and _alternative_ must be same. Therefore "http-tls" well-known URI must include origin -name and alternative (host and port). Now comments about format of "http-tls" well-known URI except that it should be something what can not be silently truncated. / Kari Hurtta
Received on Wednesday, 2 March 2016 21:36:15 UTC