- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 27 Jan 2015 10:12:54 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jan 27, 2015 at 09:01:13AM +0000, Adrien de Croy wrote: > > Willy - I think the intention is that this is used whether or not there > is TLS in play, but that the ALPN token used in Tunnel-Protocol wouldn't > match what is in the ALPN in any tunneled TLS (if any). > > E.g. if tunneling SMTP over TLS, you'd advertise smtps in the > Tunnel-Protocol header, and smtp in the ALPN field in the client helo in > TLS. > > If tunneling SMTP, you'd just advertise smtp in the Tunnel-Protocol > header. So it's using the Tunnel-Protocol to describe possibly several > layers. But the issue then is that it requires that ALPN entries exist for protocols that are normally not transported over TLS, thus adding a lot of confusion (eg: openvpn, tls, etc). > I personally would prefer to separate it out so that a proxy can know > the next layer is TLS regardless of what is transported over TLS. I agree, but I respect Martin's wish as well, hence why I was proposing to only advertise ALPN instead. I mean, if the ALPN header would match the ALPN in TLS, it's still possible for clients to announce what they're expecting to use and for proxies to enforce validation. The presence of the ALPN header field would imply that TLS is being used. Just as much as I would love to see something to advertise any protocol in the tunnel regardless of TLS being used or not, I can understand it doesn't completely address Martin's needs. What would be nice would be to ensure that everything is properly addressed at least in a way that leaves room for future improvements. Willy
Received on Tuesday, 27 January 2015 09:13:27 UTC