- From: Willy Tarreau <w@1wt.eu>
- Date: Sun, 25 Jan 2015 19:57:16 +0100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On Sun, Jan 25, 2015 at 09:39:33AM -0800, Martin Thomson wrote: > Thanks for taking a look Willy, and my apologies for not getting this > properly right (I'll explain below). You're welcome. > On 25 January 2015 at 00:06, Willy Tarreau <w@1wt.eu> wrote: > > At first I was quite excited to see something like this but now I'm > > seeing you want to limit its use to TLS only : > > That is certainly not the intent. As "h2c" demonstrates, we're using > ALPN to identify protocols that don't run on TLS. OK, then maybe put ALPN in the header field's name to remove the ambiguity, because there there's nothing that makes it obvious that TLS is in use at all, and the name makes one think it's the protocol being tunnelled which is named instead of the one inside TLS. > The latest editor's draft attempts to address that problem. OK I'll check, thanks. (...) > > I'm not sure about what purpose it provides since if a proxy expects TLS, > > it could already look at ALPN to see the transported protocol. > > Well, part of the intent here is to allow the proxy to bring that > information forward. Then, the only thing that it might want to do is > check that the client wasn't lying. OK. It could indeed be useful if the entity responsible for emitting the header is the one where the policy is configured and differs from the one feeding the TLS stream and from the one verifying the match. > > Thus I'm having two possible suggestions that come to mind : > > - either make this protocol a list of encapsulated layers. That way > > you can say "TLS/1.2, HTTP/1.1" > > As currently used for "h2" and "h2c", ALPN identifies a specific > protocol, with all the layers that it depends on (the whole stack, if > you will). OK but my point was about all the non-TLS protocols I mentionned above. It would be strange to have "h2" indicating that it's h2 over TLS, and "smtp" indicating that it's raw SMTP without TLS. The presence of ALPN implies use of TLS, so for protocols not having to pass through TLS it seems a bit awkward. I'll try to catch up with the rest of the thread as I've noticed that there's already an ongoing discussion about this. Thanks Willy
Received on Sunday, 25 January 2015 18:57:43 UTC