Re: [TLS] Consistency for Signature Algorithms?

[Dr Benjamin Kaduk <[e-mail]>]

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