Re: New tunnel protocol

On 25 January 2015 at 11:14, Adrien de Croy <adrien@qbik.com> wrote:

> You will need to make sure all the variants are registered as ALPN ids
> though as well,  such as
>
> pop3 and pop3s, smtp and smtps, imap etc etc

Yep.

> these will all have different meanings in a TLS APLN option vs the
> Tunnel-Protocol field (as they will have 1 layer of TLS difference).  In
> some protocols, such as ftp, there's already a lot of confusion (e.g.
> difference between ftps and sftp), I see this requirement adding to that.

Maybe it will actually help resolve the issues with FTP by identifying
the different variants properly.

> Might just it not be easier to be able to separately specify the TLS layer,
> and allow then the T-P header to exactly match the ALPN in the TLS
> handshake?  Some proxies definitely will want to check if the client lied
> about it.

If you need a generic ability to identify TLS, looking at the TLS
ClientHello is probably the best you can do.  After all, you have to
account for clients that lie, clients that omit the header field, and
all sorts of abuse.

It's definitely possible to create a different design, a more complex
design even.  But it's not clear that there are any use cases that
would significantly benefit from that.  Critically, if you want to do
something based on the selected protocol, I don't see how you can
avoid knowing about what you are permitting.

On 25 January 2015 at 13:14, Adrien de Croy <adrien@qbik.com> wrote:
> One more thought on this. A proxy wanting to do cert verification on TLS needs to know if the next layer is TLS.

That won't work in TLS 1.3, if that is the use case you have in mind.

Received on Tuesday, 27 January 2015 00:11:54 UTC