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

Re: Working Group Last Call: draft-ietf-httpbis-http2-encryption-04

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 31 Mar 2016 08:54:33 +0200
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP WG <ietf-http-wg@w3.org>, Mike Bishop <Michael.Bishop@microsoft.com>
Message-ID: <56FCC9A9.1020603@gmx.de>
On 2016-03-31 02:42, Martin Thomson wrote:
> Thanks Julian,
> You can find this all on
> https://github.com/httpwg/http-extensions/pull/164.  Feel free to

Thanks, and...

> merge if you are happy and we can continue with the remaining changes.


> ...
>> 8.4.  Confusion Regarding Request Scheme
>> This section looks a bit unstructured. Paragraph 3 seems to restate what
>> Paragraph 1 already says.
>> Paragraph 2 IMHO needs to be clearer: it refers to the protocol used to
>> perform the opp-sec-ed request, not the original one, right? FWIW, I still
>> think that the reasoning for this is weak (an HTTP/2 server stack might
>> suffer from the same problem), and thus should either be relaxed, or better
>> explained.
> I've restructured this and explained the distinction between discovery
> and use a little better, but I'm not going to change the fundamentals
> here.  We've gone over that point a fair number of times already and I
> thought that we had reach some sort of pseudo-acceptable (if weak)
> compromise position on it.
> ...

With the latest changes, this now reads:

"Some HTTP/1.1 implementations use ambient signals to determine if a 
request is for an https resource. For example, implementations might 
look for TLS on the stack or a port number of 443. This is necessary in 
many cases because the most common form of an HTTP/1.1 request does not 
carry an explicit indication of the URI scheme. An implementation that 
is serving an opportunistically secured request SHOULD suppress these 
signals for http resources.

HTTP/1.1 MUST NOT be used to serve opportunistically secured requests. 
HTTP/1.1 can be used to discover an opportunistically secured 
alternative service."

The problem remains that this is not really specific to HTTP/1.1; for 
instance, code running inside Apache over HTTP/2 may have exactly the 
same problem (Stefan E. to confirm); so it's more a matter of HTTP 
server internal APIs, not the on-the-wire protocol.

I believe this needs to be rephrased to better explain the actual 
problem; and I also remain unconvinced that the conclusion wrt HTTP/1.1 
makes sense.

Best regards, Julian
Received on Thursday, 31 March 2016 06:55:09 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 31 March 2016 06:55:13 UTC