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

Scott Kelly <scott@hyperthought.com> Wed, 10 June 2015 20:10 UTC

Return-Path: <scott@hyperthought.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC3EC1A9112 for <secdir@ietfa.amsl.com>; Wed, 10 Jun 2015 13:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPajBQqZU48S for <secdir@ietfa.amsl.com>; Wed, 10 Jun 2015 13:10:36 -0700 (PDT)
Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 904C71A90CD for <secdir@ietf.org>; Wed, 10 Jun 2015 13:10:36 -0700 (PDT)
Received: from smtp9.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp9.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AA83E3804F4; Wed, 10 Jun 2015 16:10:35 -0400 (EDT)
Received: by smtp9.relay.iad3a.emailsrvr.com (Authenticated sender: scott-AT-hyperthought.com) with ESMTPSA id 893293804EE; Wed, 10 Jun 2015 16:10:34 -0400 (EDT)
X-Sender-Id: scott@hyperthought.com
Received: from [192.168.128.56] (c-76-21-94-29.hsd1.ca.comcast.net [76.21.94.29]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.4.2); Wed, 10 Jun 2015 20:10:35 GMT
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Scott Kelly <scott@hyperthought.com>
In-Reply-To: <CABkgnnXeZpzxpQwzxrTpJJMcaWFdhh6zxNBEdFnwssychNX2Lg@mail.gmail.com>
Date: Wed, 10 Jun 2015 13:10:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5604BEA6-52ED-455C-A8EF-0418CB874BA7@hyperthought.com>
References: <DA0CCE5D-D67A-4AD0-8DCB-87F0F397D342@hyperthought.com> <CABkgnnUPmUQq6VaCKWu8=yZUABScbzTfoNQMwrg-Nr511R-XRQ@mail.gmail.com> <93D1B0AD-7CA0-4143-9687-A9CE05170120@hyperthought.com> <CABkgnnXeZpzxpQwzxrTpJJMcaWFdhh6zxNBEdFnwssychNX2Lg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/QOY2h6BO8HGQLSS1SKJjdjsdczk>
Cc: draft-ietf-httpbis-tunnel-protocol.all@tools.ietf.org, The IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-httpbis-tunnel-protocol-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jun 2015 20:10:43 -0000

On Jun 10, 2015, at 1:02 PM, Martin Thomson <martin.thomson@gmail.com>; wrote:

> On 10 June 2015 at 12:09, Scott Kelly <scott@hyperthought.com>; wrote:
>> 
>> +          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.
> 
> 
> 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.

Yes.

Thanks,

Scott