Re: [TLS] DSA should die

Dave Garrett <> Thu, 02 April 2015 05:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B3A3D1B2ACD for <>; Wed, 1 Apr 2015 22:03:35 -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 lRQVck0NxmOG for <>; Wed, 1 Apr 2015 22:03:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DAC011AC3F2 for <>; Wed, 1 Apr 2015 22:03:33 -0700 (PDT)
Received: by qgep97 with SMTP id p97so61358163qge.1 for <>; Wed, 01 Apr 2015 22:03:33 -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=9JJOPjVqoYMGha6JpuT9Ura+oFFARTeC5HxZhaNoVyo=; b=BqV1yIKho9dL1e5FVAPoaGl9kSzgF0233f/7ZuIzaC9gXhxiR7+AIl51nX8KXd8cka jkbxCM510AW3WKyWCnyKmgfOLf7o+8i2pq/2IDonIsBwkRS9I3D1c9lYobjDeFG/RCr8 +xiqLds4f4U0OutCTV+Gf4sMSYTht9XkGhTJudc8RsTOWL9vm8vttfJY1PLo5AJwxAfO k2OeoBbW1f0lAm9M+4zPl1OfflKkDOxDZ1e+/nGV6xFeqxPC/R5J9wIKb4+jVbVQhkF/ mRk8UXTlSHL5m0zyj08ZhK4nW1p3GiFuVWE/NqJh7z9hqQLOug7EPhVYhNjd4yjk4fFB vUPg==
X-Received: by with SMTP id t5mr60808912qcq.19.1427951013170; Wed, 01 Apr 2015 22:03:33 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 187sm2823612qhv.8.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 22:03:32 -0700 (PDT)
From: Dave Garrett <>
Date: Thu, 2 Apr 2015 01:03:31 -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 05:03:35 -0000

On Wednesday, April 01, 2015 09:15:08 pm Dave Garrett wrote:
> 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.
> 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.

On Wednesday, April 01, 2015 10:17:23 pm Martin Rex wrote:
> But how about using the Cipher Suites registry in a more creative
> fashion.
> For TLSv1.3, we could do the negotiation through he cipher suites list
> more like this:
>    0x10,0xXX    specifies a key exchange algorithm (XX) 256 codepoints
>    0x12,0xYY    specifies an authentication algorithm (YY) 256 codepoints
>    0x14,0xZZ    specifies a symmetric encryption scheme (ZZ) 256 codepoints
>    0x16,0xQQ    specifies a mac algorithm (QQ) 256 codepoints
>    0x18,0xPP    specifies a PRF algorithm (PP) 256 codepoints
> (with a little room in between if we ever exceed the 256 codepoints)

Yes, that's basically what I'm proposing. Myself, Nico, and you are all just describing the same sort of scheme differently. Yours is the clearest thus far, as it covers everything we might want here.

The only difference I suggest is picking points all above a threshold that separates new from old so filtering out the old system trivial. That looks to be around 0xD000, or 0xC100 if you want to get closer to the current highest assigned value.