Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <> Tue, 19 January 2016 18:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B95B41B3460 for <>; Tue, 19 Jan 2016 10:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MMoxbcbsgCK2 for <>; Tue, 19 Jan 2016 10:56:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E9F9B1B345C for <>; Tue, 19 Jan 2016 10:55:59 -0800 (PST)
Received: by with SMTP id z14so84485207igp.1 for <>; Tue, 19 Jan 2016 10:55:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id q10mr15964758iga.67.1453229759045; Tue, 19 Jan 2016 10:55:59 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Tue, 19 Jan 2016 18:55:49 +0000
Message-ID: <>
To: Hubert Kario <>
Content-Type: multipart/alternative; boundary=089e013c65dc914b740529b46b86
Archived-At: <>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
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: Tue, 19 Jan 2016 18:56:01 -0000

On Tue, Jan 19, 2016 at 1:25 PM Hubert Kario <> 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)?


> 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,
(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
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}


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