Subject: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 Mar 2015 21:24:59 -0500

Everyone,

As discussed in the WG meeting today, we don't have any open issues for this product, so I believe it's ready.

Therefore, this is the announcement of WGLC for: 
  http://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-02

Please review the document carefully, and comment on this list.

WGLC will end on 10 April 2015 (I'm leaving a bit extra because this is an IETF week).

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 25 Mar 2015 21:12:38 +0000

this issue has been raised before, but I wasn't aware of a satisfactory 
resolution.

The target of this header is a proxy.  It is proxies that set up 
tunnels.

The feedback from proxy vendors on this proposed header seems to have 
been largely ignored.

If I see

Tunnel-Protocol: smtp

Then I can presume it's either smtp or that there's a TLS layer in there 
as well, and if I want to know, then I have to sniff for a client hello 
packet.  There is therefore what seems to be a deliberate ambiguity put 
into this spec which can only be resolved by sniffing.

The stated purpose of the spec is to allow perhaps prioritisation of 
traffic or something.  But any proxy interested in security (which they 
all are) is not going to blindly take an assertion from a client that it 
cannot verify and use that as a basis for allocation of priority 
resource.

As for the assertion that "proxies do not implement the tunneled 
protocol", well.... what can I say to that? What if they do? It doesn't 
look like normative language to me. Proxies commonly actually DO 
implement such tunneled protocols.
So I can only see this header going into the strip and ignore bucket.  I 
just hope it doesn't create too much confusion further on in time.

Adrien de Croy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Mar 2015 08:52:27 -0500

On 25 March 2015 at 16:12, Adrien de Croy <[email-masked]> wrote:
> The feedback from proxy vendors on this proposed header seems to have been
> largely ignored.

I'm sorry if you think that is the case, because that was certainly
not my interpretation of the discussion.

The answer to your concern was that application tokens identify the
entire protocol precisely.  This is the decision regarding ALPN use
that has been codified into HTTP/2.

I understand that this made a few people sad and they wanted something
else - primarily something that had explicit and separate
identification for TLS - but we don't have an alternative that is
well-enough defined to use.

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 26 Mar 2015 23:36:11 +0000

hi Martin

I must have misread something then, because it seems to me from the 
draft that the Tunnel-Protocol header is intended to contain what either

a) could be in a TLS ALPN negotiation if the next layer is TLS (T-P 
identifies the next layer after TLS)
b) would identify the protocol directly if the next layer is not  TLS 
(T-P identifies the next layer)

and that it be the same token(s) whether or not the next layer is TLS.   
E.g. explicity NOT 2 versions of an ALPN token one of which indicates 
the presence of TLS and one not.

So I can't see how the same ALPN token can distinguish that the next 
layer is TLS or not unless it must always be TLS, in which case you're 
at pains to avoid saying so and my question would then be why?

My personal opinion is that TLS is as much a protocol as anything else 
and if the next layer in a tunnel is TLS, then it's just an error to not 
say so or to say it's something else.  It just breaks the basic layering 
that the internet is based on.

This is what Amos was referring to I believe when he suggested 
indicating TLS and then using TLS ALPN for the next layer after that.

Regards

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Mark Nottingham" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 27/03/2015 2:52:27 a.m.
Subject: Re: Working Group Last Call for 
draft-ietf-httpbis-tunnel-protocol

>>been

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 27 Mar 2015 13:51:59 +1300

> indicating TLS and then using TLS ALPN for the next layer after that.

Yes.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Mar 2015 20:00:14 -0500

Adrien,

My understanding of our position on this is that the purpose of T-P is to indicate the gross semantics of the application protocol in use inside the tunnel, not to allow parsing of it. 

Specifically, the motivating use case is to indicate the use of WebRTC inside a CONNECT tunnel, so that a middle box can (if it wishes) assign appropriate QoS, deny service (e.g. because bandwidth is extremely limited), etc.

The discussion to date covered all of this, and the place that we seemed to come to was that T-P is not necessarily for use cases that require every protocol in the layering to be enumerated. We do understand that some people have such use cases, but we are not proposing to address them with T-P.

I think that's where we're at with it.

I imagine we could improve the draft to make this more clear (and proposals are welcome). Addressing those other use cases isn't out of the question, but my current reading of the WG is that there isn't an appetite to go there.

Cheers,

> On 26 Mar 2015, at 6:36 pm, Adrien de Croy <[email-masked]> wrote:
> 
> 
> hi Martin
> 
> I must have misread something then, because it seems to me from the draft that the Tunnel-Protocol header is intended to contain what either
> 
> a) could be in a TLS ALPN negotiation if the next layer is TLS (T-P identifies the next layer after TLS)
> b) would identify the protocol directly if the next layer is not  TLS (T-P identifies the next layer)
> 
> and that it be the same token(s) whether or not the next layer is TLS.   E.g. explicity NOT 2 versions of an ALPN token one of which indicates the presence of TLS and one not.
> 
> So I can't see how the same ALPN token can distinguish that the next layer is TLS or not unless it must always be TLS, in which case you're at pains to avoid saying so and my question would then be why?
> 
> My personal opinion is that TLS is as much a protocol as anything else and if the next layer in a tunnel is TLS, then it's just an error to not say so or to say it's something else.  It just breaks the basic layering that the internet is based on.
> 
> This is what Amos was referring to I believe when he suggested indicating TLS and then using TLS ALPN for the next layer after that.
> 
> Regards
> 
> Adrien
> 
> 
> 
> 
> Cc: "Mark Nottingham" <[email-masked]>; "HTTP Working Group" <[email-masked]>
> Subject: Re: Working Group Last Call for draft-ietf-httpbis-tunnel-protocol
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Fri, 27 Mar 2015 01:17:35 +0000

