Re: [TLS] DSA should die

Dave Garrett <> Thu, 02 April 2015 01:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F9801AD09E for <>; Wed, 1 Apr 2015 18:15:13 -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 0mNbpVOaokao for <>; Wed, 1 Apr 2015 18:15:12 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CF7C1AD082 for <>; Wed, 1 Apr 2015 18:15:11 -0700 (PDT)
Received: by qgh3 with SMTP id 3so58419444qgh.2 for <>; Wed, 01 Apr 2015 18:15:11 -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=Hlqf7SARubJMWhCU4Cj54Gw/xwpJz30ZuXsS20TIc1E=; b=Oxa8XXbgVecZHCF2M0L6f3zl1xHec21mm7GEW8ZnrCLqbpEsoK1djK0MQos99RwDdH wPSreSFPmt3mtqF7Q3x5ILdV7NC/+9yJTuqyJa2cw+EK7PrvqUgputtV3r3kZc6VDZGy F5Lj7XRvQR1dNlAaD6ITSmmNuRTlS2clPHUM4msHSUm0Tp0Sgwy49GaYZLj+pkL3MW3Z Ioq7qPhONj0SY+XDdoJwsx169qfmFFWvcLoNZqblstN9H1S1vxCNi9hwoy2xm99WLLKL RTDzjlGwqQ/8Bvrio71NyMgslizrHimIsquq+4J5h4eYDXPpicEeDnw2JoJhzcZUENrK 5Y3g==
X-Received: by with SMTP id z196mr59323375qhd.66.1427937311146; Wed, 01 Apr 2015 18:15:11 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 206sm2512454qhy.1.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 18:15:10 -0700 (PDT)
From: Dave Garrett <>
Date: Wed, 1 Apr 2015 21:15:08 -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="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
Subject: Re: [TLS] 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: Thu, 02 Apr 2015 01:15:13 -0000

On Wednesday, April 01, 2015 08:40:40 pm Stephen Farrell wrote:
> <no-hats-except-the-330+-ciphersuites-is-crap-hat>
> Here's a suggestion: why pick 'em off one by one? How about
> creating a new registry that only includes stuff we think is
> really good for TLS1.3?

I don't think a whole new registry is a good idea. The ClientHello has to stay the same for backwards compatibility, and cipher suites will need to be listed for TLS 1.2 compatibility at least. Creating a whole new system is only good if you can completely ignore the old one.

There's plenty of space in the current registry if you want to start over. Just say 0xD000 and up is for TLS2 suites, and all below are TLS1. (at this point it's definitely time for 2.0) Define TLS2 codepoints for valid combinations for TLS2 and the TLS1 would be invalid to negotiate for TLS2 but in there for TLS1. This would cost a few more bytes to list AES-GCM in both TLS1 & TLS2 format in the same list, but resorting to a whole new system would add more bytes anyway, along with another registry to keep track of.

On Wednesday, April 01, 2015 08:48:36 pm Nico Williams wrote:
> It would be better to also negotiate (cipher+mode), (hash), (KDF), and
> (key agreement+server authentication) separately.

I'm definitely in favor of reducing the combinatorial explosion in suites and moving hash, KEA, & etc. into a separate negotiation. Instead of an extension, you could just do the same thing again, really. Reserve a sizable block of the 16-bit suite space for hashes and another for KEA and list them all in the same cipher_suites array. TLS1 would ignore them, and TLS2 would just see points between [a,b] are hash, [b+1,c] are KEA, etc. So, new registries in the existing space, just dumped all into the same pile.