About empty root hints list in "certificate_authorities" extension about rustls

[ctz]

I think we're in the wrong here. I think this text from NIST:

To mitigate this failure, the server shall either: 1) maintain the trust anchors of the various
PKIs whose subscribers are the potential clients for the server and include them in the hints list
or 2) be configured to send an empty hints list (...)

Is talking only in terms of TLS1.2, where certificate_authorities is required to be present by the encoding, but can be empty:

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

However, in TLS1.3 it is in an extension which is defined:

      opaque DistinguishedName<1..2^16-1>;

      struct {
          DistinguishedName authorities<3..2^16-1>;
      } CertificateAuthoritiesExtension;

(the 1 in DistinguishedName means each entry should be non-empty, the 3 in authorities means at least one entry.)

Will do a PR to fix this shortly.

[cpu]

Interesting, thanks for filing a bug (both here and w/ OpenJDK)!

I'm about to log out for the evening but the change to allow an empty list was motivated by NIST.SP.800-52r2 3.5.4 "Server Hints List" where it says (emphasis mine):

To mitigate this failure, the server shall either: 1) maintain the trust anchors of the various
PKIs whose subscribers are the potential clients for the server and include them in the hints list
or 2) be configured to send an empty hints list so that the client can always provide a certificate it
possesses. The hints list shall be distinct from the server’s trust anchor store.

That citation might be helpful context for the Java folks. (Edit: there's also some additional discussion in #1549)

And Java's implementation is supported by following words in the RFC

Since the RFC language in 8446 4.4.2.3 is a SHOULD I don't think the Java position to consider the extension invalid is supported by the text you're citing. 🤔

All that said: I think we added this feature fairly speculatively. If it's causing broad incompatibility with Java it makes sense to revisit!

See my repo: https://github.com/Taowyoo/java-tls13-bug

One other question. In this repo you're explicitly not sending any hints. Wouldn't it be appropriate in this circumstance to be doing what the webpki verifier does by default and populating the hints based on the trust store you use to verify client certificates?

It sounds like the incompatibility is specific to avoiding sending any hints and so I'm hoping you can help explain the motivation for that choice since it's not the default for Rustls own verifier implementations (and apparently causes compatibility issues 😆 )

[Taowyoo]

I'm about to log out for the evening but the change to allow an empty list was motivated by NIST.SP.800-52r2 3.5.4 "Server Hints List" where it says (emphasis mine):

Yes! This will help a lot when try to convince Java folks to accept the change.

Since the RFC language in 8446 4.4.2.3 is a SHOULD I don't think the Java position to consider the extension invalid is supported by the text you're citing. 🤔

Thank you for explaining the meaning of SHOULD.

It sounds like the incompatibility is specific to avoiding sending any hints and so I'm hoping you can help explain the motivation for that choice since it's not the default for Rustls own verifier implementations (and apparently causes compatibility issues 😆 )

The use case is exactly same as your words in original commit:

In some circumstances the server may want the client to send whatever
client certificate it has on hand with no help from the server hints to
decide which will be appropriate.

Our use case is checking peer's certificate with special extension only when server name in SNI matches.

[cpu]

Wouldn't it be appropriate in this circumstance to be doing what the webpki verifier does by default and populating the hints based on the trust store you use to verify client certificates?
...
It sounds like the incompatibility is specific to avoiding sending any hints and so I'm hoping you can help explain the motivation for that choice

Maybe this is something like a (dangerous) configuration where any client certificate is accepted unconditionally and there are no trust anchors in play?

[cpu]

Ahhh! Yes ok, I'm swayed by that argument 👍 Thanks @ctz