Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Fri, 26 June 2015 23:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4FB311B2B1F for <>; Fri, 26 Jun 2015 16:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7uT-Z0hDpu5q for <>; Fri, 26 Jun 2015 16:18:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 137F71B2B1E for <>; Fri, 26 Jun 2015 16:18:51 -0700 (PDT)
Received: by ykdy1 with SMTP id y1so71825160ykd.2 for <>; Fri, 26 Jun 2015 16:18:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=eXMeFFmPdF7Xu0ReSb+vS6497N3Aemnxk2PDkMHa3sk=; b=jihZ1T7mIYWRCvgW4Ovtv9AA9WYjx0w8sb1Mutm7hJazFGbWFwQ7flRxWf+gl72PFf kVw1TrpR4BYI3rSfCTKUAjyCVkgVtYZIlHy8Mssc9jsXAxCrLIxbS6C6kWS1T1RCnDvJ LEz7IPc8ee1Wir2xqqW1rQ2FCWpUIPuofmhjksiEpXhyDZwVzXhr6+UxGsJ1gcIu+q9i 70UrWRKCVuu1DjBV3ym955kGJNmnTi5BWqlGyXMR5OBEfVkCA7ZAt8SYHhP8pl732arh ZBnGVk0UOEP580UbCNSUchLOHtolVXyR79ByhMNqeMg/+zJXJek4RINjEt2Um6BME8Bm 3QBg==
X-Received: by with SMTP id 205mr4940430ywh.133.1435360730362; Fri, 26 Jun 2015 16:18:50 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id w6sm27518307ywf.31.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 26 Jun 2015 16:18:49 -0700 (PDT)
From: Dave Garrett <>
To: David Benjamin <>
Date: Fri, 26 Jun 2015 19:18:47 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
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 23:18:52 -0000

On Friday, June 26, 2015 03:02:32 pm David Benjamin wrote:
> 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.

In the current draft proposal, ECDSA cipher suites are mandatory for TLS 1.3, but endpoints are not required to support ECDSA (extension does negotiation). Support expectation is clear: "SHOULD offer at least one ECDHE group and SHOULD offer support for ECDSA".

Clients on EOL OSes without ECC that don't have their own ECC implementations are broken. We shouldn't even consider trying to compensate for this in the spec. To implement the new spec, you have to write a new implementation, so no, relying on an old EOL OS implementation for a part of it into your implementation is not guaranteed to be enough. Vendors still doing this will need to either decide to actually implement things themselves or only support capable OSes.

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

Indeed. Again, I do not oppose this route. If we can agree on this, I have no problem with dropping my current approach to switch to it.

It is, however, a total break from cipher suites, which could make assessing configurations with mixed TLS version support a bit more complicated. Keeping bulk cipher negotiation in suites makes keeping track of server bulk cipher support a little easier.

> 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.

I think the best way to do this would be one byte for selecting the AEAD cipher and a second byte for selecting a key+hash size combination. This could be very helpful in the future when SHA3 and future new hashes get deployed, as anything would be capable of negotiating it if an appropriate size is available. Separating these two would give us full a la carte, which could be very helpful, but is also of course more complex.