Hi Eran, I really like your proposal. I like it so much that I've implemented the client-side functionality to reconstruct the TBSCertificate and do basic policy checks on the redacted labels. It took me about 45 minutes and I found it very straightforward. (Note I didn't implement the over-redaction check, but this requires the same code no matter how redaction is defined.) I didn't get bogged down like I did with my other implementation. I think this is a huge win for reducing client-side complexity.
I would still like to see the SCT reuse attack fixed. Fortunately, combined with your proposal I think the complexity of fixing the attack is manageable. Here's what I propose (I've implemented the client-side parts of this too): 1. When issuing a redacted certificate, the issuer generates a random 128-bit SALT. The issuer places this SALT in a "Redacted Labels Salt" X.509v3 extension in the unredacted certificate, but not in the logged TBSCertificate. 2. When redacting a LABEL in the "redacted SAN" extension, the issuer replaces LABEL with "?"||HEX(HASH(SALT||LABEL)) instead of just "?" (|| is string concatenation). 3. When reconstructing the TBSCertificate to verify the SCT, the client removes the "Redacted Labels Salt" extension, just as it currently removes the SAN extension and the Transparency Info extension. 4. If the client desires stronger SCT matching, it checks that each redacted label in the redacted SAN extension matches the corresponding label in the SAN extension, by computing HASH(SALT||LABEL), where SALT is taken from the "Redacted Labels Salt" extension. Complexity analysis: 1. There is additional complexity imposed on issuers, but only on issuers who choose to offer redacted certificates, so I believe this is justifiable. 2. Clients need to remove an additional extension when reconstructing the TBSCertificate, but this is trivial and they already have to remove two other extensions anyways. 3. Clients which desire stronger SCT matching have to examine the "Redacted Labels Salt" extension and compute some hashes, which adds modest complexity. However, if a client doesn't desire the stronger SCT matching or can't handle the added complexity for some reason, they can skip this step (they'd ignore everything after the ? in a redacted label) and have exactly the same complexity and security properties as without my proposal. If I'm not mistaken, your proposal plus my proposal address all the technical/implementation concerns that have been raised with redaction. There will still be policy concerns, such as whether redaction is even a good idea, but those can be fleshed out by clients. I think 6962-bis would be delivering a solid technical solution for redaction with these changes. Regards, Andrew P.S. My implementation is here: https://github.com/AGWA-labs/ctredactionexperiment The diff to implement Eran's proposal on top of the RFC6962-compliant code I already had: https://github.com/AGWA-labs/ctredactionexperiment/commit/fbeaa9f3d91ebfd1eb614a657009222b25f37724 The diff to implement my proposal for hash-based label redaction on top of Eran's proposal: https://github.com/AGWA-labs/ctredactionexperiment/commit/d46cfee8eb4374e87c601317f6faa98c4f2e189e _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
