- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 28 Jan 2015 14:07:03 +1100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Hey Adrien, > On 28 Jan 2015, at 2:02 pm, Adrien de Croy <adrien@qbik.com> wrote: > > Hi Mark > > what sort of policy is it envisioned that this protocol would enable? If a resource allocation policy then it would be prudent surely to not set up a system that people can game by lying? That was discussed a fair bit when this draft was first brought up. I think everyone acknowledges the limits of this approach (and perhaps the draft could do a better job in that). They *very* limited cases where this is useful is in places where the UA inserts the header without any user control, e.g., a WebRTC implementation, and the network wants to do best-effort to QoS or reject those. By their nature, such policy mechanisms are limited. We don't yet have a solution for "the label on these bits are a lie." That doesn't mean that all labels are useless; just that they need to be used with that limitation in mind. > That then requires a proxy to verify the client assertion if it is to make any use of the header at all. So why not design a protocol that allows that, instead of one which abuses: > > a) the excellent design pattern of a layer in a stack identifying the next layer > b) the ALPN identifiers > > and introduces ambiguity which requires traffic sniffing and heuristics to resolve. I'm pretty sure i recall several discussions about sniffing in various contexts on this list and it seems like a bad goal. > > It seems a little ironic to me that all the people raising concerns about this proposal are proxy vendors, who are surely the target audience for this draft, and it seems foolhardy to steadfastly ignore us yet expect this to gain some traction in proxies. > > Train wreck by committee. > > Adrien > > > > ------ Original Message ------ > From: "Mark Nottingham" <mnot@mnot.net> > To: "Amos Jeffries" <squid3@treenet.co.nz> > Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org> > Sent: 28/01/2015 3:35:48 p.m. > Subject: Re: New tunnel protocol > >> Hi Amos et al, >> >> Personally, I generally agree much of your concern here -- the ad hoc way in which ALPN identifiers sprung up always made me nervous (and I've expressed that a few times). It would be nicer if there were (dare I say it) a more well-defined architecture around ALPN-as-protocol-identifier. >> >> HOWEVER, in this case we're not talking about a negotiation mechanism, nor are we trying to allow intermediaries to parse the contents of the connection. Rather, the purpose of tunnel-protocol is a hint as to the semantics of the application inside the tunnel, so as to enable application of policy. >> >> E.g., if the content is WebRTC, the network might want to apply different QoS, or refuse the tunnel because they're extremely bandwidth-constrained. >> >> For those use cases, it makes no difference (that I can see) as to whether the content is encrypted or not. >> >> What you seem to be asking for is to know whether encryption is going to be used in a tunnel up-front when you see a connection. In the current environment, designing this to allow intermediaries to discriminate against encrypted connections would be unlikely to gain traction, I think. >> >> Cheers, >> >> >>> On 28 Jan 2015, at 10:49 am, Amos Jeffries <squid3@treenet.co.nz> wrote: >>> >>> On 28/01/2015 9:42 a.m., Martin Thomson wrote: >>>> On 27 January 2015 at 11:56, Adrien de Croy wrote: >>>>> therein the problem. Surely if the next protocol after TLS is smtp, then >>>>> you don't advertise smtps in the TLS ALPN???? >>>> >>>> Why? It's not like the TLS magically disappears even if you can decrypt it. >>>> >>>>> Pretty sure captures I've seen >>>>> seen for https, only advertise http inside the ALPN field in the TLS client >>>>> hello message. >>>> >>>> The string "http/1.1" means HTTP/1.1 over TLS. >>>> >>> >>> ... and the ALPN string that means HTTP/1.1 over TCP is also "http/1.1". >>> >>> I need to separately identify these two for a real-world case without >>> reading any bytes following the CONNECT message. How? >>> >>> >>> What I understand is that every other protocol *except* HTTP/2 uses its >>> plain-text protocol label to signal "next protocol" in places like ALPN. >>> So there is no way for any of those protocols to signal the existence of >>> TLS using their regular label. >>> >>> Amos >>> >>> >> >> -- >> Mark Nottingham https://www.mnot.net/ >> >> > -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 28 January 2015 03:07:36 UTC