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

Scott Kelly <> Wed, 10 June 2015 19:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 11FA11A86FA for <>; Wed, 10 Jun 2015 12:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eeDExXHV0Saz for <>; Wed, 10 Jun 2015 12:09:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F3C51A8029 for <>; Wed, 10 Jun 2015 12:09:21 -0700 (PDT)
Received: from (localhost.localdomain []) by (SMTP Server) with ESMTP id A430C380533; Wed, 10 Jun 2015 15:09:20 -0400 (EDT)
Received: by (Authenticated sender: with ESMTPSA id BF0DC380469; Wed, 10 Jun 2015 15:09:19 -0400 (EDT)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA) by (trex/5.4.2); Wed, 10 Jun 2015 19:09:20 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Scott Kelly <>
In-Reply-To: <>
Date: Wed, 10 Jun 2015 12:09:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc:, The IESG <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 10 Jun 2015 19:09:23 -0000

Hi Martin,

Comments below.

On Jun 9, 2015, at 2:33 PM, Martin Thomson <> wrote:

> On 5 June 2015 at 05:24, Scott Kelly <> wrote:
>> 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/or other protocol security mechanisms, so I assume this exchange is not secured in any way.
> Correct.  It's a "forward-looking statement" that couldn't be validated anyway.
>> 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.
> Stephen made similar comments in his review.  Those lead to the
> addition of text:
> 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.

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.