Subject: New tunnel protocol

From: Martin Thomson <[email-masked]>
Date: Mon, 19 Jan 2015 21:09:06 -0800

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.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 21 Jan 2015 15:59:00 +1100

Thanks, Martin.

I notice that we don't have any open issues for this document. Pending Martin's formatting changes, I'd like to start thinking about WGLC for this document.

Cheers,

> On 20 Jan 2015, at 4:09 pm, Martin Thomson <[email-masked]> wrote:
> 
> I've revised the draft.
> 

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

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 21 Jan 2015 18:25:40 +1300

On 21/01/2015 5:59 p.m., Mark Nottingham wrote:
> Thanks, Martin.
> 
> I notice that we don't have any open issues for this document.
> Pending Martin's formatting changes, I'd like to start thinking
> about WGLC for this document.
> 

In section 2.2 there are a "must not" and three "must" wordings. These
all need to be normative to make any sense.

Otherwie, LGTM.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Jan 2015 09:18:20 -0800

> all need to be normative to make any sense.

Done.  And thanks.

> I notice that we don't have any open issues for this document. Pending Martin's formatting changes, I'd like to start thinking about WGLC for this document.

Sounds like a plan.  Do you want to see a new revision?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 21 Jan 2015 22:00:43 +0100

> Sounds like a plan.  Do you want to see a new revision?

I'd like to see a new revision :-)

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 21 Jan 2015 22:01:45 +0000

Hi all.. happy new year!

one comment on this.  It seems this header is intended to be used only 
when the next protocol is actually TLS, and the one after that is the 
one that is identified by this header.

Is it really intended to limit this header to only be used when the next 
protocol is TLS?   It seems like it could be quite useful for other 
cases as well, and it is very common to use CONNECT tunnels for other 
protocols without TLS.

I think there could be some confusion around this, especially since the 
header name does not indicate such a restriction.

Cheers

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Martin Thomson" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 21/01/2015 5:59:00 p.m.
Subject: Re: New tunnel protocol

>Thanks, Martin.
>
>I notice that we don't have any open issues for this document. Pending 
>Martin's formatting changes, I'd like to start thinking about WGLC for 
>this document.
>
>Cheers,
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Jan 2015 14:05:44 -0800

On 21 January 2015 at 14:01, Adrien de Croy <[email-masked]> wrote:
> one comment on this.  It seems this header is intended to be used only when
> the next protocol is actually TLS, and the one after that is the one that is
> identified by this header.

We've used ALPN to describe non-TLS protocols already: h2c.

This is definitely usable outside of TLS.

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 21 Jan 2015 22:08:43 +0000

so is the plan to identify the next protocol as "TLS" and use ALPN 
within the TLS handshake to identify the next layer after that?  It 
would be great to re-use the identifiers, but it's not at all clear from 
the draft.

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: 22/01/2015 11:05:44 a.m.
Subject: Re: New tunnel protocol

>>when

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 21 Jan 2015 22:34:29 +0000

I tried reading it a few more times, I think my issues are round wording 
like

  "When CONNECT is used to establish a TLS tunnel, the Tunnel-Protocol 
header field may be used to carry the same  ..."

So there's room for ambiguity around whether the next layer (after 
CONNECT) is TLS or not.  Or do we rely on the identifier also indicating 
it is over TLS, in which case what if there are 2 TLS layers?

Also I'm having trouble with the concept of using CONNECT to establish a 
TLS tunnel.  It sounds in this case like the proxy does the TLS 
handshake and crypto, which is not what happens.  The endpoints do that. 
  Maybe better wording would be

When CONNECT is used to establish a tunnel that will be used to carry 
TLS.... or similar.

Thanks

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Martin Thomson" <[email-masked]>
Cc: "Mark Nottingham" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 22/01/2015 11:08:43 a.m.
Subject: Re: New tunnel protocol

>would be great to re-use the identifiers, but it's not at all clear 
>from the draft.
>
>Regards
>
>Adrien
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Jan 2015 15:11:09 -0800

On 21 January 2015 at 14:34, Adrien de Croy <[email-masked]> wrote:
> So there's room for ambiguity around whether the next layer (after CONNECT)
> is TLS or not.  Or do we rely on the identifier also indicating it is over
> TLS, in which case what if there are 2 TLS layers?

I get your point.  My understanding, and what is written down, were
indeed quite different.

Does this help?

https://github.com/httpwg/http-extensions/commit/7e2e57a48c21be2b68f856b41095800620fc1a20
http://httpwg.github.io/http-extensions/tunnel-protocol.html#rfc.section.1
(when Travis catches up)

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 22 Jan 2015 01:55:47 +0000

Hi Martin

I think thatt's a lot clearer, however it still seems to basically be 
saying "if you see a protocol id, it may or may not be over TLS over the 
tunnel".

I guess you could make the argument that if a protocol is over tls, the 
protocol name should indicate that, e.g. instead of advertising smtp, 
you'd advertise smtps.

But if someone for some unfathomable reason were to try to describe 
smtps over tls, that wouldn't be possible I guess.  I think it could be 
useful to have a separate attribute clearly indicating the use of TLS or 
not

e.g.

Tunnel-Protocol: smtp; tls-layer=on;

Otherwise TLS is kinda having some different status, when you could put 
an argument that if the next level is TLS, then T-P should only ever say 
TLS, maybe indicate next level after that some other way such as

