Subject: [Trans] [draft2] Working Group Last Call for draft-ietf-trans-threat-analysis (fwd)

From: Paul Wouters <[email-masked]>
Date: Wed, 2 Mar 2016 15:15:18 -0500 (EST)

This starts a two week WGLC for draft-ietf-trans-threat-analysis

https://datatracker.ietf.org/doc/draft-ietf-trans-threat-analysis/

The purpose of the WG Last Call is to get working group consensus that
the document is complete and provides a threat analysis that is useful
to implementors of CT. If you feel this document should not proceed,
please also let us know why you think so.

Please send all comments to the list.

The WGLC ends on March 16, 2016

Paul & Melinda

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Mar 2016 20:42:00 +0000

Ship it!

---

From: Tom Ritter <[email-masked]>
Date: Wed, 2 Mar 2016 16:02:58 -0600

I believe this document should include the dual-CA compromise attack
that dkg illustrated a short while ago.

-tom

On 2 March 2016 at 14:42, Salz, Rich <[email-masked]> wrote:
> Ship it!
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Ben Laurie <[email-masked]>
Date: Fri, 4 Mar 2016 14:13:30 +0000

> that dkg illustrated a short while ago.

+1

---

From: Stephen Kent <[email-masked]>
Date: Fri, 4 Mar 2016 11:16:27 -0500

Good point. I'll try to generate some text to cover this attack, add it, 
and re-publish
when that's done.

Steve

---

From: Bryan Ford <[email-masked]>
Date: Wed, 16 Mar 2016 09:00:58 -0700

I finally had a chance to take a look at the latest version of the threat analysis document.

Months ago, I pointed out that the document presents a lopsided view of the potential types of attacks, in general considering only attacks in which CAs or log servers misbehave “in place”, while completely neglecting even to mention the large class of attack scenarios in which an attacker steals the servers’ keys and uses them to create secret “evil twins” of the CAs and/or log servers elsewhere on the Internet (or off the Internet) in domains more under the attacker’s control.  In other words, the attacker leaves the “normal” CAs and log servers that most of the Internet sees operating completely normally and appearing to be honest, but creates and uses evil twins of those CAs and log servers elsewhere for (basically undetectable) attacks against target victims.

As far as I can see, this entire class of threats is still not even mentioned in the threat analysis document, let alone analyzed.  This seems to me to be a fairly serious omission for a document that is supposed to be a comprehensive threat model analysis for CT.

The currently-raging Apple vs FBI case represents a great example of such a threat, as explained in my recent Freedom to Tinker blog post:

	https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software-transparency/ <https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software-transparency/>

In short, suppose the FBI were attempting to secretly (rather than publicly) coerce Apple to sign their backdoored software update, and further suppose that the iPhone in question used something like Certificate Transparency in attempt to provide transparency to software updates.  The FBI would not need to, and probably would not want to, make Apple’s software update server (i.e., “CA”) misbehave publicly, or to make the CT log servers on which those updates are normally logged misbehave publicly - but they wouldn’t need to.  They could instead just commandeer the keys of the “CA” (Apple’s update server) and any two CT log servers (e.g., any two that conveniently happen to be in the US) - or just coerce the holders of those keys to secretly produce signatures of the FBI’s choosing - to produce not only an apparently correctly-signed software update but also the fake SCTs, signed log-heads, or whatever needed to persuade the CT-enhanced iPhone that the correctly-signed software update has also been “logged”.  

But of course the FBI need not and would not ever need to show those fake signatures or logs to anyone but the iPhone in question, “in utmost secrecy” (the FBI’s words).  The target/victim of the attack in this case is held and thus completely “captured” by the FBI: it will never have any opportunity to gossip with the outside world to compare SCTs or log heads or anything.  Thus, the FBI has created a “evil twins” of both the CA (software update server) and log servers in attacker-controlled territory while leaving the public versions of those services completely untouched and apparently working fine as far as everyone else sees, and CT completely fails to reveal the existence of these evil twins or the “misissuance” (backdoored software updates) they have been used to sign.

If this working group has decided that threats of this form are not of interest or too unlikely to happen (despite the events playing out right now), then I do not have the time to keep arguing the point.  But at the very least, the threat model analysis document should simply pretend that such attack scenarios do not exist at all.

Bryan

