Subject: I-D Action: draft-ietf-httpbis-tunnel-protocol-00.txt

From: [email-masked]
Date: Mon, 18 Aug 2014 16:38:39 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Hypertext Transfer Protocol Working Group of the IETF.

        Title           : The Tunnel-Protocol HTTP Request Header Field
        Authors         : Andrew Hutton
                          Justin Uberti
                          Martin Thomson
	Filename        : draft-ietf-httpbis-tunnel-protocol-00.txt
	Pages           : 5
	Date            : 2014-08-18

Abstract:
   This specification allows HTTP CONNECT requests to indicate what
   protocol will be used within the tunnel once established, using the
   Tunnel-Protocol request header field.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-tunnel-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Aug 2014 10:44:09 +1000

Everyone,

As discussed, this is a new work item. Please have a look and raise any questions or issues; it isn't very complex or big, so I anticipate going to WGLC pretty quickly.

Cheers,

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

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 20 Aug 2014 10:40:28 +1000

Mark,

Is there a specific use-case motivating this additional header?   ie are
there situations that a proxy can use this to do more than just log/debug a
tunnel?

I'm certainly not opposed to having the additional information that this
header provides, but I'd like to know what advantage there is for a client
to include the header.  If there is none, then it is not likely to be sent.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Aug 2014 10:45:12 +1000

Greg, 

See:
  https://httpwg.github.io/wg-materials/ietf90/IETF90_draft-hutton-httpbis-connect-protocol.pdf
  https://github.com/httpwg/wg-materials/blob/gh-pages/ietf90/minutes.md#draft-hutton-httpbis-connect-protocol

Cheers,

On 20 Aug 2014, at 10:40 am, Greg Wilkins <[email-masked]> wrote:

> Mark,
> 
> Is there a specific use-case motivating this additional header?   ie are there situations that a proxy can use this to do more than just log/debug a tunnel?  
> 
> I'm certainly not opposed to having the additional information that this header provides, but I'd like to know what advantage there is for a client to include the header.  If there is none, then it is not likely to be sent.
> 
> cheers
> 
> 
> 
> 
> 
> --

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 20 Aug 2014 11:09:49 +1000

Mark,

thanks for those links.

I think the document itself needs to be a bit stronger on the intended
usage of the header.  Currently it reads that this header field can be sent
by a client and that it can be ignored by the proxy.  Perhaps it should be
little bit stronger and say that a proxy MAY (SHOULD?) consider this header
when deciding to create a tunnel or not.

cheers

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Aug 2014 11:12:39 +1000

On 20 Aug 2014, at 11:09 am, Greg Wilkins <[email-masked]> wrote:

> 
> Mark,
> 
> thanks for those links.
> 
> I think the document itself needs to be a bit stronger on the intended usage of the header.  Currently it reads that this header field can be sent by a client and that it can be ignored by the proxy.

That's the intent.

> Perhaps it should be little bit stronger and say that a proxy MAY (SHOULD?) consider this header when deciding to create a tunnel or not.

We can't retroactively require proxies to pay attention to a header; it's up to them. This header is merely enabling those proxies who choose to act upon the header. 

(Yes, that corresponds to MAY, but we try to avoid overusing it, else our documents get filled with MAYs. It's not really a conformance requirement, it's just a statement.)

Cheers,

---

From: Adam Rice <[email-masked]>
Date: Thu, 21 Aug 2014 13:50:03 +0900

As a client, why would I add a header to my request that is going to cause
the proxy to block it? What is the benefit to the user?

On 20 August 2014 10:12, Mark Nottingham <[email-masked]> wrote:

> by a client and that it can be ignored by the proxy.
>
> That's the intent.
>
> > Perhaps it should be little bit stronger and say that a proxy MAY
> (SHOULD?) consider this header when deciding to create a tunnel or not.
>
> We can't retroactively require proxies to pay attention to a header; it's
> up to them. This header is merely enabling those proxies who choose to act
> upon the header.
>
> (Yes, that corresponds to MAY, but we try to avoid overusing it, else our
> documents get filled with MAYs. It's not really a conformance requirement,
> it's just a statement.)
>
> Cheers,
>
>
> >
> > cheers
> >
> >
> >
> >
> >
> >
> >
> >
> > > Is there a specific use-case motivating this additional header?   ie
> are there situations that a proxy can use this to do more than just
> log/debug a tunnel?
> > >
> > > I'm certainly not opposed to having the additional information that
> this header provides, but I'd like to know what advantage there is for a
> client to include the header.  If there is none, then it is not likely to
> be sent.
> > >
> > > cheers
> > >
> > >
> > >
> > >
> > >
> > > --

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 21 Aug 2014 18:37:04 +1200

> the proxy to block it? What is the benefit to the user?

Right now there are large numbers of admin who are forced to decrypt TLS
just to determine if the traffic is Skype, HTTPS, your application, or
some attack. This is a nasty situation and getting worse.
 As senders in the TLS arms race improve their use so that it cannot be
hijacked and decrypted these admin are turned towards the last resorts
of a) completely rejecting CONNECT tunnels, or b) configuring an open
proxy, or c) walled garden software environments for clients.

