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 2:14:46 p.m.
Subject: Re: New tunnel protocol

>On 26 January 2015 at 17:02, Adrien de Croy <adrien@qbik.com> wrote:
>>  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.
>
>Yep, I'd definitely do the same. I'm guessing that anything that
>isn't SMTP won't get very far.
>
>>  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.
>
>Yep. pop3s, then pop3ss, then pop3sssssssssssssss if you like.
>
>Something more generically decomposable invites a new set of issues.
>Do you identify TCP? Just because CONNECT uses TCP, that doesn't mean
>you can't identify something in ALPN that doesn't (see
>draft-ietf-rtcweb-alpn for example).

I don't really buy that.  We're already over TCP and CONNECT.  We don't 
need to specify layers in the stack lower than where we currently are.

If they want to put pop3 over UDP over a CONNECT tunnel over TCP, then 
sure by all means specify UDP-POP3 as the tunneled protocol, but not 
TCP-CONNECT-UDP-POP3 if you see my point.

IP header doesn't have a field specifying it is over ethernet.  It has a 
protocol field, TCP has ports to achieve a similar effect.  I'm not 
aware of any protocol layer that identifies anything other than the next 
layer, not the one above that.  That's IMO one of the great design 
decisions of the internet.  It allows simple layered processing.

As for TLS1.3 deprecating the possibility of an intermediary verifying a 
server X.509 cert, that is going to annoy a lot of people if that's the 
case, there's a raft of products that protect people from invalid certs, 
and it does this without breaching privacy - just looks at the cert from 
the server, checks expiry and trust etc.


>
>The rtcweb draft actually sealed this for me, would you really want to
>identify that protocol, with all the branches: UDP, or TCP, or TURN
>over either of those (both TURN-UDP and TURN-TCP variants), then a
>mixture of SRTP, DTLS and ICE.

if it's over the CONNECT tunnel, that would be needed.


>On top of DTLS, then there is SCTP
>(with its UDP encapsulation), then on top of that there is a data
>channel protocol, after which there is some other protocol (which we
>do have an identifier for, but we don't trust that, and nor can we
>really police it either, and it might start after the tunnel is
>created). In case you want the whole ugly story:
>https://tools.ietf.org/html/draft-ietf-rtcweb-transports-07

Adrien

Received on Tuesday, 27 January 2015 01:28:39 UTC