Hi Mark

thanks for explaining this position.  I guess my own reasons for my mail 
were to dispute claims that the draft did not introduce ambiguity and 
allowed full description of the protocol stack.

Whether or not there is appetite for further uses of the header at the 
current time (e.g. relating to parsing / enforcement), and whether we 
should preclude future possible uses of it by IMO getting it so badly 
wrong are 2 independent issues  and I would be interested in learning of 
proposed usage of the header in its current form by middle-box vendors.

But even aside from all that, I'm not keen on proliferation of RFCs 
which are ambiguous, as this tends to lead to interop problems.

I think it's a perfectly valid desire to wish to indicate what sort of 
thing is being tunneled for purposes of choosing service levels, however 
precluding the ability to easily verify a client assertion seems to be 
dangerous.

How about defining 2 headers?

Tunnel-TLS-ALPN to be used if the next layer is TLS
Tunnel-ALPN if it's not TLS

Same tokens for field values.  the name of the header clearly indicates 
it's ALPN and therefore it's obvious that ALPN tokens should be used.

Otherwise I think this draft should (instead of alluding to permitted 
use for non-TLS-tunnels) warn against using the header if there's no TLS 
layer.  I wonder if there's even a use case for non-TLS at the moment 
anyway.

Otherwise there's an expectation when the words "tunnel" and "protocol" 
are used, that these should actually refer to the tunnel and the 
protocol as we understand it, and this will be a source of confusion 
since in this draft they dont really map 1:1.

Regards

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Martin Thomson" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 27/03/2015 2:00:14 p.m.
Subject: Re: Working Group Last Call for 
draft-ietf-httpbis-tunnel-protocol

>Adrien,
>
>My understanding of our position on this is that the purpose of T-P is 
>to indicate the gross semantics of the application protocol in use 
>inside the tunnel, not to allow parsing of it.
>
>Specifically, the motivating use case is to indicate the use of WebRTC 
>inside a CONNECT tunnel, so that a middle box can (if it wishes) assign 
>appropriate QoS, deny service (e.g. because bandwidth is extremely 
>limited), etc.
>
>The discussion to date covered all of this, and the place that we 
>seemed to come to was that T-P is not necessarily for use cases that 
>require every protocol in the layering to be enumerated. We do 
>understand that some people have such use cases, but we are not 
>proposing to address them with T-P.
>
>I imagine we could improve the draft to make this more clear (and 
>proposals are welcome). Addressing those other use cases isn't out of 
>the question, but my current reading of the WG is that there isn't an 
>appetite to go there.
>
>Cheers,
>
>
>>  and that it be the same token(s) whether or not the next layer is 
>>TLS. E.g. explicity NOT 2 versions of an ALPN token one of which 
>>indicates the presence of TLS and one not.
>>
>>  My personal opinion is that TLS is as much a protocol as anything 
>>else and if the next layer in a tunnel is TLS, then it's just an error 
>>to not say so or to say it's something else. It just breaks the basic 
>>layering that the internet is based on.
>>

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Mar 2015 07:49:39 +0100

> Tunnel-ALPN if it's not TLS

I've been asking as well to explicitly use the ALPN word instead of
"Protocol" to make it explicit that we were designating the protocol
transported *over* TLS so that we could keep "Tunnel-Protocol" for
later purposes (eg: I don't think that TLS has its own ALPN identifier).

Please Martin, as you can see, the name "Tunnel-Protocol" is extremely
confusing as it uses something generic to indicate something specific.
We've had a lot of confusion on HTTP in the past (eg: content-length
that became ambiguous with compression as it used to designate the
framing for some implementations and the original contents for others).
Let's be clear here.

I'm fine with several proposals, as long as there's the ALPN name in
the header name to indicate that whatever value is advertised must be
a valid, registered ALPN token. Mentionning TLS before as Adrien
suggests would be even better, but I guess that without it we can
still understand that ALPN being TLS-only, TLS is implied.

Thanks,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 12:53:03 -0500

On 27 March 2015 at 01:49, Willy Tarreau <[email-masked]> wrote:
> a valid, registered ALPN token.

Would everyone be OK with the following header field name: "ALPN" ?

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 12:54:55 -0500

Oh, and I have to apologize for dropping the ball on this one.  It
somehow didn't get recorded as an issue.  I have corrected that:
https://github.com/httpwg/http-extensions/issues/57

---

From: Martin Thomson <[email-masked]>
Date: Fri, 27 Mar 2015 12:57:18 -0500

