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

David Benjamin <davidben@chromium.org> Tue, 19 January 2016 18:56 UTC

Return-Path: <davidben@google.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 B95B41B3460
for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 10:56:01 -0800 (PST)

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

X-Spam-Flag: NO

X-Spam-Score: -1.379

X-Spam-Level:

X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001,
RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 MMoxbcbsgCK2 for <tls@ietfa.amsl.com>;
Tue, 19 Jan 2016 10:56:00 -0800 (PST)

Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com
[IPv6:2607:f8b0:4001:c05::22c])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id E9F9B1B345C
for <tls@ietf.org>; Tue, 19 Jan 2016 10:55:59 -0800 (PST)

Received: by mail-ig0-x22c.google.com with SMTP id z14so84485207igp.1
for <tls@ietf.org>; Tue, 19 Jan 2016 10:55:59 -0800 (PST)

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc:content-type;
bh=OkmCFkpEzVG3tHSY7Nikp7xrdfN5AccfWVrQXBdi5i8=;
b=d8lUlrfzoFHaM+RPB+ZDpNIpDOz1/Gp9GlwRvJuOq/bX/6M7zq6k7WsIEsoF7KLWO0
GOUhDz+eGpF8Coj/bycsrL4uhFNDUDw9NmZEBVbDO4XiWAUwJYgRT/kqUt4uho8cLTmr
EsKYVeSOS8QIEz5zigXNYyD4IqkDJNPRc/u8Y=

X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc:content-type;
bh=OkmCFkpEzVG3tHSY7Nikp7xrdfN5AccfWVrQXBdi5i8=;
b=f02qRHxEtbndQ+x3pXDzDkUhM0G5jEl8JL9JEv8iiAUPx4FFHizESQvOTy4CSipIxN
SSDuC+Hb8U6brB+XZJYni6lfb1pBy59+G9eF4dHlqsTd/PuWuzbFYrrwRzeMAyLv/0BU
t1h9xm3VK8XjtE92iqhrY3T4JysX4X9ajsh85+G9CdhNTqaTXE89RjeaQBw7kMuRESko
D2vIMzM1vMBgZfPLbcZXijLb/iwaUOmUOImqqrDwT9H3/JmYgNM/OEa9yLQhBWiMLaVU
s0/ZBrcwAou8OywttZHqAGlolntnFMCoRr6XcW3dtNHZkZxnQMySn4516kci1FUd0FiS
//+A==

X-Gm-Message-State: AG10YORovYfS2MfLT8+j4Jj5lMgPI8lrvBJ7Ih5IjuX5zRg375uEjSyBwUIJZyvo9I9fxk52yOabODaySW7/MHSy

X-Received: by 10.50.8.106 with SMTP id q10mr15964758iga.67.1453229759045;
Tue, 19 Jan 2016 10:55:59 -0800 (PST)

MIME-Version: 1.0

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>

In-Reply-To: <1717909.HACNtZYKZV@pintsize.usersys.redhat.com>

From: David Benjamin <davidben@chromium.org>

Date: Tue, 19 Jan 2016 18:55:49 +0000

Message-ID: <CAF8qwaCZXdhor8s8=cq-OrYBYzF-_H7MwudmG4BJ+i0uR4nVTw@mail.gmail.com>

To: Hubert Kario <hkario@redhat.com>

Content-Type: multipart/alternative; boundary=089e013c65dc914b740529b46b86

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

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 18:56:01 -0000

On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario <hkario@redhat.com>; wrote: > > > If it does not specify the DH share signed, it doesn't really change > > > anything... > > > > 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. > > > > (Is the DH share even signed directly? It looks like TLS 1.3 signs via > > CertificateVerify's handshake context in both directions. Either way, > > it's just a byte-string message. We could also backport this sort of > > thing to TLS 1.2 and the signature algorithm still doesn't care about > > the DH share. That gets encoded into a byte string somehow.) > > > > I'm trying to make the decompositions and premultiplications align > > with how the protocol is structured. TLS 1.2 decomposed algorithm, > > signing curve, and hash which isn't universal (Ed25519, Ed448, even > > RSA-PSS's params in full generality aren't the same shape, the > > definition of "digitally-signed" takes only a byte-string message as > > input), so they should be premultiplied. Whereas signature algorithm > > and DH group are cleanly separated in the protocol and needn't be > > premultiplied. > > 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. > 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.) For your example, nothing on the wire changes at all. Before, you'd end up sending: supported_groups {p256, p384} supported_signature_algorithms {{sha256, rsa}, {sha384, rsa}, {sha512, rsa}} And rsa_pkcs1_sha256 should be allocated to align with {sha256, rsa}, etc. The interesting case is Ed25519 and Ed448. You'd currently have to send: supported_groups {..., eddsa_ed25519, eddsa_ed448} supported_signature_algorithms {..., {sha512, eddsa}, {shake256[1], eddsa}} However, this does not capture that {shake256, eddsa} + eddsa_ed25519 isn't legal. Instead I want: supported_groups {..., irrelevant to ed25519 and friends} supported_signature_algorithms {..., eddsa_ed25519, eddsa_ed448} David [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.

- [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