Subject: [TLS] Old signature schemes in CertificateRequest

From: "Martin Thomson" <[email-masked]>
Date: Mon, 03 Jun 2019 11:29:47 +1000

RSASSA-PKCS1-v1_5 algorithms:  Indicates a signature algorithm using
      RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
      as defined in [SHS].  These values refer solely to signatures
      which appear in certificates (see Section 4.4.2.2) and are not
      defined for use in signed TLS handshake messages, although they
      MAY appear in "signature_algorithms" and
      "signature_algorithms_cert" for backward compatibility with
      TLS 1.2.

Similar things are said about those involving SHA-1 and other "legacy" schemes.

My reading is that this permits the inclusion of the related signature schemes in CertificateRequest messages.  These can't really be used in CertificateVerify, so there are some interesting corner cases to consider, like the case where only unusable schemes are listed.

I don't think that this rises to erratum level, but it's a bit of a problem.  Ideally, we'd fix this in a subsequent version by saying some more about CertificateRequest.  But then maybe this backward compatibility stuff will no longer be necessary when that time comes (he says optimistically/naively).

Is this right?  How do you think we should track this problem?

---

From: Hubert Kario <[email-masked]>
Date: Mon, 03 Jun 2019 13:52:45 +0200

On Monday, 3 June 2019 03:29:47 CEST Martin Thomson wrote:
> My reading is that this permits the inclusion of the related signature
> schemes in CertificateRequest messages.  These can't really be used in
> CertificateVerify, so there are some interesting corner cases to consider,
> like the case where only unusable schemes are listed.

or unusable together with unknown - consider PKCS1_v1_5 with ed25519 when the 
client doesn't support ed25519

> I don't think that this rises to erratum level, but it's a bit of a problem.
>  Ideally, we'd fix this in a subsequent version by saying some more about
> CertificateRequest.  But then maybe this backward compatibility stuff will
> no longer be necessary when that time comes (he says
> optimistically/naively).

yes, ideally the RFC should be more prescriptive about handling of situation 
when all sigalgs in CR are unusable to the client, but given the RFC overall 
and Alert description explanations, I think sending handshake_failure in such 
situation is quite uncontroversial.
and of course, the client MUST NOT abort the connection upon seeing such 
legacy values in CR message
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic