### Re: [TLS] Simplifying signature algorithm negotiation

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 19 January 2016 19:28 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 285931B34C7
for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 11:28:23 -0800 (PST)

X-Virus-Scanned: amavisd-new at amsl.com

X-Spam-Flag: NO

X-Spam-Score: -1.901

X-Spam-Level:

X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 ykp4A4H47XxQ for <tls@ietfa.amsl.com>;
Tue, 19 Jan 2016 11:28:20 -0800 (PST)

Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25])
by ietfa.amsl.com (Postfix) with ESMTP id BB9041B34C3
for <tls@ietf.org>; Tue, 19 Jan 2016 11:28:20 -0800 (PST)

Received: from localhost (localhost [127.0.0.1])
by welho-filter3.welho.com (Postfix) with ESMTP id 40BE85E3;
Tue, 19 Jan 2016 21:28:19 +0200 (EET)

X-Virus-Scanned: Debian amavisd-new at pp.htv.fi

Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86])
by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new,
port 10024)
with ESMTP id VD3K_YlJpyrx; Tue, 19 Jan 2016 21:28:19 +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-smtp3.welho.com (Postfix) with ESMTPSA id 02A0E230D;
Tue, 19 Jan 2016 21:28:19 +0200 (EET)

Date: Tue, 19 Jan 2016 21:28:15 +0200

From: Ilari Liusvaara <ilariliusvaara@welho.com>

To: David Benjamin <davidben@chromium.org>

Message-ID: <20160119192815.GA5795@LK-Perkele-V2.elisa-laajakaista.fi>

References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com>
<2450637.qJVlx5inBb@pintsize.usersys.redhat.com>
<CAF8qwaBisJRAhbP1Hq1p4SnXNa=4uTaa8Cf-hOmmpTTk4FcRMw@mail.gmail.com>
<1717909.HACNtZYKZV@pintsize.usersys.redhat.com>
<CAF8qwaCZXdhor8s8=cq-OrYBYzF-_H7MwudmG4BJ+i0uR4nVTw@mail.gmail.com>

MIME-Version: 1.0

Content-Type: text/plain; charset=utf-8

Content-Disposition: inline

In-Reply-To: <CAF8qwaCZXdhor8s8=cq-OrYBYzF-_H7MwudmG4BJ+i0uR4nVTw@mail.gmail.com>

User-Agent: Mutt/1.5.24 (2015-08-30)

Sender: ilariliusvaara@welho.com

Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Dan2DhEHqGgcA7MbOzoVX47UgEo>

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: Tue, 19 Jan 2016 19:28:23 -0000

On Tue, Jan 19, 2016 at 06:55:49PM +0000, David Benjamin wrote: > On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario <hkario@redhat.com>; wrote: > > > > > Problem I am pointing out is that NamedGroup specifies not only what > > curves can be used for signing but also what curves can get signed. > > > > Or are you saying that the NamedGroup would stay, and would now specify > > only the supported parameters for the key exchange, not how they are > > authenticated (as it is now)? > > > > Yes. Also, IIRC some have expressed that sometimes softare can sanely do ECDHE over some curve but not signature verification. Or it can sanely do signature verification but not ECDSA. > > On Friday 15 January 2016 20:45:34 David Benjamin wrote: > > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From now > on, NamedGroup is only used for (EC)DH. > > > On Tuesday 19 January 2016 16:50:18 David Benjamin wrote: > > Why would it need to specify what [DH group's] DH share gets signed? > > NamedGroup still exists for the key exchange (see step 1). I'm only > > proposing pulling signature curves out of NamedGroup. > > > Or to put it other way: what extensions and with what values should I > > sent if I support only TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 with either > > P-256 or P-384 curve, signed with SHA-256, SHA-384 or SHA-512 using RSA? > > > supported_groups {p256, p384} > supported_signature_algorithms {rsa_pkcs1_sha256, rsa_pkcs1_sha384, > rsa_pkcs1_sha512} > (Or s/rsa_pkcs1_/rsa_pss_/g if you meant that one.) Of course, one wants at least semi-sane behaviour when downnegotiating... > [1] I have not been following the CFRG curve work very closely. Adam tells > me Ed448 is likely to be bound to SHAKE-256. For the sake of discussion, > let's assume that's how it ends up. Actually, it isn't raw SHAKE256 but some weird prefixed variant... Fortunately only matters for TLS 1.2 client signatures, due to every- thing else being highly temporally localized. I do have should-be-final reference implementation and test vectors (and another implementation that is just slow and has the test vectors pass). Currently waiting on co-editor. -Ilari

- [TLS] Simplifying signature algorithm negotiation David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Brian Smith
- Re: [TLS] Simplifying signature algorithm negot... Dave Garrett
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Brian Smith
- Re: [TLS] Simplifying signature algorithm negot... Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negot... Hanno Böck
- Re: [TLS] Simplifying signature algorithm negot... Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negot... Nikos Mavrogiannopoulos
- Re: [TLS] Simplifying signature algorithm negot... Hubert Kario
- Re: [TLS] Simplifying signature algorithm negot... Hubert Kario
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Hubert Kario
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Kurt Roeckx
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negot... Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negot... David Benjamin
- Re: [TLS] Simplifying signature algorithm negot... Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negot... Ilari Liusvaara
- Re: [TLS] Simplifying signature algorithm negot... Eric Rescorla
- Re: [TLS] Simplifying signature algorithm negot... Joseph Salowey
- Re: [TLS] Simplifying signature algorithm negot... Eric Rescorla