Re: [TLS] Simplifying signature algorithm negotiation

[Hubert Kario <[e-mail]>]

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