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.