Re: [TLS] Consistency for Signature Algorithms?

[Dr Stephen Henson <[e-mail]>]

-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/
On 21/07/2017 20:45, Dr Benjamin Kaduk wrote:
> 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.
> 

I didn't mean there was a problem with the current spec, I meant there was a
problem with the proposed change: i.e. to remove the curve requirement from
signature algorithms.

Steve.
-- 
Dr Stephen N. Henson.
Founder member of the OpenSSL project: http://www.openssl.org/