Re: [Trans] threat analysis v06 review

[David A. Cooper]

Unfortunately, I must yet again point out that there has still been no attempt to address the issues that I and a few others have pointed out with this document. I have explained on multiple occasions that it is both technically incorrect and confusing to refer to the attack as involving two CAs with the same name and key. On May 19, Bryan Ford sent a message saying: I agree with David Cooper that describing this as “two CAs” is rather strange given the assumption that they have “the same Subject name and public key”.  I would call that “One Malicious CA with Two Certificate Chains” or something like that. On June 10, DKG wrote that: This paragraph seems wrong to me. The compromised CAs in question are *not* the same CA, though they do need to create at least one "doubled" intermediate CA that shares at least the same key (and likely, the same Subject). Perhaps it would be better to think about "compromised CA keys" instead of "compromised CAs", and leave the mechanism of compromise out of the technical discussion? While it is clear that Steve Kent very much wants the text to remain as it is, technical correctness and the WG consensus needs to take priority over the personal preferences of the editor. On 07/27/2016 01:29 PM, Melinda Shore wrote: Hi, all: Please take a look at the revised document and let us know if your concerns have or have not been addressed, and we'll be restarting working group last call shortly. Thanks, Melinda On 7/26/16 9:45 AM, Stephen Kent wrote: DKG, Thanks for the review and detailed comments. In response to your comments I made the fallowing changes: - added reference to the gossip doc in the introduction - removed all use of the term "doppelganger" - adopted the terminology you used in your example: CA-A and CA-B (same name, same key pair) and bogus cert X. - revised text to note that the two CA instances that appear as issuer of the bogus EE cert need not have different trust anchor ancestors. - revised text to include a scenario in which one CA is compromised and caused to issue the bogus cert (which is logged and, maybe revoked) while the second instance of the CA is malicious and has a parent that may be malicious or may have been tricked or attacked, etc. - revised the title of 3.3 to reflect the broader range of scenarios as per your example I did not explore the potential for logs to discriminate wrt the certs they log. I also did not discuss possible enhancements to the Monitor function to detect AIA manipulation and the like. I did not discuss in greater detail the non-standard mechanisms that may be used by browsers to deal with revocation. I think it suffices to note that such mechanisms may use cert hashes or keys to identify revoked certs, and that such approaches are not path-specific. I retained the discussion of how OCSP or CRLs and AIA extensions might be used to prevent a browser from learning about the true revocation status of a bogus cert. Yes, these are not vulnerabilities of CT per se, but they are part of the standards-based ecosystem in which CT operates. I have attached a PDF showing the revised text in 3.3, where most of the changes were made. Steve _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans