Subject: [TLS] Empty CertificateRequest.supported_signature_algorithms in TLS 1.2

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Nov 2018 08:50:21 +1100

In attempting to fix a bug related to this, a question came up about
what the semantics of an empty value is here.  Some implementations
seem to infer that empty means {*,SHA1}, which effectively assumes
that an empty value is equivalent to an absent signature_algorithms
extension (Section 7.4.1.4.1)

The text on CertificateRequest is less clear about what to do.  That's
understandable because it doesn't have to deal with the value being
absent because it's not optional.  All we have to go on is this from
Section 7.4.8:

   The hash and signature algorithms used in the signature MUST be
   one of those present in the supported_signature_algorithms field
   of the CertificateRequest message.

We think that treating an empty supported_signature_algorithms field
as an error is the best response and plan to implement that change.
We'll send a fatal alert if we receive one.

This is consistent with our handling of the signature_algorithms
extension, where we treat an empty list as a failure.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Nov 2018 16:56:43 -0500

> On Nov 21, 2018, at 4:50 PM, Martin Thomson <[email-masked]> wrote:
> 
> [...]

Sounds reasonable, provided the application did or would have actually
provided a client certificate to use.  If the application would have
continued with an empty certificate list, and no CertificateVerify,
then hanging up is arguably counter-productive.  Of course the server
should still not send a certificate request that could never be satisfied,
so perhaps snatching victory from the jaws of defeat is not worth the
trouble even when the client has no certificate to send?

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Nov 2018 14:00:55 -0800

> We'll send a fatal alert if we receive one.

Yes, I believe this is the right approach.

-Ekr

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: David Benjamin <[email-masked]>
Date: Wed, 21 Nov 2018 16:08:43 -0600

> extension (Section 7.4.1.4.1)

In the ClientHello, I believe an empty signature_algorithms extension is
invalid. The structure is defined as:

      SignatureAndHashAlgorithm
        supported_signature_algorithms<2..2^16-2>;

BoringSSL enforces this. If your ClientHello has an empty
signature_algorithms extension, we will reject it. If it is missing, we do
interpret it as {*, SHA1}, as TLS 1.2 (mistakenly) prescribes.

> extension, where we treat an empty list as a failure.

Sadly, the structure itself has a syntax error, so it's unclear whether
empty is allowed or not. :-)

      struct {
          ClientCertificateType certificate_types<1..2^8-1>;
          SignatureAndHashAlgorithm
            supported_signature_algorithms<2^16-1>;
          DistinguishedName certificate_authorities<0..2^16-1>;
      } CertificateRequest;

We do tolerate empty and give it the same {*, SHA1} interpretation as
ClientHello, since they go through the same logic, but I agree with you
that the specification does not actually say it applies to both. Rejecting
the empty list sounds like a good idea, assuming it's compatible with
current implementations. The 7.4.8 citation looks right, and rejecting it
makes sense on general principle. IMO, the default {*, SHA1} bit in TLS 1.2
was a mistake. It's caused unnecessary confusion, resulting in buggy TLS
1.2 servers that only sign SHA-1.

Maybe we should errata this by fixing that <2^16-1> to <2..2^16-1>?

David

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Nov 2018 10:53:24 +1100

> Maybe we should errata this by fixing that <2^16-1> to <2..2^16-1>?

https://www.rfc-editor.org/errata/eid2864 was filed a while ago.
Apparently also erratum 1585 found an error.

We really need a view of these documents that includes errata.