search

csosto-pk / tls-suppress-intermediates

Suppress intermediate certificates in TLS
Other
0 stars 0 forks source link

Constrained intermediates not published publicly #6

Closed csosto-pk closed 2 years ago

csosto-pk commented 2 years ago

In WebPKI, there are some cornercases (constrained ICAs) where the client might be missing a certificate or certificates in the chain. Currently the WebPKI root program rules allow not disclosing "technically constrained" certificates (but there are plans to change this).

csosto-pk commented 2 years ago

From Martin

As I've said before (I think) a lot hinges on the semantics of the tls_flags bit. I don't think that we can say that it means "I have all the intermediates I am willing to accept". That's a little too absolute for the web PKI as it stands. Right now, we (as a client) have knowledge of all the intermediates without technical constraints (like name constraints), which goes a long way, but an unqualified claim like that would amount to a lie for us.

I don't have stats on how often we'd fail as a result; I'd have to check with others. It might take a very long time to find out if we don't have metrics already.

We /can/ retry, but as you say it's a big performance hit that we'd only want to pay if we hit exceptional circumstances. My sense is that unconstrained intermediates isn't exceptional.

I am inclined to push for a semantic of "I have all the unconstrained intermediates that I'm willing to accept". Or maybe "I have all the intermediates from that I'm willing to accept, unless it's the WebPKI and then I only have unconstrained intermediates"' if someone wants to assert that enumerating all the constrained intermediates is a reasonable ask in other settings. A context-dependent interpretation is also possible, though that seems like a recipe for accidental interoperability failure. If we specify an automatic retry, that sort of thing becomes a latent performance bug, which I'd prefer to avoid.

csosto-pk commented 2 years ago

https://blog.mozilla.org/security/2021/12/09/improved-quality-of-intermediate-certificates-with-enhanced-oversight-and-automation/ says MSRP 2.8 will require constrained intermediates. In that case then "I have all the intermediates I am willing to accept" may just suffice.

csosto-pk commented 2 years ago

From Ilari

I would expect constrained intermediates to be quite rare. IIRC, there is a lot of red tape in Baseline Requirements about constrained ICAs.

csosto-pk commented 2 years ago

From Ilari, regarding potential solutions

MSRP 2.8 is slated for this year, so it might very well fix this issue for WebPKI.

Another way to address the issue would be to write some text that the server might want to send any ICA that has not been publicly disclosed. As that is neutral to PKI and is exactly what makes constrained ICAs problematic here.

csosto-pk commented 2 years ago

Added text in commit https://github.com/csosto-pk/tls-suppress-intermediates/commit/c705a7242f31a8c7b3de2832a9e9f351790b6c80

For example, if the client's certificate chain contains ICAs with technical constraints which are not disclosed, the client SHOULD send the chain back to the server regardless of the ICA suppression flag in the CertificateRequest. [EDNOTE: MSRP 2.8 may require constrained intermediates which would mean this could change for WebPKI.]

For example, if the server's certificate chain contains ICAs with technical constraints which are not disclosed, the server SHOULD send the chain back to the client regardless of the suppression flag in the ClientHello. [EDNOTE: MSRP 2.8 may require constrained intermediates which would mean this could change for WebPKI.]

csosto-pk commented 2 years ago
csosto-pk commented 2 years ago

MSRP 2.8 was published https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

And it reads

[...] Name-constrained CA certificates that are technically capable of issuing working server or email certificates that were exempt from disclosure in previous versions of this policy MUST be disclosed in the CCADB prior to July 1, 2022.

All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part.

We recognize that technically constraining intermediate certificates as described above may not be practical in some cases. All certificates that are capable of being used to issue new certificates, that are not technically constrained, and that directly or transitively chain to a certificate included in Mozilla’s root store MUST be audited in accordance with this policy. If the CA operator has a currently valid audit report at the time of creation of the intermediate certificate, then the new intermediate certificate MUST appear on the CA operator's next periodic audit reports.

So, it now requires name-constrained CA to disclosed to CCADB, but not all constrained CAs. Not sure how many non name-constrained CAs there are, but it sounds like it makes our life a little easier and name-constrained CAs will now be known.

csosto-pk commented 2 years ago

Since MSRP now requires name-constrained CA to disclosed to CCADB, but not all constrained CAs, that means that there will be even less cases in WebPKI where CAs will not be disclosed and thus not available to the peer. Thus less chances for failure. There may still be some limited cases of non name-contrained CAs which are not disclosed, so we will still keep the text

To prevent a failed TLS connection, a server could choose to send its intermediates regardless of the flag from the client, if it has a reason to believe the issuing CAs do not exist in the client ICA list. For example, if the server's certificate chain contains ICAs with technical constraints which are not disclosed, the server SHOULD send the chain back to the client regardless of the suppression flag in the ClientHello.

MSRP EDNOTE was deleted in commit https://github.com/csosto-pk/tls-suppress-intermediates/commit/2fc7eedae889485c81c4186b66987870ddb6a932