Re: [TLS] Simplifying signature algorithm negotiation

Nikos Mavrogiannopoulos <nmav@redhat.com> Sat, 16 January 2016 22:39 UTC

Return-Path: <nmavrogi@redhat.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 DFA3F1ACD30 for <tls@ietfa.amsl.com>; Sat, 16 Jan 2016 14:39:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.902
X-Spam-Level:
X-Spam-Status: No, score=-3.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham
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 J0Jdx3iOQrU3 for <tls@ietfa.amsl.com>; Sat, 16 Jan 2016 14:39:19 -0800 (PST)
Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA9AD1ACD2F for <tls@ietf.org>; Sat, 16 Jan 2016 14:39:19 -0800 (PST)
Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0GMdF7K026243; Sat, 16 Jan 2016 17:39:15 -0500
Date: Sat, 16 Jan 2016 17:39:14 -0500
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Hanno Böck <hanno@hboeck.de>
Message-ID: <1784001619.6652310.1452983954794.JavaMail.zimbra@redhat.com>
In-Reply-To: <20160116110112.4af15baf@pc1>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <20160116110112.4af15baf@pc1>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.10.63.68]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF38 (Linux)/8.0.6_GA_5922)
Thread-Topic: Simplifying signature algorithm negotiation
Thread-Index: kHxlw2gl1QvrZucIWQp9wDXKdbIjgQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/5HZ0Bg75-PpD3bHEDj5sk6wi7HI>
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 22:39:21 -0000

----- Original Message -----
> Hi,
> > - 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.)

In addition options like ecdsa_p384_sha256 ignore the NIST DSS recommendations 
of using equivalent security strength for hash and signature (SP-800-57). Having
fewer options is indeed better.

regards,
Nikos