* if the proxy is blocking your traffic because of that header then you
are by definition one of the "bad guys" on that network until unblocked.
Try not to tar your reputation further by forcing issues ;-)

* sending it allows use of your application on networks which do
consider it a "good guy" and would otherwise have a blanket denial on
CONNECT traffic.

* sending it allows proxies to make the required security decisions
without having to hijack and decrypt any traffic.

* if use of this header is picked up widely then we will be headed
toward a situation where more proxies can relatively safely have blanket
rejection on CONNECT traffic omiting it, a lot of current day attacks
will fail, and BCP 188 Pervasive Monitoring stops being pervasive.

Allowing those admin to avoid decryption or open-proxy is a net gain for
both your application and everybody else as well.

Amos

---

From: Adam Rice <[email-masked]>
Date: Thu, 21 Aug 2014 17:07:31 +0900

> will fail, and BCP 188 Pervasive Monitoring stops being pervasive.

I don't believe that anyone who has the capability to intercept and decrypt
traffic will voluntarily give it up.

Since it is trivial for malware to forge this header, I do not believe it
will stop any attacks.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 22 Aug 2014 02:50:49 +1200

On 21/08/2014 8:07 p.m., Adam Rice wrote:
> On 21 August 2014 15:37, Amos Jeffries wrote:
> 

Decryption costs $$. Also the entire traffic stream must be decrypted
("pervasive" remember). A fast way to filter out some of the traffic and
target the decryption has positive pressure to adopt for cost reduction
even by those who have the capability.

> Since it is trivial for malware to forge this header, I do not believe it

It will change the attacks which are possible and how difficult they
are. Today it is trivial to send a CONNECT with arbitrary payload to a
large number of networks and proxies. After the header they will have to
make the attack work while simultaneously spoofing bits of the internal
protocol which DPI systems can now validate.

eg. the header conveys that TLS/1.3 is being transmitted and the data
actually contains a SSL/1.0 client hello (or something not even parsing
as a client hello at all).

Then there is the whole area of signed messages that make the header
content a fixed and reliable detail while in the clear for proxies.

Amos

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Aug 2014 09:55:05 -0700

> the proxy to block it? What is the benefit to the user?

I'm going to give a different answer to the one Amos gave.  You can
read the background, including the recorded discussion from the last
IETF meeting for more on the subject.

In WebRTC, browsers will do this because they want to be good network
citizens and sometimes that means asking nicely.  Applications don't
get that privilege.

And this isn't always about a block/don't block binary decision.
Sometimes the information can let the proxy make better choices about
how it treats the data.  Realtime media over these tunnels (the
original motivating use case) has somewhat different requirements to
other types of traffic.  Knowledge about applications can help the
proxy make better decisions.

As I've said privately to others when the same point was raised, the
use of cleartext markers in the context of intermediary blocking is a
topic that was discussed at some length when the TLS working group
chose ALPN over NPN.  We could re-run those arguments, and I'm sure
that we'd have a ball in the process, but that's wasteful.  This
document really doesn't change the dynamic at all.  If you choose not
to send this, then send ALPN, then that's just forcing the proxy to do
extra work to discover what you are doing (i.e., it looks at your TLS
ClientHello once the tunnel is active).

If you are suppressing ALPN, then you suppress this too.  I don't
think that's in question.

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Thu, 21 Aug 2014 17:08:00 +0000

+ 1

> -----Original Message-----
> From: Martin Thomson [mailto:[email-masked]]
> Sent: Thursday, August 21, 2014 11:55 AM
> To: Adam Rice
> Cc: Mark Nottingham; Greg Wilkins; HTTP Working Group
> Subject: Re: I-D Action: draft-ietf-httpbis-tunnel-protocol-00.txt
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 22 Aug 2014 11:58:15 +0200

