Subject: Re: [Trans] draft-ietf-trans-threat-analysis and DKG's conspiring CAs attack

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Sep 2016 12:25:46 -0400

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.

A new version of the I-D will be posted soon.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 23 Sep 2016 16:20:19 -0400

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.