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

On 2016-03-31 09:29, Martin Thomson wrote:
> On 31 March 2016 at 17:54, Julian Reschke <julian.reschke@gmx.de> wrote:
>> 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.
>
>
> Maybe I'm a little too close to this now.  I can't see how I might
> rephrase this differently.  Do you have a suggestion?

We need to start with a precise problem description. The spec currently 
says:

"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."

This is IMHO misleading. The problems are:

- the wire protocol might not carry the URI scheme (as is the case with 
the most common HTTP/1.1 form of request targets)

- the API implemented by the HTTP server for the code running inside it 
may not carry the scheme name

- ...and even if it does, the code might not handle it properly (maybe 
because it was written for 1.1 and never updated)

- in absence of a specific scheme indicator, the HTTP server, or the 
modules running inside the server, might make use of ambient signals.

So there are many things that can go wrong, and they are not restricted 
to the use of HTTP/1.1 as wire protocol.

> I also would prefer not to have a carve-out for HTTP/1.1 here.  If you
> want to ask the question again, I look to our chair (and shepherd) for
> guidance.

The WG can of course can decide to rule out HTTP/1.1 for this use case. 
But if it does, the spec should be clear about why that is the case. I 
*believe* the answer is: "because the likelihood that things aren't 
handled properly is higher requests over HTTP/1.1".

On the other hand: if I wanted to opp-sec HTTP/1.1 over port 80 to 
HTTP/1.1 over TLS over port 81, what would be the harm?

Best regards, Julian

Received on Thursday, 31 March 2016 12:54:00 UTC