Re: [TLS] Consistency for Signature Algorithms?

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

On 21/07/2017 16:00, Ilari Liusvaara wrote:
> 
> I suppose some new dual-version TLS 1.2/1.3 libraries might have the
> same issue as mine: supported groups is just plain ignored for ECDSA,
> and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2.
> 

That is potentially a problem yes.

Suppose a server has an EE certificate with a P-256 public key and the client
preference order is ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256. For TLS 1.3
it will use ecdsa_secp256r1_sha256 and sign TLS messages using P-256+SHA256.

In TLS 1.2 the same preference list means sha384+ecdsa, sha256+ecdsa without the
curve restriction. In this case the server might sign the message using
P-256+SHA384 because the client prefers it. That isn't allowed in TLS 1.3 but is
in TLS 1.2. A client which enforces the TLS 1.3 signature algorithm rules for
TLS 1.2 might abort the connection at that point.

>> I agree though that there is an anomaly here. For example AFAICS in
>> certificates for TLS1.3 you're allowed (with some caveats) to use a
>> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not
>> allowed at all. Is that likely to be a problem in practice? Are there many
>> such certificates about in the wild?
> 
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).
> 

Yes you're right, the caveat of not otherwise having any suitable chain allows
that case.

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