Re: New tunnel protocol

------ Original Message ------
From: "Martin Thomson" <martin.thomson@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "Amos Jeffries" <squid3@treenet.co.nz>; "HTTP Working Group" 
<ietf-http-wg@w3.org>
Sent: 27/01/2015 1:11:27 p.m.
Subject: 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.
What I would rather do (at least at this stage) is initially trust the 
client's assertion, and break in other ways if they lied, e.g. if they 
say SMTP then pass it to SMTP analyzer, and if it happened to be 
something else, then the SMTP analyzer will complain that it's not SMTP.

Also if you rely on an ALPN id for something, then you can't arbitrarily 
put some new protocol over TLS without getting a new ALPN registered for 
the -s version.

I still think this way will cause confusion, and something rather like

Tunnel-Protocol: TLS; subsequent-layer=SMTP

Would be more deterministic.  Then you could do something like

Tunnel-Protocol: TLS, subsequent-layer=spop3

For the pathological case where you're tunnelling a secured protocol 
over an additional TLS tunnel. I don't know how you'd describe this in 
your draft, except by requiring people to get new ALPN ids registered 
for pop3 over TLS over TLS.

I think it's really useful for a client to advertise what it intends to 
use a tunnel for, so a proxy can evaluate some policy on that. I think 
we will have a need also for a proxy to respond that the tunneled 
protocol is not acceptable (so some new status codes for this), and also 
maybe to be able to advertise allowed protocols.

Cheers

Adrien


>
>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 01:03:50 UTC