Re: Stephen Farrell's Discuss on draft-ietf-httpbis-tunnel-protocol-04: (with DISCUSS and COMMENT)

On 10/06/2015 9:09 a.m., Martin Thomson wrote:
> Finally getting^Wmaking some time for this.
> 
> On 8 June 2015 at 18:15, Mark Nottingham <mnot@mnot.net> wrote:
>>> Care must be taken when such identifiers may leak personally
>>> identifiable information, or when such leakage may lead to
>>> profiling or to leaking of sensitive information.  If any of
>>> these apply to this new protocol identifier, the identifier
>>> SHOULD NOT be used in TLS configurations where it would be
>>> visible in the clear, and documents specifying such protocol
>>> identifiers SHOULD recommend against such unsafe use.
>>>
>>> That last sentence seems to imply that you ought replicate such
>>> guidance here.
>>
>> Seems reasonable to me.
> 
> Likewise.  https://github.com/httpwg/http-extensions/commit/6c7b987
> 
>>> - I can see situations where I might want to not tell the proxy
>>> what protocol I'll be using inside TLS and when TLS1.3 hides
>>> ALPM from the proxy (I hope:-) then could there be value
>>> registering a "I'm not telling" ALPN value so that a UA
>>> wouldn't have to lie to the proxy?
>>
>> Or the UA could omit the header, or the UA could send the header with no value.
> 
> I think those are better options.  Do you think we need to say that
> with the other agreed changes already in place?
> 
>>> - I think you ought say what you expect a proxy to do if the
>>> ALPN header field and the ALPN TLS extension value do not match
>>> and I think that ought say that a CONNECT recipient in such
>>> cases SHOULD NOT drop the connection solely on that basis.  If
>>> they have some policy about it fine, but they shouldn't barf
>>> just because there's a different order or spelling or just a
>>> different value.
>>
>> Seems reasonable to me.
> 
> I'll roll that into the point below.
> 
>>> - Replicating values at multiple protocol layers produces a
>>> common failure mode where code only uses one copy to do access
>>> control or authorization or where two nodes in sequence use
>>> different copies, with unexpected behaviour resulting. I think
>>> you should call that out in the security considerations section
>>> as it keeps happening.
>>
>> Again, seems reasonable.
>>
>> I wonder if it would be helpful to explicitly motivate it — i.e., say this header is there to make the information available at the HTTP layer during CONNECT, so that the server can refuse the connection gracefully if they like (e.g., with a 403); without it, the server would have to sniff ALPN in the tunnel and then close the connection rudely.
> 
> I think that we're going to need some review on this change.
> 
> https://github.com/httpwg/http-extensions/commit/a62c60a
> 

Recall the long discussion for March WGLC on this documents -02.

That discussions made it clear that:
a) this header value was *not* intended to describe the full protocol
stack - only an undefined number (1..N) protocol(s) at the top of it.
b) TLS was mandatory - except when it wasn't used. (WTF!)
c) some values describe whole stacks, some only the leaf protocol.

Consider the (multiple) cases of ALPN "http/1.1" - TLS or not?. Which we
went over exhaustively earlier.

When a proxy MUST inspect the packets in order to understand what the
header contains it becomes a waste of bytes. We just go with sniffing.
Its way simpler.


I stepped out of the discussions on this document when that point became
clear. If the header *did* describe the whole protocol stack, it would
be wonderful and I'm back in again trying to add support to Squid.
Otherwise its just a waste of time for me.


Amos

Received on Wednesday, 10 June 2015 00:17:32 UTC