[TLS] Simplifying signature algorithm negotiation

[David Benjamin <[e-mail]>]

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

0xfe00-0xffff - reserved for private use, compatible with existing
HashAlgorithm reservation.

[3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
RSA}, they should ignore it since hash 7 doesn't exist.