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

[Stephen Farrell <[e-mail]>]

Hi Mark,

That's all good from my POV and I like your suggestion at the end.

Cheers,
S.

On 09/06/15 02:15, Mark Nottingham wrote:
> 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/
>