Re: [TLS] A la carte handshake negotiation

Dave Garrett <> Sat, 13 June 2015 01:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9B7CA1A89F0 for <>; Fri, 12 Jun 2015 18:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lmd8moqxQh5N for <>; Fri, 12 Jun 2015 18:45:18 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D23F91A89C7 for <>; Fri, 12 Jun 2015 18:45:17 -0700 (PDT)
Received: by qkhg32 with SMTP id g32so25043212qkh.0 for <>; Fri, 12 Jun 2015 18:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:mime-version:content-type :content-transfer-encoding:message-id; bh=bdWRL9hqf1keTWmvVtA0MHlP1ldDOiD7u/UtchJUt2I=; b=spxLKxRntKIP+YSkBf2Xq7LLeZOPk0JI3YpZP9GLzkt3lswnb8rfSo6digGx4gywwC QkWMNFRpxgbvX17FA6PEZnH9vEH8Ck8r/jofMFB4BtX/509zaNrjrt+ZyxQVDQzd2mid SRCsPrDO1obCaZUlQpeLmLM2Qm94jJxNh7ZK1hzBbIkF7MtO6mBCASmrsyXx/qvH+s1V VQBYHKBT2BzqCLXYmstzXLMQQIPC2z5kkLugoaekuIpo3vflkbvXdu5AyEIBu5x4QAJP O1QKCrer1lLDVgjlSLL5sgYoIqryx/dEOMlEUkYAcxziM6vWkCA0UGwSz23cl/X+q0wp CQDg==
X-Received: by with SMTP id o7mr36818957qkh.81.1434159917178; Fri, 12 Jun 2015 18:45:17 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id q105sm2502379qgq.11.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 12 Jun 2015 18:45:16 -0700 (PDT)
From: Dave Garrett <>
Date: Fri, 12 Jun 2015 21:45:13 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
Archived-At: <>
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: Sat, 13 Jun 2015 01:45:19 -0000

Based on the discussions today, I've significantly revised the text of this proposal. This new draft goes into more detail for the PSK & anon cipher suites.

Of note, I've added a table to state what's available to negotiate with what. It's longer than it should be because both DHE_PSK and DH_anon should be dropped from there, but for now I've included them because ECDHE_PSK and ECDH_anon AEAD cipher suites have yet to be standardized. There's expired drafts for these and if PSK and anon are to be considered fully compatible with TLS 1.3, then these really should be defined. Merging them together into one I-D for AEAD ECDHE cipher suite assignments seems like the simplest route.

I'd also rather plain (symmetric-only) PSK be relegated to its own specifications and not included here, but I've included it in the table for now. ECDHE_PSK should ideally be the only supported PSK handshake. Plain PSK has no FS and it was generally agreed that TLS 1.3+ should be FS only.

New draft text:
Diff with master:

I think there might've been some discussion on this list in the past about potentially adding PSK to the SignatureAlgorithm enum for the "signature_algorithms" extension. This could obsolete all ECDHE_PSK and DHE_PSK cipher suites and allow PSK negotiation via normal ECDHE_ECDSA cipher suites and the extension. I'm not sure if this would be desired or not. I'm not proposing this currently, but I'm not against also doing this, though.

To reiterate from the anon discussion, the "signature_algorithms" extension already defines `anonymous(0)` and has an explicit prohibition on it ever being included. Obsoleting ECDH_anon and DH_anon and switching to this extension for negotiation would require either hacking in a second anonymous value to replace it (bad idea, IMO) or changing the extension spec to allow the existing value, which might break things expecting otherwise. Personally, I think anon should have its own cipher suite and not be negotiated via the signatures extension, as it is not a valid option for normal use-cases. (paranoid exploit worry: a bad implementation could muck up extension handling and negotiate anon when it shouldn't; safer to just keep it separate) Arguably, PSK isn't a valid option most of the time either, but it can't be negotiated without a pre-shared key actually being pre-shared, so using the extension for it might be viable. If ECDH_anon suites are defined, anon will be able to negotiate DHE/ECDHE via the "supported_groups" extension, so it would only be one anon suite per symmetric cipher.

Also note that non-standards-track ciphers are still listed in there, but may be dropped prior to merge. Promoting ECDHE AES-CCM from informational to standards track would be a good idea if we only want to include standards track ciphers here. AES-OCB will be added whenever its draft has a temporary codepoint to include.