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
- [secdir] secdir review of draft-ietf-httpbis-tunn… Scott Kelly
- Re: [secdir] secdir review of draft-ietf-httpbis-… Martin Thomson
- Re: [secdir] secdir review of draft-ietf-httpbis-… Scott Kelly
- Re: [secdir] secdir review of draft-ietf-httpbis-… Martin Thomson
- Re: [secdir] secdir review of draft-ietf-httpbis-… Scott Kelly
- Re: [secdir] secdir review of draft-ietf-httpbis-… Martin Thomson