Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)

Martin Thomson <martin.thomson@gmail.com> Tue, 10 December 2013 17:03 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BB81AE20D for <tls@ietfa.amsl.com>; Tue, 10 Dec 2013 09:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4qqCtaUwyfAk for <tls@ietfa.amsl.com>; Tue, 10 Dec 2013 09:03:13 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBCE1AE1F9 for <tls@ietf.org>; Tue, 10 Dec 2013 09:03:13 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id t61so5329376wes.11 for <tls@ietf.org>; Tue, 10 Dec 2013 09:03:07 -0800 (PST)
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; bh=E0fScMPgurwtkRMgzjz11TkEwQdIaKtlB5iT0bfk4bc=; b=DHtHqk8i9DYtFbni2yLK5nAv6WA/eWjhzZ+F2LYbgzYHHvKFdNK3X/Zn/h3t6zHyHl 3o3usTW1YLyYDm3SyHMzptA7t2OJInS0sv4lvQVo8l+hvpFbrzNG05sd0zEdCp+r3KTl xAd2UntdWRJ+46mcUqlJv273ukIkOVy8cQ51TQJ55EiPOwp8G+dbgf9t0eCxeyOfn7Z/ srGaUAVjfe2cEweRNsurb2Z4aIb/ksevwvEAbSErCYmWP/z21Uu0fnfs4+nzBjtnwfHI +rraiU9v7j+ZdRriZHA4O7k0XB1TQ4y5mvkJzoDhn3XL10vXbGsB6/i5o6tjd5Mys4CD p5Aw==
MIME-Version: 1.0
X-Received: by 10.180.10.135 with SMTP id i7mr20202412wib.1.1386694987713; Tue, 10 Dec 2013 09:03:07 -0800 (PST)
Received: by 10.227.134.195 with HTTP; Tue, 10 Dec 2013 09:03:07 -0800 (PST)
In-Reply-To: <CAFewVt56ony-5LFewu4139Q-5qHEQqh8n9F0_GTOBt4Qz4zRqg@mail.gmail.com>
References: <CAFewVt5fNk9HF0uuE1Z_wD=8cme1eCuU8=VJU3RaLLCoPi2p+w@mail.gmail.com> <CABkgnnXpkoRsP5pqQcg-Baw02CEbPG1EdwsOpZ5uNHg7pa2mPA@mail.gmail.com> <CAFewVt56ony-5LFewu4139Q-5qHEQqh8n9F0_GTOBt4Qz4zRqg@mail.gmail.com>
Date: Tue, 10 Dec 2013 09:03:07 -0800
Message-ID: <CABkgnnVMGzZPTrv5qf5dnPom6aHdbhfwvaDiSG3CmVFLiVJMyg@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] How ALPN makes the http2-tls-relaxed option less secure, compared to NPN (was Re: ALPN concerns)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Dec 2013 17:03:15 -0000

On 9 December 2013 18:15, Brian Smith <brian@briansmith.org> wrote:
> If the server really doesn't care about the security or privacy
> properties of a resource, then it wouldn't implement opportunistic
> encryption in the first place, unless it was doing so purely as a
> compatibility hack.

I don't know that hack is the right word here.

One of the options that is being considered for HTTP/2.0 is the
mandatory implementation of unauthenticated TLS for http: URIs.  If
that were the case, all that a server would have to do is upgrade
their stack.  That sets a pretty low bar.

> we'd say that the client MUST NOT advertise
> the http2-tls-relaxed ALPN token, in order to avoid tipping off any
> MitM that the connection will be unauthenticated.

Yes, but that isn't the reason I'd use for it.  The reason is that
it's not necessary.  It's got absolutely nothing to do with tipping
anybody off.