Re: New tunnel protocol

Hi Martin,

I finally found some time to read it.

On Mon, Jan 19, 2015 at 09:09:06PM -0800, Martin Thomson wrote:
> I've revised the draft.
> 
> Changes are largely cosmetic.  The document has more complete
> boilerplate, including an IANA considerations section.
> 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-httpbis-tunnel-protocol-01.txt
> 
> I also created some bad formatting.  I'm correcting that in the
> editor's copy, but won't burden people with too many updates at once.

At first I was quite excited to see something like this but now I'm
seeing you want to limit its use to TLS only :

  "When CONNECT is used to establish a TLS tunnel, the Tunnel-Protocol
   header field may be used to carry the same application protocol label
   as will be carried within the TLS handshake.  If there are multiple
   possible application protocols, all of those application protocols
   are indicated."

I expected to see a header field indicating whether we were transporting
TLSv1.2, OpenVPN, RDP, ICA, IMAP, SSH etc since that's what makes it hard
for proxies to apply policy enforcement based on protocol validation.

I'm not sure about what purpose it provides since if a proxy expects TLS,
it could already look at ALPN to see the transported protocol.

Additionally I find that the header field name is not perfect if it's
only for the protocol inside TLS because it leaves no room for a non-
confusing header later for all other uses.

Thus I'm having two possible suggestions that come to mind :
  - either make this protocol a list of encapsulated layers. That way
    you can say "TLS/1.2, HTTP/1.1"

  - or if you really want it to be TLS-centric, at least it should carry
    the TLS name. Eg: "Tunnel-TLS-Protocol".

Personally I think the first one above is particularly suited to various
applications because they can decide what to disclose. For example,
"Tunnel-Protocol: TLS/1.2, h2" explicitly discloses everything, while
"Tunnel-Protocol: TLS/1.2" only discloses the envelope and a proxy may
or may not accept to let that pass through depending on its policy, or
could attempt to detect it via ALPN decoding. In the case where you want
multiple protocols to be attempted (eg: h2 & http/1.1), the second
option above probably is better. In this case, a client may send

  Tunnel-Protocol: TLS/1.2
  Tunnel-TLS-Protocol: h2, http/1.1

Then maybe the second one would always match ALPN and thus shoud carry
this name ?

  Tunnel-Protocol: TLS/1.2
  Tunnel-TLS-ALPN: h2, http/1.1

Just my two cents,
Willy

Received on Sunday, 25 January 2015 08:06:41 UTC