Subject: [Trans] Threat document - status and question

From: Melinda Shore <[email-masked]>
Date: Wed, 8 Jun 2016 10:47:22 -0800

Hi, all:

We'd like to restart working group last call on the threat
analysis draft 
(https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/)
but I wanted to make sure that any serious concerns have been
addressed.  In particular, it seems as if there may be some
unresolved questions about the conspiring CA attack identified
by DKG.

Do you all feel that the document is ready for working group
last call, and that any issues blocking it from being sent on
to the IESG have been resolved?

Thanks,

Melinda

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 08 Jun 2016 21:50:13 +0300

Dear Melinda,

There was a discussion about one more possible attack related with name 
redaction. (Letter by
Andrew Ayer on June 6 ).

Is not it a subject to include in the document?

Thank you!

On 08.06.2016 21:47, Melinda Shore wrote:
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

-- 
SY, Dmitry Belyavsky

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 8 Jun 2016 16:03:14 -0400

Unfortunately, the concerns have not been addresses. I pointed out in a 
message on April 26 that the text still incorrectly referring to the 
malicious CA issuing the bogus EE certificate as two CAs, and my message 
was ignored.

Byran Ford sent a message on May 19 agreeing that the current text is 
"rather strange." Steve Kent just responded by adding more text to the 
document rationalizing his decision to refer to the malicious CA as "two 
CAs."

So, the text is still unnecessarily confusing and it still contains 
information that is technically incorrect.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 9 Jun 2016 11:29:26 -0400

Dmitry,

I've been waiting for Rob Stradling to comment on the attack described 
by Andrew.
I consider Rob to be the definitive expert on redacted certs (since he 
invented
the concept) and I want to make sure that Ron concurs with the attack 
description
and the impact characterization before adding it to the threat document.

If Rob concurs, then I'll draft text to describe the attack and submit 
it to the
WG list for review, rather than re-issuing the whole doc with this added 
material
for review.

Andrew's message noted a potential problem for Monitors dealing with 
redacted certs.
The Monitor spec that I co-authored 
(draft-kent-trans-monitor-auditor-01.txt) already
describes a model in which Monitors are expected to have access to the 
cert data
associated with the Subjects they serve. So, in the case of redacted 
certs, I think a
Monitor serving the Subject(s) of such certs will be able to function as 
expected.
Eran suggested that a Monitor need not have such info and might be on 
the lookout
for suspect certs in general, but I have trouble understanding how that 
will work,
in general. I have not reviewed version 16 of 6962-bis, but I found 
prior descriptions
of the Monitor function to be too vague. So, I'll mention the Monitor 
problem, as well
as the CT-aware browser problem (re SCT matching), in the text I prepare.

Steve

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 9 Jun 2016 11:44:50 -0700

On Thu, 9 Jun 2016 11:29:26 -0400
Stephen Kent <[email-masked]> wrote:

> Dmitry,
> 
> I've been waiting for Rob Stradling to comment on the attack
> described by Andrew.
> I consider Rob to be the definitive expert on redacted certs (since
> he invented
> If Rob concurs, then I'll draft text to describe the attack and
> submit it to the
> WG list for review, rather than re-issuing the whole doc with this
> added material
> for review.

I would much rather the attack be fixed (I described one possible fix)
than merely describing it in the threat document.  Is this not an
option?

> describes a model in which Monitors are expected to have access to
> the cert data
> Monitor serving the Subject(s) of such certs will be able to function
> as expected.

No, even if a monitor has access to full cert data, they aren't
maximally useful when redaction is used (I consider this unexpected).
If a monitor is configured with:

	www1.example.com should have key A
	www2.example.com should have key B

and it sees a pre-cert for ?.example.com using key A, it can't
say for certainty whether this is OK, because the pre-cert might be for
www1.example.com, or it might be for www2.example.com.
draft-kent-trans-monitor-auditor-01.txt says to accept the pre-cert in
this case, which makes it possible to launch the attack I described.

> the lookout for suspect certs in general,

Name redaction does pose a challenge to monitors without access to cert
data, but this is a separate issue, and I don't think it can ever be
resolved.  However, we can and should make it possible for monitors
with access to cert data to function usefully when name redaction is
used.

Regards,
Andrew

---

From: Rob Stradling <[email-masked]>
Date: Fri, 10 Jun 2016 15:31:07 +0100

Steve,

I consider the consensus of this WG to be "the definitive expert".  :-)

FWIW though, I concur with Andrew's attack description and impact 
characterization.  Regarding fixing it: I'd rather nuke the redaction 
option than add further complexity.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Andrew Ayer <[email-masked]>
Date: Fri, 10 Jun 2016 11:34:01 -0700

On Fri, 10 Jun 2016 15:31:07 +0100

> option than add further complexity.

I think the removal of redaction should be considered.  For those who
haven't been following Chrome's ct-policy list, Chrome has announced
that they will not be supporting redaction, at least until a list of
concerns is addressed:

https://groups.google.com/a/chromium.org/d/msg/ct-policy/fCt4Bm03GsI/jBbqE_QWBQAJ

Addressing those concerns may require additional standardization (e.g.
a CAA property for domain owners to opt-in to redaction). If there's
still interest in redaction, it could be done in a future document,
along with the necessary work to make it acceptable to Chrome. In the
meantime, someone might find a simpler way to address this attack.

Regards,
Andrew

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jun 2016 10:55:07 -0400

Andrew,

> ...
Not for me to say. But I agree that the issue you cited is troubling.
> ...

Yes, a Monitor serving www1 would think the log entry was OK,
even though it also would match www2. But, this requires that www2
has the same key as www1. If there was a compromise of www1, then
I agree that a Monitor would not detect the compromise, but a
Monitor isn't really intended to do that. If this represents collusion
between www1 and www2 then this is good example of how colluding
Subjects could use an SCT issued for one Subject with a cert for
another Subject, because of the properties of redacted certs. Got it.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Jun 2016 10:57:48 -0400

Rob,

> I consider the consensus of this WG to be "the definitive expert".  :-)
If the WG had more folks commenting on more topics I'd agree, but ...
> option than add further complexity.
I'm in favor of removing the redaction option. It's one of the more 
complex aspects
of CT and if you, as its creator are comfortable holding off for now, I 
think that
would be a good action.

Steve

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 15 Jun 2016 11:04:31 -0700

On Mon, 13 Jun 2016 10:55:07 -0400
Stephen Kent <[email-masked]> wrote:

> Andrew,
> 
> 
> 
> > ...
> > I would much rather the attack be fixed (I described one possible
> > fix) than merely describing it in the threat document.  Is this not
> > an option?
> > maximally useful when redaction is used (I consider this
> > unexpected). If a monitor is configured with:
> >
> > say for certainty whether this is OK, because the pre-cert might be
> > for www1.example.com, or it might be for www2.example.com.
> > draft-kent-trans-monitor-auditor-01.txt says to accept the pre-cert
> > in this case, which makes it possible to launch the attack I
> > described.
> 
> Monitor isn't really intended to do that. 

Alternatively, www1 could be operated by a third party who holds the
private key (not an uncommon scenario).  I think a Monitor should be
expected to detect an attempt by that third-party to misuse their key to
impersonate www2.

> If this represents collusion

It doesn't require collusion between the subjects.  Rather, one subject
colludes with the CA to attack the other subject.

Regards,
Andrew

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Jun 2016 09:40:48 -0400

Andrew,

> expected to detect an attempt by that third-party to misuse their key to
I agree that the purpose of a Monitor is to detect cert mis-issuance and 
having www2 be able to use the same SCT as www1 is an example of such.

If the private key for www1 is held by another party because that party 
is running the web site on behalf of the entity responsible for www1, 
then www1 already has a serious vulnerability. Is there some other case 
where you envision www1 will grant a 3rd party access to its private key?
> colludes with the CA to attack the other subject.
Yes, because name-redaction requires a pre-cert, and only a CA can 
submit a pre-cert, the CA issuing the pre-cert has to be complicit. 
Thanks for the clarification.

Steve