Re: [TLS] Simplifying signature algorithm negotiation

David Benjamin <davidben@chromium.org> Tue, 19 January 2016 16:50 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 F2FE61B3246 for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 08:50:30 -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 ebSNNCGyAaOo for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 08:50:28 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 9ED4A1B3242 for <tls@ietf.org>; Tue, 19 Jan 2016 08:50:28 -0800 (PST)
Received: by mail-ig0-x22a.google.com with SMTP id z14so81233260igp.0 for <tls@ietf.org>; Tue, 19 Jan 2016 08:50:28 -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 :content-type; bh=Kbn7M4qMnJqGRBaCvTwdAcViGf4UJ65ALRZK5iVu92M=; b=UoOoq8ODX28e8qibZKJ6Z13Xgmqh0MbDgkfyQi/6aKrCkeU+hN5aZ39T1P7GucK0dp YzQR/IwpWiDQjeqIewGKuNbEQIO8q8A6PT4eFLz4AmJok7FIm9xOnkaw4KSOVnRv0ckJ soosNyegC2aBxV+IlJ2fhMU6HjKl8AaHFIsnU=
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:content-type; bh=Kbn7M4qMnJqGRBaCvTwdAcViGf4UJ65ALRZK5iVu92M=; b=SX5rPvZutvosARidJQsaeyOuG/t2tt39p6PQYTK3fcdAV4SnA1tPgB6dGUF8d/wYyk EwN1Ce+x1+pUewA0IEO1ReKiGIJGTDfF3H6kQmxtxaroA1xb+/X0jZKoOxsnQ90mAGD2 AoMGcIAmL9u2fkwwcL2QV0DSk3e06VeMzSv4K4+mrJCLzVJUKE2Oal07DgLZBydIozKz sagSPIlsGwZyPi8XqPheYFTyleMA/pcYbQH6ivkfGY/soVGQj7yMdw1SDiLmBGXEo+0E lMvpbSCSTV5eTkepRyFBFruXVbPNOzzWAev13S3CuDq8u2/gcI8EM2/LtfLeWneUygv3 es2g==
X-Gm-Message-State: AG10YOQvxtvnGg+4k/qNh30SC4jFKNd3HdZJeAMmxM/dSsVx8BFWfuuEgaH58wz3xXPqWP1BmRNBRGi7E6dJFkaK
X-Received: by 10.50.134.129 with SMTP id pk1mr17056250igb.11.1453222227972; Tue, 19 Jan 2016 08:50:27 -0800 (PST)
MIME-Version: 1.0
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <2450637.qJVlx5inBb@pintsize.usersys.redhat.com>
In-Reply-To: <2450637.qJVlx5inBb@pintsize.usersys.redhat.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 19 Jan 2016 16:50:18 +0000
Message-ID: <CAF8qwaBisJRAhbP1Hq1p4SnXNa=4uTaa8Cf-hOmmpTTk4FcRMw@mail.gmail.com>
To: Hubert Kario <hkario@redhat.com>, tls@ietf.org
Content-Type: multipart/alternative; boundary=047d7b2e3fe6adf0a30529b2aaba
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2JNc8XrZogL-QqL_ueaNX_oIZZ4>
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 16:50:31 -0000

On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario <hkario@redhat.com>; wrote:

