- From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
- Date: Tue, 09 Jun 2015 11:17:26 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: httpbis-chairs@ietf.org, draft-ietf-httpbis-tunnel-protocol.shepherd@ietf.org, draft-ietf-httpbis-tunnel-protocol.ad@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-httpbis-tunnel-protocol@ietf.org, ietf-http-wg@w3.org
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 >> <stephen.farrell@cs.tcd.ie> 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/ >
Received on Tuesday, 9 June 2015 10:18:14 UTC