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

[Martin Thomson <[e-mail]>]

Finally getting^Wmaking some time for this.

On 8 June 2015 at 18:15, Mark Nottingham <[e-mail]> 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