Re: [TLS] Ala Carte Cipher suites - was: DSA should die

Dave Garrett <> Sat, 04 April 2015 15:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 38C261B2BD2 for <>; Sat, 4 Apr 2015 08:41:49 -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_52=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qurl077pBntu for <>; Sat, 4 Apr 2015 08:41:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 100F01B2BD0 for <>; Sat, 4 Apr 2015 08:41:48 -0700 (PDT)
Received: by qgdy78 with SMTP id y78so46924626qgd.0 for <>; Sat, 04 Apr 2015 08:41:47 -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=0kOBYiJEznf5YAsyqfdRDskuVNKB2IEIbtPXHUPd8Cs=; b=rltv+aDbM9IL9ANlKfb16ev2XeDNYgTPMib0TpC2mvnrXTQMynh0Cmz2YN5uVWKwc/ soAmhzcAz75AujL/8JgNviZ5C7kRZEq+xlOY+mn5EQeDWvLobDUF7bHGVpUHO53K3aOH w+ZwqTmYVdGdaBSdE9DUqf8zOMWtOG/y01rtaoX2bFbik/911ODv2T9EzjuZjUwf/sNn pJZtnXOFaMc8jOCOYDRHhpAxFZss52tWmamp9eMzFpnsAVh3LPT1xGIeqmeGZJSIQHsQ 5YOkX/gHs5xJdBi2QKMekWNeKMHzCrWdnMJ3z/1jl64tETJqQqLlslQmj6RYz06KzNpZ U6Vg==
X-Received: by with SMTP id x138mr8627841qha.14.1428162107355; Sat, 04 Apr 2015 08:41:47 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id m68sm8032622qge.15.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 04 Apr 2015 08:41:46 -0700 (PDT)
From: Dave Garrett <>
To: Aaron Zauner <>
Date: Sat, 4 Apr 2015 11:41:38 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-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: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die
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, 04 Apr 2015 15:41:49 -0000

On Saturday, April 04, 2015 12:52:50 am Aaron Zauner wrote:
> Added the PSK ciphersuites after lengthy discussion with nikos and peter
> gutmann, they assure me it's of importance to the embedded world.

I'm fine with (EC)DHE_PSK, but I thought the consensus was that non-ephemeral cipher suites were not permitted any longer. I thought usage of plain PSK would be against TLS 1.3 & HTTP/2 consensus. If it really is needed, I think they should be prohibited in general TLS and only allowed via the IoT application profile.

> > Just splitting it into only two parts would avoid the risk of support holes you'd get with the full a la carte route.
> > 
> > There's plenty of space in the registry to keep adding piles and piles of variations for each suite, but I have seen actual instances where a server and client actually do support the same handshake and connection ciphers in TLS 1.2, but don't negotiate it because the specific combination isn't listed. The current system does lead to some support holes as-is.
> I actually really like the idea. But there're a couple of open questions
> to that; What happens to existing ciphersuites?

There's hardly any left that are still permitted. Each cipher that would be usable in TLS 1.3+ would need to define its own set of new cipher suites. The TLS 1.3 spec could have a short section to just assign the IDs for the existing ones. Clients would propose both the old suites and the new suites in the same array. Old servers would ignore the new, and new servers would ignore the old. (again, set all new above some point so checking is just a greater/lesser than comparison) It would be an extra few bytes, but again, any system to improve this via an extension would also add an extra few bytes.

> And given we switch to a
> model of asymmetric and symmetric ciphersuites: (how) do we document all
> the implicit ciphersuites that are defined once a new symmetric or
> asymmetric algorithm is defined?

The two are separate enough that all combinations should be valid and all implementations should be capable of handling all combinations.