Re: [TLS] A la carte handshake negotiation

David Benjamin <> Fri, 26 June 2015 19:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B790C1A1BEA for <>; Fri, 26 Jun 2015 12:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.511
X-Spam-Status: No, score=0.511 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OXuSmcFqc3Df for <>; Fri, 26 Jun 2015 12:02:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FA731A6EDE for <>; Fri, 26 Jun 2015 12:02:43 -0700 (PDT)
Received: by igblr2 with SMTP id lr2so19334670igb.0 for <>; Fri, 26 Jun 2015 12:02:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=A7qaJvXmGg9RZNk7nF2KAdkzzpo7fpevZCJdeLSlqt4=; b=pbSG5DbNHzurdfYXN41orLnUEN69q6vuBtqigKg5xYy5bJ79hdBx/mUfLEYtll1j1y oYs7tJZqkBN32kZUz+n2jRjFYD+zMhDqVcTCyT/POv+uqg0wB/pWU0L4yRuq++dg4TSu cG52VeP1IKD+nTs2e6ewbLuf9rLYJxY8M9H+ei9plBGQOatogDJlmbD9gSzHpwC3iYmh VJeUOqB2RVaJRCaQymbEkPKHNMm7uihlJTd1X5jcCdekWcKL/zFiWXxNtmyFbuQVWi6c ZB5nw3UZcAHX7zZokk/xQoB1sudsw0AGGK8UQFj8lHzojqk7HrsZ3JlDkcdyl7rGZCM6 8lIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=A7qaJvXmGg9RZNk7nF2KAdkzzpo7fpevZCJdeLSlqt4=; b=O5rqgfiUv095QUpxMllI0eAChEqLreQgyOVOlIR+q/D0q7whHvEdHi3xzaV4RrHd+J A7EZw1TpQ6Zu5AH4/zKEhhTJ0U/PtNHZIwRmHTjz5fJ1ATx8GdCMudKKMVAHqEHTqolg yiv+70xFo8eKAtF8uMOVPRjnowT2sku2RaNzwG7CzV/KK6m9qXJ5y7yGTtELJTh7Sr69 U6k3GfovHyQ0p38Pi7LR/EkbQXopZc4AK/2WyO6B4SqlRBuQBzMlsGgio6EaH5T/r0Lp oie622mgEw6tqKyKoSCRE3JxBm1c+ABy4e1GGLEXshQv45sMUAVVL077wQXiaelmxMWj GClg==
X-Gm-Message-State: ALoCoQlLINQC+pRuyMYLOa8ukDFT9YKNBHWlSS9cCyPJzmbkTv4SlipVowSN5AHKYEqb/W0eNwwA
X-Received: by with SMTP id m25mr3884379ioi.92.1435345362125; Fri, 26 Jun 2015 12:02:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <20150616233111.GD6117@localhost> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 26 Jun 2015 19:02:32 +0000
Message-ID: <>
To: Dave Garrett <>, Nico Williams <>
Content-Type: multipart/alternative; boundary=001a113fc24c70d13c05197062a0
Archived-At: <>
X-Mailman-Approved-At: Sun, 28 Jun 2015 11:30:38 -0700
Cc: "<>" <>
Subject: Re: [TLS] A la carte handshake negotiation
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jun 2015 19:02:48 -0000

On Wed, Jun 17, 2015 at 1:31 AM Dave Garrett <> wrote:

> [snip]
> Ok, I revised the drafts and forked the anon deprecation changeset.
> Main draft proposal:
> Version with deprecated anon suites:
> Note that both totally deprecate all DH(E) suites, as that's one of the
> goals here. (due to weak DH params, old Java choking, & etc.) Thus, all
> suites must be ECDHE prefixed for TLS 1.3 support under these proposals
> (with the exception of plain PSK). All ECDHE suites would be capable of
> negotiating either ECDHE or DHE using string groups via the extension.
> PSK & anon will need a litany of new ECDHE suites to be defined. There is
> currently no ECDHE AEAD anon suite, thus none supporting TLS 1.3 (among the
> reasons I pursued the idea of merging it into PSK).
> I'm fine with relegating the anon deprecation idea to the bin if we agree
> to define all the new suites we need to maintain support. Getting
> ECDHE_anon into the ChaChaPoly draft would be a start.

I have the same concerns with this version as before. I don’t believe it
lowers the risk of accidental interop failure---if anything, it makes it

This scheme is still a problem for Chrome on Windows XP. This proposal
effectively makes ECDSA (and ECDHE) MTI for any clients doing the standard
PKI-based handshake. Whether or not this is desirable, it certainly should
be spelled out clearly in the spec.

Imagine how implementations look. Most allow configuring the cipher suite
list. This now interacts subtly with configuring 1.3 ciphers, and we have
the same interop risks of a parallel extension. What if the consumer, for
whatever reason, omitted the ECDHE_ECDSA variant of some AEAD but included
ECDHE_RSA? Now 1.2 servers work, 1.3 ones don’t. Alright, so what if we
internally checked for consistency? That’s fine, but we could just as
easily have checked for consistency between 1.2 cipher suites and a new 1.3

A separate extension avoids any mixing of semantics and gives a clean break
from the old pre-multiplied scheme.

As for what this extension contains, I don’t have strong opinions over
whether we go a la carte---pruning down to the GCMs and CHACHA would also
address the explosion---but if we bother, it seems a list of AEAD or
AEAD+PRF is correct. The key exchange is already consistently separated
from the bulk cipher in TLS. It's a waste to ignore the one clear boundary
that we actually have.

If the worry is state-machine bugs due to PKI and PSK key exchanges being
different, we won’t guard against them by separating
No one would make ECDHE_PSK_WITH_AES_128_GCM_SHA256 use a codepath from
ECDHE_PSK_WITH_CHACHA20_POLY1305, so sufficiently similar cipher suites
will be funneled together anyway.