> On Mar 2, 2016, at 12:15 PM, Paul Wouters <[email-masked]> wrote:
> 
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Mar 2016 16:49:58 +0000

On 16 March 2016 at 16:00, Bryan Ford <[email-masked]> wrote:
> Months ago, I pointed out that the document presents a lopsided view of the
> potential types of attacks, in general considering only attacks in which CAs
> or log servers misbehave “in place”, while completely neglecting even to
> mention the large class of attack scenarios in which an attacker steals the
> servers’ keys and uses them to create secret “evil twins” of the CAs and/or
> log servers elsewhere on the Internet (or off the Internet) in domains more
> under the attacker’s control.  In other words, the attacker leaves the
> “normal” CAs and log servers that most of the Internet sees operating
> completely normally and appearing to be honest, but creates and uses evil
> twins of those CAs and log servers elsewhere for (basically undetectable)
> attacks against target victims.
>
> As far as I can see, this entire class of threats is still not even
> mentioned in the threat analysis document, let alone analyzed.  This seems
> to me to be a fairly serious omission for a document that is supposed to be
> a comprehensive threat model analysis for CT.
>
> The currently-raging Apple vs FBI case represents a great example of such a
> threat, as explained in my recent Freedom to Tinker blog post:
>
> https://freedom-to-tinker.com/blog/bford/apple-fbi-and-software-transparency/
>
> In short, suppose the FBI were attempting to secretly (rather than publicly)
> coerce Apple to sign their backdoored software update, and further suppose
> that the iPhone in question used something like Certificate Transparency in
> attempt to provide transparency to software updates.  The FBI would not need
> to, and probably would not want to, make Apple’s software update server
> (i.e., “CA”) misbehave publicly, or to make the CT log servers on which
> those updates are normally logged misbehave publicly - but they wouldn’t
> need to.  They could instead just commandeer the keys of the “CA” (Apple’s
> update server) and any two CT log servers (e.g., any two that conveniently
> happen to be in the US) - or just coerce the holders of those keys to
> secretly produce signatures of the FBI’s choosing - to produce not only an
> apparently correctly-signed software update but also the fake SCTs, signed
> log-heads, or whatever needed to persuade the CT-enhanced iPhone that the
> correctly-signed software update has also been “logged”.
>
> But of course the FBI need not and would not ever need to show those fake
> signatures or logs to anyone but the iPhone in question, “in utmost secrecy”
> (the FBI’s words).  The target/victim of the attack in this case is held and
> thus completely “captured” by the FBI: it will never have any opportunity to
> gossip with the outside world to compare SCTs or log heads or anything.
> Thus, the FBI has created a “evil twins” of both the CA (software update
> server) and log servers in attacker-controlled territory while leaving the
> public versions of those services completely untouched and apparently
> working fine as far as everyone else sees, and CT completely fails to reveal
> the existence of these evil twins or the “misissuance” (backdoored software
> updates) they have been used to sign.
>
> If this working group has decided that threats of this form are not of
> interest or too unlikely to happen (despite the events playing out right
> now), then I do not have the time to keep arguing the point.  But at the
> very least, the threat model analysis document should simply pretend that
> such attack scenarios do not exist at all.

I do agree that these attacks can be mounted, and are in fact already
discussed in general in 6962 and 6962-bis (s7.3 for the latter).

I have still not yet had the time to thoroughly review the threat
analysis document, so I can't comment on it at this time.

In general, it seems hard to defend against attacks that permanently
separate their victims from the rest of the world - and it also seems
hard to mount such an attack.

---

From: Bryan Ford <[email-masked]>
Date: Wed, 16 Mar 2016 11:34:41 -0700

> discussed in general in 6962 and 6962-bis (s7.3 for the latter).

I don’t see a section 7.3 in draft-ietf-trans-rfc6962-bis-12, which appears to be the latest version; did the section numbers change recently and you’re referring to a different version?  I would most naturally expect such issues to be discussed in section 12 “Security Considerations”, but see no obvious mention of this class of attacks anywhere in there.

> analysis document, so I can't comment on it at this time.

Perhaps the WGLC shouldn’t close until at least the core CT developers such as you have had a chance to do that review?

> hard to mount such an attack.

Hard to defend: perhaps, but does that justify ignoring that entire threat vector space in a threat analysis document?  And do you (still) maintain that collective signing is not a workable defence against precisely such attacks?  If so, I’m still curious why.

