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

[Barry Leiba <[e-mail]>]

OK... the telechat is over, and Martin has some updates queued.
Martin, please post the updates, let's wait for Stephen to get back
home and review them (that might take until the end of the month), and
in the meantime let's make sure the httpbis working group is OK with
the changes.

Barry, ART Director

On Tue, Jun 9, 2015 at 10:09 PM, Martin Thomson
<[e-mail]> wrote:
> 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
>