Subject: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04

From: Scott Kelly <[email-masked]>
Date: Fri, 5 Jun 2015 05:24:25 -0700

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

Sorry that this review is a few days late, I hope it is still useful.

This document describes a method for using the HTTP ALPN header with the HTTP CONNECT method. HTTP CONNECT is used to ask a proxy to establish a tunnel through which other protocols (possibly HTTP, but not necessarily) can be forwarded. Once established, the client encapsulates the tunneled protocol in HTTP, sends this to the proxy, and the proxy de-encapsulates and forwards the traffic, which may or may not be encrypted. 

The ALPN header allows the client to tell the proxy which protocol(s) it intends to encapsulate. This ALPN header is not authenticated, and the draft makes no reference to client authentication and/or other protocol security mechanisms, so I assume this exchange is not secured in any way.

In the introduction, it says
   
   "When the CONNECT method is used to establish a tunnel, the ALPN
   header field can be used to identify the protocol that the client
   intends to use with that tunnel.  For a tunnel that is then secured
   using TLS [RFC5246], the header field carries 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.

   The ALPN header field carries an indication of client intent only.
   An ALPN identifier is used here only to identify the application
   protocol or suite of protocols that the client intends to use in the
   tunnel.  No negotiation takes place using this header field.  In TLS,
   the final choice of application protocol is made by the server from
   the set of choices presented by the client.  Other substrates could
   negotiate the application protocol differently.

   Proxies do not implement the tunneled protocol, though they might
   choose to make policy decisions based on the value of the header
   field.  For example, a proxy could use the application protocol to
   select appropriate traffic prioritization.”

The security considerations section notes that the client may falsify the ALPN header, but it also implies that this could be used as input to an authorization decision:

   The ALPN header field described in this document is an OPTIONAL
   header field.  Clients and HTTP proxies could choose to not support
   the header and therefore fail to provide it, or ignore it when
   present.  If the header is not available or ignored, a proxy cannot
   identify the purpose of the tunnel and use this as input to any
   authorization decision regarding the tunnel.  This is
   indistinguishable from the case where either client or proxy does not
   support the ALPN header field.

In the last of the previously quoted paragraphs, there was a similar implication regarding policy (traffic prioritization). These both raised red flags for me (especially the use of “authorization decision”).

This header is unauthenticated, and therefore not trustworthy. The client and/or a bad actor between the client/proxy can modify this. Further, unless the proxy actively compares the ALPN content to the TLS ClientHello message, those values may be different. For these reasons, the ALPN header in unreliable for use in traffic policy decisions, and for security-relevant definitions of “authorization”, should never be relied upon.

Things I think should change:

The draft never says what the proxy should do if the client makes one claim in the ALPN header, but then does something different (including using different ALPNs in encapsulated TLS negotiations). Seems like it should.

Also, the draft seems to suggest that it is okay to use the ALPN for policy/authorization decisions. This is unreliable from a security perspective. At minimum, I think the draft should explicitly call this out.

—Scott

---

From: Martin Thomson <[email-masked]>
Date: Tue, 9 Jun 2015 14:33:32 -0700

> Sorry that this review is a few days late, I hope it is still useful.

Of course it is :)

> The ALPN header allows the client to tell the proxy which protocol(s) it intends to encapsulate. This ALPN header is not authenticated, and the draft makes no reference to client authentication and…

Correct.  It's a "forward-looking statement" that couldn't be validated anyway.

> Also, the draft seems to suggest that it is okay to use the ALPN for policy/authorization decisions. This is unreliable from a security perspective. At minimum, I think the draft should explicitly…

Stephen made similar comments in his review.  Those lead to the
addition of text:

https://github.com/httpwg/http-extensions/compare/6c7b987e2b25e...master

Does that help at all?  The intent is not to let this be used for
authorization decisions, but to allow a quick, clean "deny" decision
to be issued.  The current state of play is pretty messy in that
regard.

Other changes (based on other reviews) resulted in more emphasis on
this being a hint, or an indication of intent.

---

From: Scott Kelly <[email-masked]>
Date: Wed, 10 Jun 2015 12:09:18 -0700

Hi Martin,

Comments below.

> this being a hint, or an indication of intent.

I looked at the modification at the github link above, but I still have the same impression when I read the text.

RFC3552 gives guidelines for writing security considerations text, and one of the stated aims is to inform the reader of relevant security issues. I don’t think the current language does this. It states that the proxy may make policy/authorization decisions based on the ALPN header value (implying that this is generally okay). This has security implications that a non-security-savvy person may not understand.

The new language says (in part),

+          A proxy can use the value of the ALPN header field as input to
+          authorization decisions.  The header field exposes protocol
+          information at the HTTP layer, allowing authorization decisions to be
+          made earlier, with better error reporting (such as a 403 status code).

The term “authorization” evokes notions of security, at least for me. This text gives me the impression that the ALPN header is suitable for use in security decisions.

I can think of a couple of ways to address this. One easy way is to replace “authorization” with something more security-neutral (“filtering”? “allow/deny”?). Another is to simply add a statement saying this header may be falsified by either the client or a MitM, and therefore should not be relied upon for security-relevant decisions unless additional security measures are applied.

—Scott

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jun 2015 13:02:25 -0700

> I can think of a couple of ways to address this. One easy way is to replace “authorization” with something more security-neutral (“filtering”? “allow/deny”?). Another is to simply add a statement s…

Would it make more sense like this?

          A proxy can use the value of the ALPN header field to more cleanly and
          efficiently reject requests for a CONNECT tunnel.  Exposing protocol
          information at the HTTP layer allows a proxy to deny requests earlier,
          with better error reporting (such as a 403 status code).  The ALPN
          header field can be falsified and is therefore not sufficient basis
          for authorizing a request.

---

From: Scott Kelly <[email-masked]>
Date: Wed, 10 Jun 2015 13:10:32 -0700

>          for authorizing a request.

Yes.

Thanks,

Scott

---

From: Martin Thomson <[email-masked]>
Date: Wed, 10 Jun 2015 14:28:39 -0700

>>          for authorizing a request.

Thanks Scott.

https://github.com/httpwg/http-extensions/commit/3fb72e95