W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: New tunnel protocol

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>
Message-ID: <20150127091254.GA8765@1wt.eu>
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.

Received on Tuesday, 27 January 2015 09:13:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC