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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 09 December 2013 17:11 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 C6D561ADFF4 for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 09:11:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8e5m-pNu5XOM for <tls@ietfa.amsl.com>; Mon, 9 Dec 2013 09:11:46 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0311ADFE2 for <tls@ietf.org>; Mon, 9 Dec 2013 09:11:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A151BE51; Mon, 9 Dec 2013 17:11:40 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ew6K4BC0ejhb; Mon, 9 Dec 2013 17:11:40 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7418ABE50; Mon, 9 Dec 2013 17:11:40 +0000 (GMT)
Message-ID: <52A5F9CC.5090603@cs.tcd.ie>
Date: Mon, 09 Dec 2013 17:11:40 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Watson Ladd <watsonbladd@gmail.com>, Brian Smith <brian@briansmith.org>
References: <CAFewVt5fNk9HF0uuE1Z_wD=8cme1eCuU8=VJU3RaLLCoPi2p+w@mail.gmail.com> <CACsn0cnXpQbsXgk7JQuDgc97RoQSa_=fmXOFsdiHeyT_qDAJKg@mail.gmail.com>
In-Reply-To: <CACsn0cnXpQbsXgk7JQuDgc97RoQSa_=fmXOFsdiHeyT_qDAJKg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
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: Mon, 09 Dec 2013 17:11:52 -0000

On 12/09/2013 04:59 PM, Watson Ladd wrote:
> Why exactly does the client need to tell the server if it will
> validate the cert or not?
> Either the server has a cert that will validate, in which case it can
> use it always, or not, in which case
> there isn't a choice. Why signal to the world "I CAN BE FOOLED"?

I'm not sure there's that much point in getting into
the specifics of Mark's scheme, since the httpbis wg
haven't decided to go down that road yet. (They might
but then they might do something else, who knows.)

For me (wearing no hats) it seems like standardising
NPN might take away energy from tls1.3 and/or slow
its deployment, which'd be a concern.

I'd also think that in the real case of ALPN and
HTTP/2.0 it'll be entirely obvious which protocol is
being negotiated just from the sizes of the packets
for any tls version <= 1.2 so any privacy loss or
gain is extremely minor to non-existent for now.
(That's because of HTTP/2.0 being binary etc.)

And I'd hope tls1.3 will be where we'd get significant
privacy gains in a more well thought out manner, e.g.
perhaps addressing the kind of application traffic
padding that Alfredo's draft described as a built-in
feature. (Or some equivalent.)

I've not thought through the negotiation thing though,
i.e. as to the impact of clients still having to be
able to do tls1.2 & ALPN for HTTP/2.0 even after tls1.3
is available on both ends. That does sound like its
worth thinking through but I'd hope could be handled
well in tls1.3 while still getting the privacy
benefits.

S.