On 07/21/2017 08:41 AM, Dr Stephen Henson wrote: > On 21/07/2017 14:23, Hubert Kario wrote: >> 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) >> > There is another and significant problem with the change. In TLS 1.2 support > for a curve was indicated in the supported curves extension and it implied > support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the > supported groups extension are for ECDH only. Support for a curve for ECDSA is > indicated in the signature algorithms extension.
Could you say a bit more about why you believe this to be a problem? On the face of it, it seems that the previous state overloaded a single field to mean multiple only semi-related things, whereas the new formulation keeps things more orthogonal and easier to implement in a modular way. That is, groups are for key exchange, and signature algorithms are for signing, and there is no muddy overlap between them. Thanks, Ben
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
