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/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
