Subject: Re: [Trans] threat analysis v06 review

From: Stephen Kent <[email-masked]>
Date: Tue, 26 Jul 2016 13:45:09 -0400

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Jul 2016 09:29:42 -0800

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:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 27 Jul 2016 15:19:13 -0400

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:

Thanks,

Melinda

DKG,

- adopted the terminology you used in your example: CA-A and
CA-B (same

- 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

- 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

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

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

[email-masked]

Trans mailing list

[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Thu, 28 Jul 2016 10:00:01 -0400

David,

> 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.
>
> incorrect and confusing to refer to the attack as involving two CAs 
> with the same name and key.
You have made this statement several times, but I do not recall you 
citing specific text from 5280 that supports your contention.

Although analogies are always imperfect, I'll propose two as a basis for 
rejecting your assertion.

1. When a person is the victim of identity theft, this is analogous to 
an attacker compromising the key of an extant CA and using it to create 
a CA instance with the same name and key as the targeted CA. We do not 
say that the identity thief is the same person as the victim, even 
though that is the goal of the identity thief. We recognize that, in the 
physical world, they are two different entities, even if the identity 
thief appears to be identical to the victim in the eyes of banks, 
government agencies, etc.

2. If an animal is cloned, the resulting offspring may be identical in 
appearance and genetics. Yet the clones are distinct animals, not one 
animal. Again, there is one animal only if one chooses to view the 
animal as beign defined by its appearance and genes, rather that 
physical world presence. This is analogous to an attacker providing 
different contact info (postal and e-mail addresses, etc.), while using 
the same CA name and the same key. These appear as two CAs as far as the 
CAs that issue certs to these entities are concerned.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 28 Jul 2016 11:19:32 -0400

The editor of this document is again
making it clear that he intends to ignore input from the working
group if what the working group wants for the document is
different from what he wants.

The so-called analogies below have nothing at all to do with the
attack scenario that is supposed to be described in the text. The
only thing that comes even close is:

This is analogous to
an attacker providing different contact info (postal and
e-mail addresses, etc.), while using the same CA name and the
same key.

There is nothing in the attack scenario that involves the attacker
providing different contact info to the two CAs from which it is
trying to get CA certificates, but providing different contact
info doesn't make the CA that the attacker is operating into two
CAs.

I could provide text describing the attack scenario that would be
both technically correct and much easier to understand than what
is currently in the document. However, there would be no point in
my spending time writing something like that at the moment, as the
current document editor has made it very clear that any such input
would be ignored.

On 07/28/2016 10:00 AM, Stephen Kent wrote:

David,

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.

You have made this statement several times, but I do not recall
you citing specific text from 5280 that supports your contention.

Although analogies are always imperfect, I'll propose two as a
basis for rejecting your assertion.

1. When a person is the victim of identity theft, this is
analogous to an attacker compromising the key of an extant CA and
using it to create a CA instance with the same name and key as the
targeted CA. We do not say that the identity thief is the same
person as the victim, even though that is the goal of the identity
thief. We recognize that, in the physical world, they are two
different entities, even if the identity thief appears to be
identical to the victim in the eyes of banks, government agencies,
etc.

2. If an animal is cloned, the resulting offspring may be
identical in appearance and genetics. Yet the clones are distinct
animals, not one animal. Again, there is one animal only if one
chooses to view the animal as beign defined by its appearance and
genes, rather that physical world presence. This is analogous to
an attacker providing different contact info (postal and e-mail
addresses, etc.), while using the same CA name and the same key.
These appear as two CAs as far as the CAs that issue certs to
these entities are concerned.

Steve

---

From: Watson Ladd <[email-masked]>
Date: Thu, 28 Jul 2016 09:08:58 -0700

On Jul 28, 2016 8:19 AM, "David A. Cooper" <[email-masked]> wrote:
>
> The editor of this document is again making it clear that he intends to
ignore input from the working group if what the working group wants for the
document is different from what he wants.
>
> The so-called analogies below have nothing at all to do with the attack
scenario that is supposed to be described in the text. The only thing that
comes even close is:
>
>> This is analogous to an attacker providing different contact info
(postal and e-mail addresses, etc.), while using the same CA name and the
same key.
> There is nothing in the attack scenario that involves the attacker
providing different contact info to the two CAs from which it is trying to
get CA certificates, but providing different contact info doesn't make the
CA that the attacker is operating into two CAs.

I care about semantical clarity as much as the next person, but I despite
trying I've failed to understand what meaning CA has here. The two N
certificates are different certificates. In what way does CA mean anything?

> I could provide text describing the attack scenario that would be both
technically correct and much easier to understand than what is currently in
the document. However, there would be no point in my spending time writing
something like that at the moment, as the current document editor has made
it very clear that any such input would be ignored.
>>> 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.
>> 1. When a person is the victim of identity theft, this is analogous to
an attacker compromising the key of an extant CA and using it to create a
CA instance with the same name and key as the targeted CA. We do not say
that the identity thief is the same person as the victim, even though that
is the goal of the identity thief. We recognize that, in the physical
world, they are two different entities, even if the identity thief appears
to be identical to the victim in the eyes of banks, government agencies,
etc.
appearance and genetics. Yet the clones are distinct animals, not one
animal. Again, there is one animal only if one chooses to view the animal
as beign defined by its appearance and genes, rather that physical world
presence. This is analogous to an attacker providing different contact info
(postal and e-mail addresses, etc.), while using the same CA name and the
same key. These appear as two CAs as far as the CAs that issue certs to
these entities are concerned.