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 <david...@chromium.org>
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.
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
