Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin <[e-mail]>]

Sorry, I'd meant to add this note to the message below and forgot:

In putting together the PR, I noticed that eddsa is currently in the draft
as always paired with no hash rather than the one it uses internally. So
the problem about advertising {sha512, eddsa} and eddsa_448 doesn't occur.
My bad, I should have looked at that more carefully.

I still think this change is worthwhile. If we expect that future signature
algorithms look like ed25519, this scheme only gives us 256 values to
allocate from and wastes one of the bytes, and it also simplifies and
unifies the interface for signature algorithms. The other benefits from
incorporating curve preferences into the negotiation also still apply.

David

On Fri, Jan 22, 2016 at 5:25 PM David Benjamin <[e-mail]>
wrote:

> I've put together a pull request with some initial text for this proposal
> if folks decide to adopt it.
> https://github.com/tlswg/tls13-spec/pull/404
>
> (I'm sure there's no end of editorial problems. I think this is the first
> time I've done non-trival spec work.)
>
> David
>
>
> On Fri, Jan 15, 2016 at 3:45 PM David Benjamin <[e-mail]>
> 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
>>
>> 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.
>>
>