Hi, I generally like the idea of simplifying the different algorithm negotiation things, but:
On Fri, 15 Jan 2016 20:45:34 +0000
David Benjamin <david...@chromium.org> wrote:
> [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.
I think a couple of them (esp. everything with dsa and _md5) should get
a diediedie rfc and never be seen again.
> - 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
Do we really need that many?
I think the "complexity zoo" of TLS is one of its current downsides and
I really think we should go with fewer options in the future. Can we
strip that down to - below 5 or something? (personal opinion: Strip
down to 2, but this may be too radical for now.)
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
pgpkrBJu0EUUI.pgp
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