Hard to mount: perhaps, but do you disagree that such an attack appears to be exactly what the FBI is at the moment quite explicitly threatening to perform against Apple (by threatening just to commandeer their signing keys and sign their own backdoored software update)?  And that the FBI appears to be in a perfect position to perform such an attack secretly even against a CT-hardened system, if they didn’t happen to want the publicity like they seem to this time?

Bryan

---

From: Ben Laurie <[email-masked]>
Date: Wed, 16 Mar 2016 19:09:56 +0000

> I don’t see a section 7.3 in draft-ietf-trans-rfc6962-bis-12, which appears to be the latest version; did the section numbers change recently and you’re referring to a different version?  I would m…

Sorry, 7.3 is the relevant section in 6962. I meant 12.4!

"(2) by
   violating its append-only property by presenting two different,
   conflicting views of the Merkle Tree at different times and/or to
   different parties. "

> Perhaps the WGLC shouldn’t close until at least the core CT developers such as you have had a chance to do that review?

WGLC for a document we don't depend on? Why not?

> Hard to defend: perhaps, but does that justify ignoring that entire threat vector space in a threat analysis document?

I have already said I am not commenting on the threat analysis
document at this time.

> And do you (still) maintain that collective signing is not a workable defence against precisely such attacks?  If so, I’m still curious why.

This is not really a question for this group, and I have already
explained why I don't think its a workable solution, as have others.

> Hard to mount: perhaps, but do you disagree that such an attack appears to be exactly what the FBI is at the moment quite explicitly threatening to perform against Apple (by threatening just to com…

No, I don't agree that - the attack they are proposing is against a
single phone, in their possession, whose user is dead. That seems like
a pretty ideal situation for mounting an isolation attack.

I also agree in advance that CT would not defend against such a strong
and narrowly targeted attack.

Since you like this example, I'd love to hear how you think collective
signing would, in detail, for this particular example.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 18 Mar 2016 13:00:25 -0400

Bryan,

Thanks for the feedback.

I added text to address the concerns you cited about the threat analysis 
document
last year, based on comments you made in the London meeting. I don't 
recall you mentioning
this specific concern at that time or in subsequent messages. Can you 
refer me to one or
more specific message in which you cited the oversight you mentioned below?

> Months ago, I pointed out that the document presents a lopsided view 
> of the potential types of attacks, in general considering only attacks 
> in which CAs or log servers misbehave “in place”, while completely 
> neglecting even to mention the large class of attack scenarios in 
> which an attacker steals the servers’ keys and uses them to create 
> secret “evil twins” of the CAs and/or log servers elsewhere on the 
> Internet (or off the Internet) in domains more under the attacker’s 
> control.  In other words, the attacker leaves the “normal” CAs and log 
> servers that most of the Internet sees operating completely normally 
> and appearing to be honest, but creates and uses evil twins of those 
> CAs and log servers elsewhere for (basically undetectable) attacks 
> against target victims.
I will write text to address a class of attacks where a CA's or a a 
log's private key is compromised
and the attack is undetected. I do agree with Ben, however, about the 
difficulty faced by CT or other
mechanisms when users operate in an isolated environment. If a user 
lives in a country where the
telecom infrastructure is controlled by state security forces, there may 
be few if any ways for
the user to acquire externally supplied security info. I don't 
anticipate addressing that topic.

Also, BTW, Eran (a co-author of 6962-bis) provided feedback on the treat 
analysis document,
which was reflected in the -02 version.

Steve

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Mar 2016 13:30:01 -0400 (EDT)

On Wed, 2 Mar 2016, Paul Wouters wrote:

> From: Paul Wouters <[email-masked]>
> To: Trans <[email-masked]>, Melinda Shore <[email-masked]>
> Subject: [Trans] Working Group Last Call for
>     draft-ietf-trans-threat-analysis (fwd)
> 
>

So the WGLC ended but it seems we still need another iteration of the
draft to work out the dual CA compromise attack. I'm also would like
to see a few more people read the document for other issues, as it
seems the discussion mostly focused on this one attack.

We will do another WGLC once Steve has produced another version of
the draft. It would be nice if we could finish this before IETF-95.

Paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 24 Mar 2016 20:41:45 -0400

I concur with Paul's conclusion.

Will push out a new version as soon as the system allows.

Steve