IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Tue, 09 June 2015 21:33 UTC

Return-Path: <martin.thomson@gmail.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 EB5491A1B4B; Tue, 9 Jun 2015 14:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 leY42f4Ulb12; Tue, 9 Jun 2015 14:33:33 -0700 (PDT)
Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2413C1A1B5B; Tue, 9 Jun 2015 14:33:33 -0700 (PDT)
Received: by yhid80 with SMTP id d80so12621107yhi.1; Tue, 09 Jun 2015 14:33:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=5VBsK/3uXe4YyD17jS7MnJ8WcdXjhibSPHHMyYh/IQw=; b=A7Acutq3M/dzdMyvwGGAMMN8gI3YBWMB0T50717QZ3MutpIa4JohT/k8hbamOsg2eL 0Dss+nMC4QcL3aI8HvSaDVIM47KhI18WgQ9UJN54Ab0BFoVGk0UMK39+Rhr0Lo/cYHR6 RP/cmXgQOCzrR8YFuYQi3OFpN9Yv9B/uB31/QFpl98v5NXULCZvcwTs8PEYnLtpCZrRW b7JX27jrD7DIVhLSYnpF5dIGO7P8KQKxDC/ecyOy0FBBVMxj2F7fN77vItrTq5VZQ24i nbcQLF84pX70sI2G7tmLZb2DVt+smtj0HJpH2hWS1NU/6E62TuN4gw3QEisrgQOC2d3J 03Cw==
MIME-Version: 1.0
X-Received: by 10.170.112.18 with SMTP id e18mr27815527ykb.101.1433885612354; Tue, 09 Jun 2015 14:33:32 -0700 (PDT)
Received: by 10.129.110.138 with HTTP; Tue, 9 Jun 2015 14:33:32 -0700 (PDT)
In-Reply-To: <DA0CCE5D-D67A-4AD0-8DCB-87F0F397D342@hyperthought.com>
References: <DA0CCE5D-D67A-4AD0-8DCB-87F0F397D342@hyperthought.com>
Date: Tue, 09 Jun 2015 14:33:32 -0700
Message-ID: <CABkgnnUPmUQq6VaCKWu8=yZUABScbzTfoNQMwrg-Nr511R-XRQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Scott Kelly <scott@hyperthought.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/xTHAGheSahS5nxAcwiCb0CtPTQQ>
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: Tue, 09 Jun 2015 21:33:37 -0000

On 5 June 2015 at 05:24, Scott Kelly <scott@hyperthought.com> 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:

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.

v2.23.0 | Report a Bug | By Email