Dear fellow X.509 aficionados, I'd like to share some observations and an idea from a PKIX sibling of the WebPKI used for Internet routing security. Technical innovation should of course follow the IETF process; I'm sending this message here to offer myself as a point of contact for further off-list discussion with interested parties.
On Fri, Oct 07, 2022 at 10:01:35AM -0400, Andrew Ayer wrote: > Right. I'm not seeing any way for a client to avoid the attack > described by Corey without making assumptions about the CA's practices > which might not be true in all cases. > > So I have to concur with Corey that there is currently a security > issue which would allow attackers to tamper with Apple and Mozilla > revocation systems. > > A simple fix would be to require that CAs use HTTPS URLs for CRL > shards, though this wouldn't be as strong as relying on indicators > within the CRL itself. The issue at hand appears to be similar to some challenges the Resource Public Key Infrastructure (RPKI) community faced when designing the foundation for a Secure Internet Routing architecture [RFC6480]. [ crash course: The RPKI is a constellation of Trust Anchors (root certs, aka unconstrained CAs), regular CAs (each more narrowly constrained following hierarchical IP & AS resource delegations), CRLs, and lots of Signed Objects (containers carrying EE certificates and payloads relevant to BGP routing). A key point here is that the distribution of RPKI data from CAs towards Relying Parties solely relies on object security, not transport security like HTTPS. ] Some risks were identified at the time: (1) RPs must be able to verify they have the complete set of files in hand the CA intended them to have; (2) none of the files were tampered with mid-flight; (3) the RP is not falling victim to replay attacks of previously valid data. To mitigate the above risks, the concept of "Manifests" was introduced. A RPKI Manifest [RFC9286] is a Cryptographic Message Syntax (CMS) protected content type which carries as payload a monotonically increasing value (manifestNumber) and a listing of pairs of a file name and SHA-256 message digests calculated over the file's contents. Each Manifest listing contains the filename of a CRL and the SHA-256 of that CRL file. As a certificate can list multiple CRL Distribution Point URLs (pointing to shards), the WebPKI RP can establish there is a set of files to consider, and for each file can verify the issuer signature; but cannot verify whether each file within the set is the most current one, (or whether the set of files are coherent from a versioning perspective). On the other hand, RPKI RPs are 'better off' in this regard: they can compare whether the newly fetched Manifest has a higher manifestNumber than the (previously fetched, locally cached) Manifest, and each manifestNumber corresponds to a list of SHA-256 hashes; making for a great mechanism to robustly deal with distribution bundles of files. Perhaps a bit of glue is missing in this ecosystem if there are concerns about replay attacks (or more innocently phrased 'caching decoherence'), and CRL sharding? Maybe researchers & auditors would benefit from a RPKI-Manifest-like extension to the products generated by the likes of Boulder? I'm happy to share what I know (having authored a few internet-drafts and some experience implementing RPKI RP software). Perhaps there is an opportunity here to do better than 'just put the files on HTTPS'! :-) Kind regards, Job -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/Y0BlqjqWwjhgC/A3%40snel.
