Re: [TLS] Simplifying signature algorithm negotiation

Hubert Kario <hkario@redhat.com> Tue, 19 January 2016 18:25 UTC

Return-Path: <hkario@redhat.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 609D41B33FD for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 10:25:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 Y4D7fvVlYAeE for <tls@ietfa.amsl.com>; Tue, 19 Jan 2016 10:25:16 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F901B33FB for <tls@ietf.org>; Tue, 19 Jan 2016 10:25:15 -0800 (PST)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 6C2F918B249; Tue, 19 Jan 2016 18:25:15 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-125.brq.redhat.com [10.34.0.125]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0JIPDNK023460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jan 2016 13:25:14 -0500
From: Hubert Kario <hkario@redhat.com>
To: David Benjamin <davidben@chromium.org>
Date: Tue, 19 Jan 2016 19:25:13 +0100
Message-ID: <1717909.HACNtZYKZV@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.2.8-200.fc22.x86_64; KDE/4.14.14; x86_64; ; )
In-Reply-To: <CAF8qwaBisJRAhbP1Hq1p4SnXNa=4uTaa8Cf-hOmmpTTk4FcRMw@mail.gmail.com>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com> <2450637.qJVlx5inBb@pintsize.usersys.redhat.com> <CAF8qwaBisJRAhbP1Hq1p4SnXNa=4uTaa8Cf-hOmmpTTk4FcRMw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2622625.sc6tRH5ysJ"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0MoAOa85eCiT-9yiyzTGmFvamEg>
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:25:18 -0000

On Tuesday 19 January 2016 16:50:18 David Benjamin wrote:
> 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.

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)?

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?
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic