Re: [TLS] Simplifying signature algorithm negotiation

[David Benjamin <[e-mail]>]

On Mon, Jan 18, 2016 at 6:48 AM Hubert Kario <[e-mail]> 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