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).

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.  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

Received on Tuesday, 27 January 2015 01:15:13 UTC