Tunnel-Protocol: TLS; next-layer=smtp

A proxy verifying this can then know explicitly whether to expect TLS 
next, and whether the ALPN in TLS should match what is specified as next 
protocol etc.

Also the language about proxies not i mplementing the tunneled protocol 
I wonder is a bit optimistic, we see a lot of traffic / different 
protocols non-web-related going over CONNECT tunnels, and customers want 
to control them, sometimes to a degree which requires protocol 
implementation.

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: 22/01/2015 12:11:09 p.m.
Subject: Re: New tunnel protocol

>>CONNECT)

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 22 Jan 2015 17:50:46 +1300

On 22/01/2015 12:11 p.m., Martin Thomson wrote:
>> So there's room for ambiguity around whether the next layer
>> (after CONNECT) is TLS or not.  Or do we rely on the identifier
>> also indicating it is over TLS, in which case what if there are 2
>> TLS layers?
> 
> I get your point.  My understanding, and what is written down,
> were indeed quite different.
> 
> Does this help?
> 
> (when Travis catches up)

No,

Consider that under the new scheme the label for HTTPS tunnels would
say "HTTP/1.1" to indicate that an HTTP/1.1 compliant proxy "does not
understand nor implement the tunneled protocol".

The client intent is to tunnel TLS to keep the stuff inside secure. It
is not appropriate for the HTTP upper layers to expose those
intended-private details for all the world to read.

IMO, just indicate TLS as the next layer after CONNECT and have that
layers ALPN (or not) indicate the nested next-layer. If the
intermediary is capable of peeking at the TLS ALPN value it can do so
itself. That also resolves security and logistical issues with keeping
the two ALPN tags in-sync.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Jan 2015 09:02:49 -0800

