- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Wed, 10 Feb 2016 04:38:25 +0000
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, HTTP WG <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>, "Julian F. Reschke" <julian.reschke@greenbytes.de>
Mark Nottingham <mnot@mnot.net>: (Wed Feb 10 05:31:11 2016) > Hi Kari, > > I think Barry is about to start IETF LC on this, so if that happens, we'll just consider this LC feedback. I see. > It's a fair point. This is difficult to specify; one way we could do it is to specify the way we know here (using HTTPS with a strong cert), and require other ways to update this specification (with an Updates: field on the Standards Track). > > What do others think? > https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1 | However, if "other.example.com" is | offered with the "h2c" protocol, the client cannot use it, because | there is no mechanism in that protocol to establish the relationship | between the origin and the alternative. => | However, if "other.example.com" | (or "www.example.com" on another port) is offered with the "h2c" protocol, | the client cannot use it, because there is no mechanism in that protocol | to establish the relationship between the origin and the alternative. I think that this addition gives enough hint about that. And probably drop "h2c" examples or add note (to near of examples): | "h2c" protocol on example assumes that "reasonable assurance" (Section 2.1) | is established elsewhere. Or something like that. / Kari Hurtta >> On 10 Feb 2016, at 5:28 am, Kari Hurtta <hurtta-ietf@elmme-mailer.org> wrote: >> >> >> Tricky >> >> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1 >> >> | 2.1. Host Authentication >> | >> | >> | Clients MUST have reasonable assurances that the alternative service >> | is under control of and valid for the whole origin. >> >> I have impression that on absence of other protocol, this is mean to >> forbid use plain HTTP/2 (ie "h2c"), because there is no "reasonable >> assurance". >> >> But is reader understanding that? There is examples which use "h2c". >> >> This does not give that >> >> | However, if "other.example.com" is >> | offered with the "h2c" protocol, the client cannot use it, because >> | there is no mechanism in that protocol to establish the relationship >> | between the origin and the alternative. >> >> Reader may think that there is "reasonable assurance" when hostname >> is same. >> >> There is >> >> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-9.1 >> >> | 9.1. Changing Ports >> | >> | >> | Using an alternative service implies accessing an origin's resources >> | on an alternative port, at a minimum. An attacker that can inject >> | alternative services and listen at the advertised port is therefore >> | able to hijack an origin. On certain servers, it is normal for users >> | to be able to control some personal pages available on a shared port, >> | and also to accept to requests on less-privileged ports. >> >> But that part is confusing: >> >> | This risk is mitigated by the requirements in Section 2.1. >> >> When requirement is "reasonable assurance" I think that reader >> is confused. >> >> "h2c" examples are >> >> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-3 >> >> | The Alt-Svc field value can have multiple values: >> | >> | Alt-Svc: h2c=":8000", h2=":443" >> >> >> https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-3.1 >> >> >> | HTTP/1.1 200 OK >> | Content-Type: text/html >> | Cache-Control: max-age=600 >> | Age: 30 >> | Alt-Svc: h2c=":8000"; ma=60 >> >> >> So my question is: Can reader understand this without >> reading https://lists.w3.org/Archives/Public/ietf-http-wg/ ? >> >> ( Or without reading that other protocol RFC which >> gives reasonable assurance. ) >> >> / Kari Hurtta >> > > -- > Mark Nottingham https://www.mnot.net/ >
Received on Wednesday, 10 February 2016 20:17:01 UTC