Re: [TLS] A la carte handshake negotiation

David Benjamin <> Fri, 26 June 2015 20:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C94B1ACDCD for <>; Fri, 26 Jun 2015 13:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9VywOsqU5z7K for <>; Fri, 26 Jun 2015 13:56:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B51E31ACDB6 for <>; Fri, 26 Jun 2015 13:56:24 -0700 (PDT)
Received: by igblr2 with SMTP id lr2so21070031igb.0 for <>; Fri, 26 Jun 2015 13:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=AWr4JF6GmIxvvaLf9fJkMr3rHg/bZyJ05w6qrAehP6M=; b=hGqR1BYNWf81ePafKgChtMNR5mAeHR0x3Zvhe8zBvfN6eJJV4GqvqXmjlqOtpXp2rd C5mC8T1Pt3IP24klfPeoknN8GVYKclpn0NxDtUG1dJ8R4Ei5Euo33U3kGhNdqkBWTPY0 MwDJmua68lHpAeYrjkDOj8sLwMcZlwsIiMbW4=
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=AWr4JF6GmIxvvaLf9fJkMr3rHg/bZyJ05w6qrAehP6M=; b=UHx/sV7CXH54+2vXigD+hiazQXCtkiVGNzX4+BuSpp46NVR8H8691JoSN+WoQ+DQkk r82wvxbtYleQ96M+uRNoGZGvhO2b0efIxYE+QOFHLvk2UfYGhcC5H6qc2lzOLZ9IsuKb pPc/F64FuW9OI8dflSbpPMnt5XjPRdXjMJ+TkwOp1cTO4xJTuQGXIFnfJDuOjq7pYVv4 JCgXl39JzFelAOC2Rm1A0yGo0zFVNPXjvMfNPVAbRUS4q5HvkBWfmuJJTUsOcW5f13JY s3+Yr4Tl0GjXVO5GHrY5MwlsAh5hh6cVCjF52x+pnStCvmPNHkKJRwqXy/2WLX6BwnfM Z6oQ==
X-Gm-Message-State: ALoCoQn1GBIt/8QdaO4vY0SXbY6w3U4qHCW4sPjU1LVrBmEjj5t/OK7w/nOMwhLnXDe5/xHmnhqs
X-Received: by with SMTP id a10mr5664069ict.49.1435352184210; Fri, 26 Jun 2015 13:56:24 -0700 (PDT)
MIME-Version: 1.0
References: <> <20150616233111.GD6117@localhost> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 26 Jun 2015 20:56:14 +0000
Message-ID: <>
To: Dave Garrett <>, Nico Williams <>
Content-Type: multipart/alternative; boundary=bcaec55237801169d3051971f90a
Archived-At: <>
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 20:56:27 -0000

[Oops. I sent this from the wrong address the first time so it didn't get
through to the broader list. Apologies for messing up the threading.]

On Fri, Jun 26, 2015 at 3:02 PM David Benjamin <> wrote:

> 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
> worse.
> 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
> mechanism.
> 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.
> David