W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: draft-ietf-httpbis-alt-svc-12.txt

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 10 Feb 2016 14:31:11 +1100
Cc: HTTP WG <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>, "Julian F. Reschke" <julian.reschke@greenbytes.de>
Message-Id: <B7164F24-DDA1-4753-8A8B-04809B1965FF@mnot.net>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Hi Kari,

I think Barry is about to start IETF LC on this, so if that happens, we'll just consider this LC feedback.

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?



> 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 03:31:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC