Re: [TLS] Simplifying signature algorithm negotiation

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 16 January 2016 21:02 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D96A1AC3C6 for <tls@ietfa.amsl.com>; Sat, 16 Jan 2016 13:02:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.699
X-Spam-Level:
X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avyJhv4fAETd for <tls@ietfa.amsl.com>; Sat, 16 Jan 2016 13:02:22 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0C31AC3C1 for <tls@ietf.org>; Sat, 16 Jan 2016 13:02:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 86EA955A; Sat, 16 Jan 2016 23:02:20 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fm5IbW9qKARQ; Sat, 16 Jan 2016 23:02:20 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-35-116.bb.dnainternet.fi [87.92.35.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3ADB7287; Sat, 16 Jan 2016 23:02:20 +0200 (EET)
Date: Sat, 16 Jan 2016 23:02:16 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Hanno Böck <hanno@hboeck.de>
Message-ID: <20160116210216.GA10852@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <20160116110112.4af15baf@pc1>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160116110112.4af15baf@pc1>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: ilariliusvaara@welho.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/gDI33UTV7lT2sbTopTg9VYSB4Ic>
Cc: tls@ietf.org
Subject: Re: [TLS] Simplifying signature algorithm negotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Jan 2016 21:02:24 -0000

On Sat, Jan 16, 2016 at 11:01:12AM +0100, Hanno Böck wrote:
> 
> > - rsapss_sha256
> > - rsapss_sha384
> > - rsapss_sha512
> > - ecdsa_p256_sha256
> > - ecdsa_p256_sha384
> > - ecdsa_p256_sha512
> > - ecdsa_p384_sha256
> > - ecdsa_p384_sha384
> > - ecdsa_p384_sha512
> > - ecdsa_p521_sha256
> > - ecdsa_p521_sha384
> > - ecdsa_p521_sha512
> > - eddsa_ed25519
> > - eddsa_ed448
> 
> Do we really need that many?
> I think the "complexity zoo" of TLS is one of its current downsides and
> I really think we should go with fewer options in the future. Can we
> strip that down to - below 5 or something? (personal opinion: Strip
> down to 2, but this may be too radical for now.)

Well, there already are 3 main signature schemes...

Six of those on the list could be cut down (cutting the list to 8)
for purposes of server signature.

Unfortunately there might be more in certificate-to-certificate
signatures.

Also, I don't think having N signature algorithms is that bad (unless
your TLS stack architecture is garbage, but then you have other problems
anyway). But if that gets coupled to other things, you are in world of
hurt.

Such annoyances include the TLS_ECDHE_RSA_*/TLS_ECDHE_ECDSA_* cipher-
suites, since RSA_PSS presumably uses _RSA_ and others use _ECDSA_.


-Ilari