Signature Algorithms for ECDSA now define both the curve and the hash algorithm:
ecdsa_secp256r1_sha256(0x0403),
ecdsa_secp384r1_sha384(0x0503),
ecdsa_secp521r1_sha512(0x0603),
This is in contrast to the TLS 1.2 protocol, where any hash can be used with
any curve.
There are good reasons for that change:
- less combinations to test
- establishes the low water mart for security
I see few problems with that though:
1). there are not insignificant number of clients that advertise support for
all (at least P-256 and P-384) curves, but don't advertise support for
hashes stronger than SHA-256 with ECDSA[1]
2). This is inconsistent with RSA-PSS behaviour, where key size is completely
detached from the used hash algorithm.
3). This is not how ECDSA signatures in X.509 work, so it doesn't actually
limit the signatures on certificates (in other words, as an implementer
you need to support all hashes with all curves either way)
With the implementers hat on, I'd prefer to drop the curves from signature
algorithm names/specifications and return to TLS 1.2 behaviour.
With my security hat on, I'd say that we should set the minimal key sizes for
RSA-PSS signatures too, as we did with ECDSA.
Any other ideas?
1 - Nick Sullivan from Cloudflare provided me with some stats from random
50000 client hellos from early 2017:
Sigalgs:
ECDSA + SHA-256 = 39104 (78.2%)
ECDSA + (SHA-256 + SHA-384 + SHA-512) = 28678 (57.4%)
ECDSA + (SHA-256 + SHA-384 + !SHA-512) = 8934 (17.9%)
ECDSA + (SHA-256 + !SHA-384 + !SHA-512) = 1492 (2.98%)
Note: many of the 1492 seem to be on iOS and only support:
[RSA-SHA-384, RSA-SHA-256, RSA-SHA1, ECDSA-SHA256, ECDSA-SHA1]
Curves:
none = 757 (1.51%)
P-256 = 49243 (98.5%)
P-384 = 49233 (98.5%)
P-256 + P-384 = 49233 (98.5%)
P-256 + !P-384 = 10 (0.02%)
!P-256 + P-384 = 0 (0%)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
