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

[Mark Nottingham <[e-mail]>]

Hi Stephen,

> On 8 Jun 2015, at 11:01 pm, Stephen Farrell <[e-mail]> wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> I think this should be an easy discuss but is needed.  RFC 7301
> says:
> 
> 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.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - 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 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. 


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

Cheers,


--
Mark Nottingham   https://www.mnot.net/