Last Call Review of draft-ietf-httpbis-tunnel-protocol-04
review-ietf-httpbis-tunnel-protocol-04-secdir-lc-kelly-2015-06-10-00

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