Hi there,

below comments on the current version in git:

>    The HTTP Tunnel-Protocol header field identifies the protocol that
>    will be spoken within the tunnel, using the application layer next
>    protocol identifier [RFC7301] specified for TLS [RFC5246].

Maybe intro "ALPN" here?

>    When CONNECT is used to establish a TLS tunnel, the Tunnel-Protocol
>    header field may be used to carry the same next protocol label as was
>    carried within the TLS handshake.  However, the HTTP-Protocol is an

"HTTP-Protocol"? Typo?

> 2.  The Tunnel-Protocol HTTP Request Header Field
>
>    Clients include the Tunnel-Protocol Request Header field in a HTTP
>    Connect request to indicate the application layer protocol used

s/Connect/CONNECT/?

>    within the tunnel.

Should we say something about the semantics of the field name in 
requests other than CONNECT?

> 2.1.  Header Field Values
>
>    Valid values for the protocol field are taken from the registry
>    established in [RFC7301].

It would be more helpful to reference the IANA registry 
(<http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids>)...

> 2.2.  Syntax
>
>    The ABNF (Augmented Backus-Naur Form) syntax for the Tunnel-Protocol
>    header field is given below.  It is based on the Generic Grammar
>    defined in Section 2 of [RFC7230].

Section 2 of [RFC7230] doesn't define a "Generic Grammar".

>       Tunnel-Protocol = "Tunnel-Protocol:" protocol-id
>       protocol-id     = token ; percent-encoded ALPN protocol identifier

This should only define the field value (not the field name). See 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-alt-svc-latest.html#alt-svc> 
for an example.

>    ALPN protocol names are octet sequences with no additional
>    constraints on format.  Octets not allowed in tokens ([RFC7230],
>    Section 3.2.6) must be percent-encoded as per Section 2.1 of
>    [RFC3986].  Consequently, the octet representing the percent
>    character "%" (hex 25) must be percent-encoded as well.
>
>    In order to have precisely one way to represent any ALPN protocol
>    name, the following additional constraints apply:
>
>    o  Octets in the ALPN protocol must not be percent-encoded if they
>       are valid token characters except "%", and
>
>    o  When using percent-encoding, uppercase hex digits must be used.
>
>    With these constraints, recipients can apply simple string comparison
>    to match protocol identifiers.

(steal with pride :-)

>    For example:
>
>
>      CONNECT turn_server.example.com:5349 HTTP/1.1
>      Host: turn_server.example.com:5349
>      Tunnel-Protocol: turn

Do we need to state how to treat multiple field instances? (Any security 
concern here?)

> 3.  IANA Considerations
>    [[anchor6: To Be Added]]

Insert header field registration...

> 4.  Security Considerations
>
>    In case of using HTTP CONNECT to a TURN server the security
>    consideration of Section 4.3.6 of [RFC7231] apply.  It states that
>    there "are significant risks in establishing a tunnel to arbitrary
>    servers, particularly when the destination is a well-known or
>    reserved TCP port that is not intended for Web traffic.  Proxies that
>    support CONNECT SHOULD restrict its use to a limited set of known
>    ports or a configurable whitelist of safe request targets."
>
>    The Tunnel-Protocol request header field described in this document
>    is an optional header and HTTP Proxies may of course not support the

s/header/header field/

- avoid lowercase "may"; maybe say "might".

>    header and therefore ignore it.  If the header is not present or
>    ignored then the proxy has no explicit indication as to the purpose
>    of the tunnel on which to provide consent, this is the generic case

s/,/-/

>    that exists without the Tunnel-Protocol header.
>
> 5.  References
>
> 5.1.  Normative References
>
>    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>               Requirement Levels", BCP 14, RFC 2119, March 1997.
>
>    [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
>               Resource Identifier (URI): Generic Syntax", STD 66,
>               RFC 3986, January 2005.
>
>    [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
>               (HTTP/1.1): Message Syntax and Routing", RFC 7230,
>               June 2014.
>
>    [RFC7231]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
>               (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
>
>    [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
>               "Transport Layer Security (TLS) Application-Layer Protocol
>               Negotiation Extension", RFC 7301, July 2014.
>
> 5.2.  Informative References
>
>    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
>               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
> ...

Best regards, Julian