- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 28 Jan 2015 15:40:17 +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>
Adrien, > On 28 Jan 2015, at 2:22 pm, Adrien de Croy <adrien@qbik.com> wrote: > I think it could fulfil these goals, and do a better job at it, if it were possible to verify the client assertion. Requiring sniffing for a TLS client hello is not going to help interop or help authors to make bug-free implementations. Even trying to sniff prior to deciding whether to add a TLS interpreter in the parsing stack is not straightforward when most people use libraries for TLS. So people will have to roll their own TLS packet parsers. That seems like a really bad goal. > > I think we must always consider the applications we haven't thought of yet. And the confusion created by adopting a radically different design pattern to one which is in use at all layers of our stacks. > > I don't have any problem with a client wishing to advertise it is using a protocol as a payload within TLS, and indicating there is a TLS layer there. I have a problem with the ambiguity about whether there is the TLS layer there or not, because this requires sniffing to resolve, and I believe the confusion around it will cause interop problems. At the risk of repeating myself - You seem to be arguing for a use case where the application payload is actually being parsed by an intermediary. That is not the a use case that we've discussed supporting. Again, this is *not* a negotiation mechanism -- so what are the interop problems you're concerned about? Regards, > Adrien > >> >> >>> 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/ -- Mark Nottingham https://www.mnot.net/
Received on Wednesday, 28 January 2015 04:40:50 UTC