I reviewed the text of Section 3.4 in draft-ietf-trans-threat-analysis-09.txt and, unfortunately, the text in the section is still incorrect.

On 09/14/2016 12:25 PM, Stephen Kent wrote:
David,

Thanks for providing text and a diagram. I think your characterization of this class of attacks is very good; it's generally concise and very clear. It's better that what I wrote.

I a number of edits to your text. I reduced the length of some long (4-5) line sentences, and referred to an attacker (vs. the CA) where appropriate. (An attacker would supply a cert chain to a browser, but the attacker is not acting as a CA in that context.)

I included (revised) text that I used to describe ways that a browser can be steered toward specific revocation status data by an attacker, since IO think this helps explain the subtle issues of why revocation is problematic. I retained most of your text about possible remedies.

The first four paragraphs of Section 3.4 describe an attack in which a CA certificate issued to a malicious CA is revoked, but the bogus certificates issued by the malicious CA are still accepted by browsers since there is a second certificate chain for the certificates that is still valid. This is the attack scenario that Section 3.4 was intended to describe: https://www.ietf.org/mail-archive/web/trans/current/msg01984.html.

Unfortunately, while the next four paragraphs of Section 3.4 are written as if they are continuing to describe the same scenario, they actually describe a totally unrelated scenario; one in which the malicious CA presents the bogus EE certificates as revoked to some entities and as not revoked to others.

There is no reason for these four paragraphs to be there. Section 3.2.1.1.1 mentions that a malicious CA could provide different certificate status information about the same certificate to different targets. Section 3.2.1.1.1 doesn't have separate text mentioning that that could be done with either CRLs or OCSP, but if necessary such text could be added to Section 3.2.1.1.1. But, it doesn't belong in Section 3.4 as it has nothing to do with attacks based on exploiting multiple certificate chains.

In addition problem of paragraphs 5 - 8, which need to be removed from this section, the final sentence of the fourth paragraph also needs to be deleted. The fourth paragraph explains that in the attack, the malicious CA has been issued CA certificates from two different parent CAs. It then explains where the parent CAs may appear within the Web PKI and explains that the malicious CA may have either applied to the parent CAs for the CA certificates or may have compromised the parent CAs and created the CA certificates without the parents knowledge. The sentence that was added to the end of the paragraph says:
If the malicious CA applied for its certificates from these CAs, it may have presented credentials that cause each parent to believe that the parent is dealing with a different CA, despite the fact that the CA name and public key are identical.
This sentence should be deleted for several reasons. The text implies that each of the CAs is aware of the certificate request received by the other CA ("each parent to believe that the parent is dealing with a different CA"), and that the parents know that both certificate requests specify the same subject name and public key ("despite the fact that the CA name and public key are identical"). Even if RFC 5280 permitted different CAs to operate under the same name (it doesn't), the parent CAs should realize there is a problem if two different CAs are supposedly have the same public key, as this would either indicate a stolen public key or the use of a weak key generator.

Even if we were to accept the absurd notion that two different CAs can legitimately operate under the same name and public key, what would lead "each parent to believe that the parent is dealing with a different CA"? Are CA A and CA B sharing so much information that they would know which which CAs the other one is dealing (beyond the information that would appear in the certificates that they issue? If they were sharing so much information, why wouldn't CA B similarly discover when CA A revoked the CA certificate it issued to the malicious CA, especially since that information would be made publicly available by CA A? And if CA B knew that CA A had revoked its certificate to the malicious CA, and that CA B had itself issued a certificate with the same subject name and public key, why wouldn't it revoke its certificate as well. Surely, even if CA B mistakenly believed that its certificate had been issued to a different CA, that any certificates issued by the CA that had just been revoked by CA A could be validated through the path that CA B was providing. And, since CA A and CA B were sharing so much information, surely CA B would know that CA A had revoked the certificate it had issued because it had discovered the subject CA acting maliciously.

The simple solution is to just delete this sentence. It adds nothing to the description of the text, and it is fundamentally flawed in numerous ways.

_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans

Reply via email to