> Tunnel-ALPN if it's not TLS

As I mention up-thread, the presence of TLS is part of the protocol.
If the protocol negotiates TLS in-band, then it can be one protocol
identifier (STARTTLS or absence thereof is purely a function of the
protocol in use).

h2 and h2c are different protocols because the presence or absence of
TLS is fundamental.  I'd expect two tokens for any protocol that isn't
intrinsically able to decide about the status of TLS.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Mar 2015 19:06:04 +0100

Hi Martin,

> Would everyone be OK with the following header field name: "ALPN" ?

No objection from me, it seems to clear the confusion and address your
needs at the same time.

Thanks,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Mar 2015 18:00:41 +1300

On 28/03/2015 6:54 a.m., Martin Thomson wrote:
> On 27 March 2015 at 12:53, Martin Thomson wrote:
>> On 27 March 2015 at 01:49, Willy Tarreau wrote:

Okay by me too.

Though the header is of less interest for Squid in its current form than
I had thought earlier.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Sat, 28 Mar 2015 12:13:31 -0700

> Though the header is of less interest for Squid in its current form than

Maybe you can help us help you :) What specific property are you looking to
have exposed here?

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 29 Mar 2015 13:27:32 +1300

> Maybe you can help us help you :) What specific property are you looking to

A quick way to identify whether the inner protocol is TLS wrapped or
not, without having to register all the sub-protocols inside the TLS or
to sniff the TLS handshake.

Amos

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 29 Mar 2015 08:44:30 +0200

> to sniff the TLS handshake.

Here at least the presence of the ALPN header will indicate TLS is present.
However we won't have any indication about non-TLS protocols as it seems
we both expected. But we could write a second proposal for this as well.

Willy

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Mar 2015 03:12:24 +0000

I think renaming to ALPN addresses a couple of issues, but still not the 
one about whether it's being used for a TLS-wrapped protocol or bare 
protocol.

The language in the draft still is explicit that it would be the same 
token inside the TLS ALPN as would be in the HTTP header.

I'm happy if we remove the ability to use this for a non-TLS-wrapped 
protocol, since that removes any ambiguity.  Otherwise presense of TLS 
should be explicitly identified.

------ Original Message ------
From: "Willy Tarreau" <[email-masked]>
To: "Amos Jeffries" <[email-masked]>
Cc: "Martin Thomson" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 29/03/2015 7:44:30 p.m.
Subject: Re: Working Group Last Call for 
draft-ietf-httpbis-tunnel-protocol

---

From: Martin Thomson <[email-masked]>
Date: Sun, 29 Mar 2015 20:54:16 -0700

On 29 March 2015 at 20:12, Adrien de Croy <[email-masked]> wrote:
>
> I think renaming to ALPN addresses a couple of issues, but still not the one
> about whether it's being used for a TLS-wrapped protocol or bare protocol.

Correct.  The registry will have to serve there.  The presence or
absence of TLS is arguably of little value in cases where the protocol
is unknown anyway: unless you have some sort of magic I don't know of.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Mar 2015 11:43:50 +0000

sorry I'm still missing something about the possible function of the 
registry.

If you have a foo protocol that is used over TLS or may be used directly 
over TCP, then if you see

ALPN: foo

then how does the registry help you determine if this is foo over TLS or 
plaintext foo, since _surely_ you don't put foos in the TLS ALPN, since 
the "next layer" from TLS is not foos, it is foo.

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Willy Tarreau" <[email-masked]>; "Amos Jeffries" <[email-masked]>; 
"HTTP Working Group" <[email-masked]>
Sent: 30/03/2015 4:54:16 p.m.
Subject: Re: Working Group Last Call for 
draft-ietf-httpbis-tunnel-protocol

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2015 12:58:27 -0500

On 30 March 2015 at 06:43, Adrien de Croy <[email-masked]> wrote:
> plaintext foo, since _surely_ you don't put foos in the TLS ALPN, since the
> "next layer" from TLS is not foos, it is foo.

You describe the whole thing.  So 'foos' is correct.  A protocol of
foo over TLS over TCP is identified separately from foo over TCP.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 30 Mar 2015 21:20:20 +0000

OK I understand.

seems like broken layering to me though.

For instance what do you do for foo over TLS over TLS... create fooss?  
foo over SSH becomes foosh?

So to put a protocol over TLS you need to assign another registry entry? 
  And if it can go over some other channel you need to register even 
more?  I see problems with this approach.  Software won't be updated to 
recognise these tokens.  So it will have to resort to sniffing if it 
wants to do anything with the TLS layer (like protecting against bad 
certs).

The design pattern where each layer identifies only the next layer is 
very effective and elegant.  I don't know why we would want to move away 
from that.

It's a misnomer to refer to ALPN as "next layer" negotiation then.  
Maybe I'm being confused by NPN

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Willy Tarreau" <[email-masked]>; "Amos Jeffries" <[email-masked]>; 
"HTTP Working Group" <[email-masked]>
Sent: 31/03/2015 6:58:27 a.m.
Subject: Re: Working Group Last Call for 
draft-ietf-httpbis-tunnel-protocol