> On Friday 15 January 2016 20:45:34 David Benjamin wrote:
> > Hi folks,
> >
> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In
> > TLS 1.2, signature algorithms are spread across the handshake. We
> > have SignatureAlgorithm, NamedGroup/Curve (for ECDSA), and
> > HashAlgorithm, all in independent registries. NamedGroup is sent in
> > one list, also used for (EC)DH, while the other two are sent as a
> > pair of (HashAlgorithm, SignatureAlgorithm) tuples but live in
> > separate registries.
> >
> > This is a lot of moving parts. Signature negotiation in TLS 1.2 tends
> > to be messy to implement. Client certificate keys may be in
> > smartcards via OS-specific APIs, so a lot of time is spent transiting
> > new preference shapes across API boundaries in order to discover
> > smartcard bugs. Sometimes I think people deploy client certs because
> > they hate me and want to cause me pain… :-)
> >
> > Anyway, the new CFRG curves also bind signature curve and hash
> > together. The current draft represents this as eddsa_ed25519 and
> > eddsa_ed448 NamedGroups and eddsa SignatureAlgorithm. But this
> > doesn’t capture that EdDSA + Ed25519 + SHA-256 is illegal. (Or ECDSA
> > + FF3072.)
> >
> > I propose we fold the negotiable parameters under one name. Think of
> > how we’ve all settled on AEADs being a good named primitive with a
> > common type signature[1]. Specifically:
> >
> > 1. Drop eddsa_ed25519(31) and eddsa_ed448(32) from NamedGroup. From
> > now on, NamedGroup is only used for (EC)DH.
> >
> > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm
> > as they are. Introduce a new SignatureAlgorithm u16 type and
> > negotiate that instead. (Or maybe a different name to not collide.)
> > u8 is a little tight to allocate eddsa_ed25519 and eddsa_ed448
> > separately, but u16 is plenty.
> >
> > 3. Allocate values for SignatureAlgorithm wire-compatibly with TLS 1.2
> > by (ab)using the old (HashAlgorithm, SignatureAlgorithm) tuples.
> > 0x0401 becomes rsa_pkcs1_sha256, etc. Reserve ranges consistently
> > with HashAlgorithm from TLS 1.2. Note this does not introduce new
> > premultiplications on the wire. Just in the spec and registry.
> >
> > 4. Deprecate ecdsa_sha256, etc., in favor of new
> > ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old
> > ecdsa_* values are for TLS 1.2 compatibility but ignored in TLS 1.3.
> > Although this introduces new premultiplications, it’s only 9 values
> > with the pruned TLS 1.3 lists. I think this is worth 9 values to keep
> > NamedGroups separate.
> >
> > 5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
> > rsapss_{sha256,sha384,sha512}. These come with the signature algorithm
> > and curve pre-specified. (See [2] at the bottom for full list of
> > allocations.)
> >
> > Thoughts?
> >
> > David
> >
> > [1] We’re stuck with RSA-PSS's generality, so that'll need some
> > mapping to a subset of X.509's RSA-PSS. We'll just not bother with
> > RSA-PSS with hashAlgorithm SHA-256, maskGenAlgorithm
> > MGF-7-v3.0-SHA-334-saltLengthQuotient-5/7, saltLength 87, trailerField
> > 14. And RSA key generation still has size parameter. Hopefully future
> > things can look more like Ed25519.
> >
> > [2]
> > 0x0000-0x06ff - Reserved range for TLS 1.2 compatibility values. Note
> > this is wire-compatible with TLS 1.2.
> > - 0x0101 - rsa_pkcs1_md5
> > - 0x0201 - rsa_pkcs1_sha1
> > - 0x0301 - rsa_pkcs1_sha224
> > - 0x0401 - rsa_pkcs1_sha256
> > - 0x0501 - rsa_pkcs1_sha334
> > - 0x0601 - rsa_pkcs1_sha512
> > - 0x{01-06}02 - dsa_md5, etc. Ignored in TLS 1.3.
> > - 0x{01-06}03 - ecdsa_md5, etc. Advertised for TLS 1.2 compatibility
> > but ignored in TLS 1.3.
> >
> > 0x0700-0xfdff - Allocate new values here. Optionally avoid 0x??0[0-3]
> > to avoid colliding with existing signature algorithms, but I don’t
> > think that’s necessary[3].
> > - 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
>
> Then what ECDHE share gets signed?
> if the same as the curve, what about FFDHE, what about ECDHE-RSA? why no
>  - rsapss_dh2048_sha256
>  - rsapss_dh3072_sha256
>  - rsapss_dh4096_sha384
>  - (etc.)
>  - rsapss_p256_sha256
>  - rsapss_p384_sha384
>  - (etc.)
>
> 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.

David