Or, if you consider what you are doing to be confidential (it usually
isn't), don't include tunnel-protocol. Just like today.
On Jan 21, 2015 8:56 PM, "Amos Jeffries" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJUwIGlAAoJELJo5wb/XPRjbLUIAKEwlIVSVfrTnjnmKMzR+i2c
> v/x+Qrxsw1Hc5HIHSPqSamcW86MWsKjf872Ay5kLbjzbye5XRVIxJX8ltteImfH4
> ft9gSEAnIIaeqXcHW7yAE4M+M8x67ShXz2ErvmUEHh38hoybsBYqNVKkGEVg4oEU
> u6Siuljxjtj4NmhRP8hMTLYf6vT01LOwY9g7gZ3EGf5k0vk+6yTF9qBNxKji9RHF
> qF6a+/hK15l9YVJejk4KI1w3Jp4xy0Vw0hwJQux+nnbn4D/dW5CE3myIy345xDts
> ZJhZsKAcRg+JEoRGIMGze6Of5lBIlmtgxs8nhuSalwve+G/grguWb83DDeykWx4=
> =UNbp
> -----END PGP SIGNATURE-----
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 25 Jan 2015 03:33:34 +0000

that's a different issue.

The problem for me as a proxy implementor, is I still don't know whether 
to expect there to be a TLS layer in there or not.  Please don't make me 
resort to sniffing or daft heuristics to figure this out.  Just make it 
explicit.  If there is an and/or option, include a way to clearly state 
this in the protocol.

Cheers

Adrien

---

From: Martin Thomson <[email-masked]>
Date: Sat, 24 Jan 2015 21:20:46 -0800

On 24 January 2015 at 19:33, Adrien de Croy <[email-masked]> wrote:
> The problem for me as a proxy implementor, is I still don't know whether to
> expect there to be a TLS layer in there or not.  Please don't make me resort
> to sniffing or daft heuristics to figure this out.  Just make it explicit.
> If there is an and/or option, include a way to clearly state this in the
> protocol.

The ALPN identifier tells you if there is TLS.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Jan 2015 09:06:15 +0100

Hi Martin,

I finally found some time to read it.

> 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

---

From: Amos Jeffries <[email-masked]>
Date: Sun, 25 Jan 2015 21:37:41 +1300

On 25/01/2015 6:20 p.m., Martin Thomson wrote:
> On 24 January 2015 at 19:33, Adrien de Croy wrote:

What does this mean?

 CONNECT example.com:443 HTTP/1.1
 Tunnel-Protocol: h2c
 ...
 <TLS handshake ALPN(h2)>

Or

 CONNECT example.com:80 HTTP/1.1
 Tunnel-Protocol: HTTP/1.1
 ...
 <TLS handshake ALPN(http/1.1)>
 GET / HTTP/1.1

Or

 CONNECT example.com:80 HTTP/1.1
 Tunnel-Protocol: HTTP/1.1
 \r\n
 <TLS handshake>
 ...
 HTTP/1.1 4xx Protocol Not Supported
 \r\n
 The "HTTP/1.1" protocol is not permitted through this HTTP/1.1 proxy.
 \r\n

Or

 CONNECT example.com:587 HTTP/1.1
 Tunnel-Protocol: h2c
 ...
 <TLS handshake>
 HELO example.com:25 HTTP/1.1
 ...

Any attempt to proxy the above and use the new header results in some
form of interoperability failures. So what reason does anybody have to
bother using it?

Lots of problems disappear by being strict that next means *next* layer.
Not allowing any intermediary layer (ie TLS ALPN extension) to
contradict the identifiable state.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Jan 2015 09:39:33 -0800

Thanks for taking a look Willy, and my apologies for not getting this
properly right (I'll explain below).

> seeing you want to limit its use to TLS only :

That is certainly not the intent.  As "h2c" demonstrates, we're using
ALPN to identify protocols that don't run on TLS.

The latest editor's draft attempts to address that problem.

> for proxies to apply policy enforcement based on protocol validation.

All those need is a new ALPN identifier and they are good to go.

> it could already look at ALPN to see the transported protocol.

Well, part of the intent here is to allow the proxy to bring that
information forward.  Then, the only thing that it might want to do is
check that the client wasn't lying.

>     you can say "TLS/1.2, HTTP/1.1"

As currently used for "h2" and "h2c", ALPN identifies a specific
protocol, with all the layers that it depends on (the whole stack, if
you will).

> option above probably is better. In this case, a client may send

Partial disclosure wasn't a goal. If the intent is to hide some of
what is happening, the best option is to omit the header field
entirely.

---

From: Martin Thomson <[email-masked]>
Date: Sun, 25 Jan 2015 09:48:18 -0800

>> The ALPN identifier tells you if there is TLS.

That some values for the ALPN identifier signal that there is TLS in
the stack (h2, http/1.1) and others don't (h2c).

>  CONNECT example.com:443 HTTP/1.1

That means that the client lied to the proxy.

>  <TLS handshake ALPN(http/1.1)>

The value "HTTP/1.1" isn't defined, but if it were to mean cleartext
HTTP/1.1 (the lowercase variant means HTTP/1.1 over TLS) then the
client is lying here too.

>  The "HTTP/1.1" protocol is not permitted through this HTTP/1.1 proxy.

If you intended the lowercase variant here, that's fine.  The value
only signals the client's intent with respect to application
protocols.  Here, the destination server has declined the transaction,
but it is still effectively speaking the intended protocol.

>  HELO example.com:25 HTTP/1.1

Again, that's the client lying about its intentions.  Depending on how
much information the proxy can extract from the session, there isn't
much that can be done about that.  Of course, the client might find
that its connection has been given a priority that is completely
inappropriate for its actual task.

> form of interoperability failures. So what reason does anybody have to

I assume that the interoperability failures only occur if the
destination server fails to understand what the client wants and does.
That is always possible though; I can fail to implement a protocol
correctly in numerous ways.

Of course, if the proxy is performing a MitM on the TLS session, or
the client chooses a cleartext protocol and the proxy decides to MitM
that, that is definitely highly likely to break something.  That's on
the client, for lying.

> contradict the identifiable state.

Indeed they do, but that does not address the actual requirements
here.  The "next" layer in something like WebRTC is basically useless
(it's a TCP encapsulation of UDP packets in some cases).

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Jan 2015 19:57:16 +0100

> properly right (I'll explain below).

You're welcome.

> ALPN to identify protocols that don't run on TLS.

OK, then maybe put ALPN in the header field's name to remove the
ambiguity, because there there's nothing that makes it obvious
that TLS is in use at all, and the name makes one think it's the
protocol being tunnelled which is named instead of the one inside
TLS.

> The latest editor's draft attempts to address that problem.

OK I'll check, thanks.

(...)
> check that the client wasn't lying.

OK. It could indeed be useful if the entity responsible for emitting
the header is the one where the policy is configured and differs from
the one feeding the TLS stream and from the one verifying the match.

> protocol, with all the layers that it depends on (the whole stack, if

OK but my point was about all the non-TLS protocols I mentionned above.
It would be strange to have "h2" indicating that it's h2 over TLS, and
"smtp" indicating that it's raw SMTP without TLS. The presence of ALPN
implies use of TLS, so for protocols not having to pass through TLS it
seems a bit awkward.

I'll try to catch up with the rest of the thread as I've noticed that
there's already an ongoing discussion about this.

Thanks
Willy

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 25 Jan 2015 19:14:18 +0000

ok, that's what I was getting at in my initial query

it may help then to make that clear in the dfraft that the ALPN id is 
the thing specifying whether TLS is the next layer or not

So for those concerned with privacy, the client could simply advertise 
TLS

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

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.

You'd need to make sure that for every protocol you could see in a TLS 
APLN option, there was a corresponding -s version defined for T-P.

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.

Adrien

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 25/01/2015 6:20:46 p.m.
Subject: Re: New tunnel protocol

---

From: Adrien de Croy <[email-masked]>
Date: Mon, 26 Jan 2015 10:14:31 +1300

One more thought on this. A proxy wanting to do cert verification on TLS needs to know if the next layer is TLS. 

Requiring a proxy to recognise all ALPN ids to know this I think is a bad design decision. 

> On 26/01/2015, at 8:14 am, Adrien de Croy <[email-masked]> wrote:
> 
> it may help then to make that clear in the dfraft that the ALPN id is the thing specifying whether TLS is the next layer or not
> 
> So for those concerned with privacy, the client could simply advertise TLS
> 
> You will need to make sure all the variants are registered as ALPN ids though as well,  such as
> 
> 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.
> 
> You'd need to make sure that for every protocol you could see in a TLS APLN option, there was a corresponding -s version defined for T-P.
> 
> 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.
> 
> Adrien
> 
> Cc: "Amos Jeffries" <[email-masked]>; "HTTP Working Group" <[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Jan 2015 16:00:16 -0800

> protocol being tunnelled which is named instead of the one inside

I've always considered the name on this draft to be weak.  But I
haven't found a name that I liked better.

Please send suggestions.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Jan 2015 16:11:27 -0800

> pop3 and pop3s, smtp and smtps, imap etc etc

Yep.

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

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.

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

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 27 Jan 2015 01:02:51 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 27/01/2015 1:11:27 p.m.
Subject: Re: New tunnel protocol

>>layer,
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

>>  One more thought on this. A proxy wanting to do cert verification on 
>>TLS needs to know if the next layer is TLS.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 26 Jan 2015 17:14:46 -0800

On 26 January 2015 at 17:02, Adrien de Croy <[email-masked]> wrote:
> 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

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 27 Jan 2015 01:27:42 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 27/01/2015 2:14:46 p.m.
Subject: Re: New tunnel protocol

>>over an

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.

>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

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 27 Jan 2015 07:47:11 +0100

> haven't found a name that I liked better.

The name of the draft has little importance, you need one to start
discussions, so by definition the contents may change over time.

> Please send suggestions.

For the header field, I'd suggest : Tunnel-ALPN. That clearly covers
your purpose of advertising the ALPN names registered at IANA.

But like Amos and Adrien, I think that you're missing an opportunity
to have a header field indicating what is transported when it's not
TLS, and possibly to make it more flexible to indicate what is put
on top of TLS. I understand the benefits of ALPN (given that it
advertises a list of protocols to be negociated), as well as I'm
pretty convinced about the benefits of indicating what is transported
so that clients may help policy enforcement detect their protocol and
validate it (eventhough I respect that it could be out of the scope
of your proposal).

At least, calling it Tunnel-ALPN or TLS-ALPN, or Tunnel-TLS-ALPN will
serve your purpose and will not prevent anyone from proposing to
address the other needs with another non-confusing header field name.

Regards,
Willy

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 27 Jan 2015 09:01:13 +0000

Willy - I think the intention is that this is used whether or not there 
is TLS in play, but that the ALPN token used in Tunnel-Protocol wouldn't 
match what is in the ALPN in any tunneled TLS (if any).

E.g. if tunneling SMTP over TLS, you'd advertise smtps in the 
Tunnel-Protocol header, and smtp in the ALPN field in the client helo in 
TLS.

If tunneling SMTP, you'd just advertise smtp in the Tunnel-Protocol 
header.  So it's using the Tunnel-Protocol to describe possibly several 
layers.

I personally would prefer to separate it out so that a proxy can know 
the next layer is TLS regardless of what is transported over TLS.

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 27 Jan 2015 10:12:54 +0100

> header.  So it's using the Tunnel-Protocol to describe possibly several 

But the issue then is that it requires that ALPN entries exist for
protocols that are normally not transported over TLS, thus adding a
lot of confusion (eg: openvpn, tls, etc).

> the next layer is TLS regardless of what is transported over TLS.

I agree, but I respect Martin's wish as well, hence why I was proposing
to only advertise ALPN instead. I mean, if the ALPN header would match
the ALPN in TLS, it's still possible for clients to announce what they're
expecting to use and for proxies to enforce validation. The presence of
the ALPN header field would imply that TLS is being used. Just as much as
I would love to see something to advertise any protocol in the tunnel
regardless of TLS being used or not, I can understand it doesn't completely
address Martin's needs. What would be nice would be to ensure that
everything is properly addressed at least in a way that leaves room for
future improvements.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Jan 2015 09:32:35 -0800

On 27 January 2015 at 01:01, Adrien de Croy <[email-masked]> wrote:
>
> Willy - I think the intention is that this is used whether or not there is
> TLS in play, but that the ALPN token used in Tunnel-Protocol wouldn't match
> what is in the ALPN in any tunneled TLS (if any).

The opposite of that.  See HTTP/2.

> Tunnel-Protocol header, and smtp in the ALPN field in the client helo in

If "smtps" identifies a profile of SMTP that runs over TLS, both
places would use that string.

The intent is to have the two match exactly.

---

From: "Adrien de Croy" <[email-masked]>
Date: Tue, 27 Jan 2015 19:56:14 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Willy Tarreau" <[email-masked]>; "HTTP Working Group" 
<[email-masked]>
Sent: 28/01/2015 6:32:35 a.m.
Subject: Re: New tunnel protocol

>The intent is to have the two match exactly.

therein the problem.  Surely if the next protocol after TLS is smtp, 
then you don't advertise smtps in the TLS ALPN???? Pretty sure captures 
I've seen seen for https, only advertise http inside the ALPN field in 
the TLS client hello message.

Adrien

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Jan 2015 12:42:15 -0800

On 27 January 2015 at 11:56, Adrien de Croy <[email-masked]> wrote:
> therein the problem.  Surely if the next protocol after TLS is smtp, then
> you don't advertise smtps in the TLS ALPN????

Why?  It's not like the TLS magically disappears even if you can decrypt it.

> Pretty sure captures I've seen
> seen for https, only advertise http inside the ALPN field in the TLS client
> hello message.

The string "http/1.1" means HTTP/1.1 over TLS.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 28 Jan 2015 12:49:51 +1300

On 28/01/2015 9:42 a.m., Martin Thomson wrote:
> On 27 January 2015 at 11:56, Adrien de Croy wrote:

... and the ALPN string that means HTTP/1.1 over TCP is also "http/1.1".

I need to separately identify these two for a real-world case without
reading any bytes following the CONNECT message. How?

What I understand is that every other protocol *except* HTTP/2 uses its
plain-text protocol label to signal "next protocol" in places like ALPN.
So there is no way for any of those protocols to signal the existence of
TLS using their regular label.

Amos

---

From: Adrien de Croy <[email-masked]>
Date: Wed, 28 Jan 2015 14:59:07 +1300

> On 28/01/2015, at 9:42 am, Martin Thomson <[email-masked]> wrote:
> 

No it doesn't. It means the next protocol is HTTP/1.1.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2015 13:35:48 +1100

Hi Amos et al,

Personally, I generally agree much of your concern here -- the ad hoc way in which ALPN identifiers sprung up always made me nervous (and I've expressed that a few times). It would be nicer if there were (dare I say it) a more well-defined architecture around ALPN-as-protocol-identifier.

HOWEVER, in this case we're not talking about a negotiation mechanism, nor are we trying to allow intermediaries to parse the contents of the connection. Rather, the purpose of tunnel-protocol is a hint as to the semantics of the application inside the tunnel, so as to enable application of policy.

E.g., if the content is WebRTC, the network might want to apply different QoS, or refuse the tunnel because they're extremely bandwidth-constrained.

For those use cases, it makes no difference (that I can see) as to whether the content is encrypted or not.

What you seem to be asking for is to know whether encryption is going to be used in a tunnel up-front when you see a connection. In the current environment, designing this to allow intermediaries to discriminate against encrypted connections would be unlikely to gain traction, I think.

Cheers,

> On 28 Jan 2015, at 10:49 am, Amos Jeffries <[email-masked]> wrote:
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 28 Jan 2015 03:02:44 +0000

Hi Mark

what sort of policy is it envisioned that this protocol would enable?  
If a resource allocation policy then it would be prudent surely to not 
set up a system that people can game by lying?

That then requires a proxy to verify the client assertion if it is to 
make any use of the header at all.  So why not design a protocol that 
allows that, instead of one which abuses:

a) the excellent design pattern of a layer in a stack identifying the 
next layer
b) the ALPN identifiers

and introduces ambiguity which requires traffic sniffing and heuristics 
to resolve.  I'm pretty sure i recall several discussions about sniffing 
in various contexts on this list and it seems like a bad goal.

It seems a little ironic to me that all the people raising concerns 
about this proposal are proxy vendors, who are surely the target 
audience for this draft, and it seems foolhardy to steadfastly ignore us 
yet expect this to gain some traction in proxies.

Train wreck by committee.

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Amos Jeffries" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 28/01/2015 3:35:48 p.m.
Subject: Re: New tunnel protocol

>Hi Amos et al,
>
>Personally, I generally agree much of your concern here -- the ad hoc 
>way in which ALPN identifiers sprung up always made me nervous (and 
>I've expressed that a few times). It would be nicer if there were (dare 
>I say it) a more well-defined architecture around 
>ALPN-as-protocol-identifier.
>
>HOWEVER, in this case we're not talking about a negotiation mechanism, 
>nor are we trying to allow intermediaries to parse the contents of the 
>connection. Rather, the purpose of tunnel-protocol is a hint as to the 
>semantics of the application inside the tunnel, so as to enable 
>application of policy.
>
>E.g., if the content is WebRTC, the network might want to apply 
>different QoS, or refuse the tunnel because they're extremely 
>bandwidth-constrained.
>
>What you seem to be asking for is to know whether encryption is going 
>to be used in a tunnel up-front when you see a connection. In the 
>current environment, designing this to allow intermediaries to 
>discriminate against encrypted connections would be unlikely to gain 
>traction, I think.
>
>Cheers,
>
>
>>>>then

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2015 14:07:03 +1100

Hey Adrien,

> On 28 Jan 2015, at 2:02 pm, Adrien de Croy <[email-masked]> wrote:
> 
> Hi Mark
> 
> what sort of policy is it envisioned that this protocol would enable?  If a resource allocation policy then it would be prudent surely to not set up a system that people can game by lying?

That was discussed a fair bit when this draft was first brought up. I think everyone acknowledges the limits of this approach (and perhaps the draft could do a better job in that).

They *very* limited cases where this is useful is in places where the UA inserts the header without any user control, e.g., a WebRTC implementation, and the network wants to do best-effort to QoS or reject those.

By their nature, such policy mechanisms are limited. We don't yet have a solution for "the label on these bits are a lie." That doesn't mean that all labels are useless; just that they need to be used with that limitation in mind.

> That then requires a proxy to verify the client assertion if it is to make any use of the header at all.  So why not design a protocol that allows that, instead of one which abuses:
> 
> a) the excellent design pattern of a layer in a stack identifying the next layer
> b) the ALPN identifiers
> 
> and introduces ambiguity which requires traffic sniffing and heuristics to resolve.  I'm pretty sure i recall several discussions about sniffing in various contexts on this list and it seems like a bad goal.
> 
> It seems a little ironic to me that all the people raising concerns about this proposal are proxy vendors, who are surely the target audience for this draft, and it seems foolhardy to steadfastly ignore us yet expect this to gain some traction in proxies.
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 28 Jan 2015 03:22:28 +0000

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 28/01/2015 4:07:03 p.m.
Subject: Re: New tunnel protocol

>That was discussed a fair bit when this draft was first brought up. I 
>think everyone acknowledges the limits of this approach (and perhaps 
>the draft could do a better job in that).
>
>They *very* limited cases where this is useful is in places where the 
>UA inserts the header without any user control, e.g., a WebRTC 
>implementation, and the network wants to do best-effort to QoS or 
>reject those.
>
>By their nature, such policy mechanisms are limited. We don't yet have 
>a solution for "the label on these bits are a lie." That doesn't mean 
>that all labels are useless; just that they need to be used with that 
>limitation in mind.
I think it could fulfil these goals, and do a better job at it, if it 
were possible to verify the client assertion.  Requiring sniffing for a 
TLS client hello is not going to help interop or help authors to make 
bug-free implementations.  Even trying to sniff prior to deciding 
whether to add a TLS interpreter in the parsing stack is not 
straightforward when most people use libraries for TLS.  So people will 
have to roll their own TLS packet parsers.  That seems like a really bad 
goal.

I think we must always consider the applications we haven't thought of 
yet.  And the confusion created by adopting a radically different design 
pattern to one which is in use at all layers of our stacks.

I don't have any problem with a client wishing to advertise it is using 
a protocol as a payload within TLS, and indicating there is a TLS layer 
there.  I have a problem with the ambiguity about whether there is the 
TLS layer there or not, because this requires sniffing to resolve, and I 
believe the confusion around it will cause interop problems.

Adrien

>>  and introduces ambiguity which requires traffic sniffing and 
>>heuristics to resolve. I'm pretty sure i recall several discussions 
>>about sniffing in various contexts on this list and it seems like a 
>>bad goal.
>>
>>audience for this draft, and it seems foolhardy to steadfastly ignore 
>>us yet expect this to gain some traction in proxies.
>>
>>>  Personally, I generally agree much of your concern here -- the ad 
>>>hoc way in which ALPN identifiers sprung up always made me nervous 
>>>(and I've expressed that a few times). It would be nicer if there 
>>>were (dare I say it) a more well-defined architecture around 
>>>  HOWEVER, in this case we're not talking about a negotiation 
>>>mechanism, nor are we trying to allow intermediaries to parse the 
>>>contents of the connection. Rather, the purpose of tunnel-protocol is 
>>>a hint as to the semantics of the application inside the tunnel, so 
>>>as to enable application of policy.
>>>
>>>  What you seem to be asking for is to know whether encryption is 
>>>going to be used in a tunnel up-front when you see a connection. In 
>>>the current environment, designing this to allow intermediaries to

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 28 Jan 2015 17:00:43 +1300

On 28/01/2015 4:07 p.m., Mark Nottingham wrote:
>> what sort of policy is it envisioned that this protocol would
>> enable?  If a resource allocation policy then it would be prudent
>> surely to not set up a system that people can game by lying?
> 
> By their nature, such policy mechanisms are limited. We don't yet
> have a solution for "the label on these bits are a lie." That doesn't
> mean that all labels are useless; just that they need to be used with
> that limitation in mind.

I proposed a solution to that days ago. Label only what the next layer
is (TLS, or whatever) instead of next+N layer(s).

If the label is an identifiable lie (sniffing of the TLS handshake can
be done without touching anything encrypted) then correct or strip the
header.

Note how I am only speaking to verifying the Tunnel-Protocol header
itself. An act which is under the scope of this draft to make normative.
Verifying the ALPN on the TLS is left as an exercise for the endpoints
speaking TLS.

Choosing between decrypt+sniff to verify some potentially unsupported
protocol inside TLS encrypted payload, or allowing lies to affect basic
policy decisions - neither can be called desirable ways to promote use
of encryption. Quite the opposite.

> 
>> That then requires a proxy to verify the client assertion if it is
>> to make any use of the header at all.  So why not design a protocol
>> that allows that, instead of one which abuses:
>> 
>> a) the excellent design pattern of a layer in a stack identifying
>> the next layer b) the ALPN identifiers
>> 
>> heuristics to resolve.  I'm pretty sure i recall several
>> discussions about sniffing in various contexts on this list and it
>> seems like a bad goal.
>> 
>> audience for this draft, and it seems foolhardy to steadfastly
>> ignore us yet expect this to gain some traction in proxies.
>> 
>> ------ Original Message ------ From: "Mark Nottingham"
>> 
>>> Hi Amos et al,
>>> 
>>> hoc way in which ALPN identifiers sprung up always made me
>>> nervous (and I've expressed that a few times). It would be nicer
>>> if there were (dare I say it) a more well-defined architecture
>>> around ALPN-as-protocol-identifier.
>>> 
>>> contents of the connection. Rather, the purpose of
>>> tunnel-protocol is a hint as to the semantics of the application
>>> inside the tunnel, so as to enable application of policy.
>>> 
>>> For those use cases, it makes no difference (that I can see) as
>>> to whether the content is encrypted or not.
>>> 
>>> going to be used in a tunnel up-front when you see a connection.
>>> In the current environment, designing this to allow
>>> intermediaries to discriminate against encrypted connections
>>> would be unlikely to gain traction, I think.

Discrimination is going to happen whatever we do. I'm arguing for a
design where the discrimination *for* encryption is not tied up in knots.

An implementation which is going to discriminate against particular
encrypted protocols (h2 vs pop3s for example) currently needs to
implement decryption to do so. Lets leave it that way while making it
easy to pass-thru encrypted traffic.

Pulling the encrypted internal protocol name out into cleartext makes it
easy to discriminate against any secure protocols while letting the
insecure ones happen in a broken/decrypted way. That actively allows
hiding the interceptor for some protocols instead of making it reveal
itself.

I was planning a configuration ON/OFF knob in Squid to opaquely reject
CONNECT unless it sees Tunnel-Protocol:TLS - and only traffic that
passes that frontline gets deeper inspection at sysadmin choices of
ACLs. Its a common enough feature request.
 If we are having an unbounded assortment of names for encrypted
protocols then even that gets left to the sysadmin to configure
manually. Undoubtedly ending up with uncoordinated mashup of what
protocols people know about and what protocols work per-installation.
And then lies begin to actually matter - with the on/off the worst a lie
can do is self-DoS the lying client.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Tue, 27 Jan 2015 20:38:06 -0800

> ... and the ALPN string that means HTTP/1.1 over TCP is also "http/1.1".

I'm not aware of any such thing being registered.

(p.s., I can no longer keep up with the volume of emails on this
thread, so I might not be replying as often.)

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 28 Jan 2015 15:40:17 +1100

Adrien,

> On 28 Jan 2015, at 2:22 pm, Adrien de Croy <[email-masked]> wrote:

> I think it could fulfil these goals, and do a better job at it, if it were possible to verify the client assertion.  Requiring sniffing for a TLS client hello is not going to help interop or help authors to make bug-free implementations.  Even trying to sniff prior to deciding whether to add a TLS interpreter in the parsing stack is not straightforward when most people use libraries for TLS.  So people will have to roll their own TLS packet parsers.  That seems like a really bad goal.
> 
> I think we must always consider the applications we haven't thought of yet.  And the confusion created by adopting a radically different design pattern to one which is in use at all layers of our stacks.
> 
> I don't have any problem with a client wishing to advertise it is using a protocol as a payload within TLS, and indicating there is a TLS layer there.  I have a problem with the ambiguity about whether there is the TLS layer there or not, because this requires sniffing to resolve, and I believe the confusion around it will cause interop problems.

At the risk of repeating myself - 

You seem to be arguing for a use case where the application payload is actually being parsed by an intermediary. That is not the a use case that we've discussed supporting.

Again, this is *not* a negotiation mechanism -- so what are the interop problems you're concerned about?

Regards,

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Wed, 28 Jan 2015 10:48:23 +0100

Le Mer 28 janvier 2015 03:35, Mark Nottingham a écrit :
Hi,

> What you seem to be asking for is to know whether encryption is going to
> be used in a tunnel up-front when you see a connection. In the current
> environment, designing this to allow intermediaries to discriminate
> against encrypted connections would be unlikely to gain traction, I think.

It's not discrimination. Without TLS you can cache, with TLS you can not.
Thus TLS changes the bandwidth constrains, and the kind of middlebox the
data flow must be routed through to succeed.

The middlebox-hostile stance you describe only results in middleboxes
failing to make the correct decisions when relaying data, and web clients
complaining that the brand new protocols they tried to smuggle through TLS
tunnels fail right and left on the real Internet.

Sometimes I wonder if they actually want their stuff to work, or just want
to have someone to point the finger to.

-- 
Nicolas Mailhot

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 28 Jan 2015 10:03:52 +0000

Hi Mark

As soon as you want to verify the client assertion, you need to do some 
parsing.

I think it's a bit short-sighted to deny the potential applications that 
could be had if we allowed verification of the assertion.  I'd go so far 
as to say without being able to be verified, the header won't really add 
any value at all.  We're talking about forward proxies here, which is a 
restricted use case.  You may as well set QOS on U-A as a T-P you can't 
easily verify.

It's one thing to deny service based on a client assertion, it's another 
thing to grant some extra access.  You can do the former without 
checking, since the client has presumably no incentive to lie in order 
to be blocked.  However customers will (rightly) want verification of 
any client assertion which elevates a client's service level.

Having the client advertise the next protocol(s) in a tunnel is 
extremely interesting.  We see unwanted protocols over CONNECT all the 
time.  Probably a significant proportion of the world's email spam is 
transported this way.  Currently, we have no way other than heuristic 
protocol divination to see what the next layer is.  We start with the 
port number, look at what messages are sent etc etc.

If we were given the client assertion as to the protocol however, we 
could still deny without verification, but if policy allows the 
protocol, we need to pass it off for verification, and in this case we 
can do that trivially easily and in a way which only breaks if the 
client is lying and where the lie results in a denial to the client.

There are also products out there that add value to TLS without 
breaching privacy, for instance by checking for well formed protocol, 
protecting against certain types of exploits, and verifying server 
certificates.

So basically being deterministic around advertising of the TLS layer 
allows a lot of added benefit for IMO trivial cost (in terms of change 
to the proposal).  Could even adopt something like

Tunnel-Protocol: TLS:http/1.1
with ALPN in the TLS layer advertising http/1.1

or

Tunnel-Protocol: TLS
and use ALPN in TLS for the next layer or not so you're not leaking the 
next layer after the next layer for whatever reason.

I really just don't want to have to sniff for TLS, or have to second 
guess every ALPN ID as to whether that means it has TLS or not, and what 
to do when the inevitable confusion arises and the client gets it wrong.

My only complaint really about the draft is the ambiguity about whether 
the next protocol is TLS or not.  Surely we can think of a way to simply 
just state whether it is or not, rather than requiring the proxy to jump 
through hoops to guess?  This is new, we have an opportunity to make it 
explicit.

For whatever purpose, whether that be higher level protocol analysis or 
TLS hardening, or something we haven't though of yet.

Adrien

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 28/01/2015 5:40:17 p.m.
Subject: Re: New tunnel protocol

>>have to roll their own TLS packet parsers. That seems like a really 
>>bad goal.
>>
>>  I think we must always consider the applications we haven't thought 
>>of yet. And the confusion created by adopting a radically different 
>>design pattern to one which is in use at all layers of our stacks.
>>
>>  I don't have any problem with a client wishing to advertise it is 
>>using a protocol as a payload within TLS, and indicating there is a 
>>TLS layer there. I have a problem with the ambiguity about whether 
>>there is the TLS layer there or not, because this requires sniffing to 
>>resolve, and I believe the confusion around it will cause interop 
>>problems.
>
>You seem to be arguing for a use case where the application payload is 
>actually being parsed by an intermediary. That is not the a use case 
>that we've discussed supporting.
>
>>>>>contents of the connection. Rather, the purpose of tunnel-protocol 
>>>>>is a hint as to the semantics of the application inside the tunnel, 
>>>>>so as to enable application of policy.
>>>>>
>>>>>discriminate against encrypted connections would be unlikely to 
>>>>>gain traction, I think.
>>>>>
>>>>>  Cheers,
>>>>>
>>>>>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 28 Jan 2015 10:10:17 +0000

I haven't been following this discussion fully so apologies
if this was covered but I think I've seen various emails in
this thread that are assuming that ALPN will be a reliable
way to know what protocol is being carried within TLS. Now
that may be true to an extent today, but please bear in mind
that ALPN was selected over NPN mostly because it required
less change to TLS and could thus be more easily deployed.
At the time that the TLS WG made that decision, I believe
that they did intend that ALPN values would be encrypted in
the TLS1.3 handshake, thus restoring that feature of NPN
that had been dropped for pragmatic reasons.

So if the httpbis WG want to make some future uses of ALPN
that call for a middlebox to be able to see the value, then
I think you should communicate with the TLS folks to see what
they plan for this in TLS1.3. (I don't recall that having
been discussed since the ALPN/NPN discussions, but there
have been a few TLS WG interims that I wasn't at, so it may
have been.)

Cheers,
S.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 28 Jan 2015 11:36:48 +0100

Hi Mark,

On Wed, Jan 28, 2015 at 01:35:48PM +1100, Mark Nottingham wrote:
> Hi Amos et al,
> 
> Personally, I generally agree much of your concern here -- the ad hoc way in
> which ALPN identifiers sprung up always made me nervous (and I've expressed
> that a few times). It would be nicer if there were (dare I say it) a more
> well-defined architecture around ALPN-as-protocol-identifier.
> 
> HOWEVER, in this case we're not talking about a negotiation mechanism, nor
> are we trying to allow intermediaries to parse the contents of the
> semantics of the application inside the tunnel, so as to enable application
> of policy.
> 
> E.g., if the content is WebRTC, the network might want to apply different
> QoS, or refuse the tunnel because they're extremely bandwidth-constrained.
> 

Yes it still makes a difference for banner protocols. For example, if you
pass POP in clear, the proxy must not disable quick-ack like it can do for
TLS since the first packet of the connection will be sent by itself.

That's why I think it's reasonable to consider that, as a first step, we
could have something which satisfies exactly what Martin needs (eg: repeat
in a header field what is supposed to be advertised in the TLS ALPN), and
to ensure that the name of this header doesn't make it difficult to later
add information about what is being tunnelled (eg: TLS vs VPN vs anything
else).

Regards,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Jan 2015 09:59:02 -0800

> add information about what is being tunnelled (eg: TLS vs VPN vs anything

I have no objection to other signals, certainly.

The other signals are much harder to conceptualize.  I'm not opposed
to exposing more information if it can be justified and worked into a
solution.  If someone has a need, they should develop a solution
around that need and propose it.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 29 Jan 2015 08:38:06 +0100

> around that need and propose it.

I agree, let's not conflate all needs. I think you should rename your
header field to something like "Tunnel-ALPN" or something like this,
explicitly mentionning ALPN.

In parallel, I think Adrien made a good point about some ambiguities
regarding the transported protocols (sometimes advertised as the legacy
protocol transported over TLS, sometimes as the TLS variant of the
protocol). h2/h2c is probably what ignited the beginning of the confusion,
but as long as you copy the same protocol IDs in your header as present
in the TLS handshake, this issue is out of the scope of this WG.

That's why I think it makes sense to declare that you're simply mirroring
the ALPN value whatever it is, regardless of whether it makes sense or not,
and how you encode it. *That* is in the scope of this WG.

And as much as I would love to see a protocol declaration header field for
tunnels, it's something different and complementary to your work that can
be worked on later (maybe Adrien, Amos and I could work on this later).

Regards,
Willy