Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 01 Jan 2014 18:22:20 +0000

Rob Stradling:
> On 23/12/13 18:29, Jacob Appelbaum wrote:
>> Phillip Hallam-Baker:
> <snip>
>>> You can't calculate the number of CAs the way the EFF tried to. An
>>> intermediate certificate does not equate to a CA. Pretending it does to
>>> peddle an alternative PKI scheme calls into question their veracity.
>>
>> I disagree strongly. I have an intermediate certificate. I am as
>> powerful CA as a result.
> 
> Jake, you're only that powerful if you control the intermediate private
> key.

I do control the private key for the aforementioned intermediate
certificate[0] authority. :)

... and I'm not the only one, obviously.

Happy new year,
Jake

[0] http://www.win.tue.nl/hashclash/rogue-ca/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Jan 2014 10:40:34 -0800

> certificate[0] authority. :)

No, you really do not. As you certainly know, that attack only applied to a very limited number of CAs in the root piles at the time. I I remember correctly, it applied to zero of them approximately six months later. Please don't overstate the results of the excellent research that you did; doing so diminishes the research.

--Paul Hoffman

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 02 Jan 2014 18:57:01 +0000

Paul Hoffman:
> No, you really do not.

I control the private key for the rouge CA that we created. I'm not the
only one with the private key material - all of my fellow researchers
likely still have it as well.

Perhaps you think that I said something that I didn't say. I'm not
claiming that I have the private key for the CA's actual correct CA
signing key.

> As you certainly know, that attack only
> applied to a very limited number of CAs in the root piles at the
> time.

I'm not sure where you came to this impression? There were a few CAs who
were vulnerable, we picked one to perform the research. It worked. That
work produced a valid signature that we could apply to our second
certificate, which is a sub-CA certificate. Thus, the attack we did only
applied to a single CA and we did not destroy the private key for the
corresponding certificate. So yes, we most certainly do have the private
key for that intermediate certificate authority that we created.

> I I remember correctly, it applied to zero of them
> approximately six months later.

Unless one explicitly distrusts (all) MD5 signed certificates, pre-loads
our certificate to mark it as untrusted, or a few other things relating
to time constraints - it will probably still work for MITM attacks. Many
applications fail to do proper constraint checking.

> Please don't overstate the results of
> the excellent research that you did; doing so diminishes the
> research.

I'm not overstating anything. I think you don't understand what we
actually did if you think that later, patching things will somehow
magically stop previously successful attacks...

All the best,
Jacob

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jan 2014 15:25:04 -0500

> applications fail to do proper constraint checking.

Anyone who trusts MD5 for signing any form of keying material is vulnerable
to this type of attack. It does not matter whether there is a CA involved
or not or the number of sub CAs. A variation of the attack could be
performed on PGP or DNSSEC.

The fix here is to disable MD5 completely in the browser or for CAs to not
use MD5 in any certificate. The industry has chosen to do the second since
we can't actually recall legacy browsers. However, Microsoft's recent
decision to end of life SHA-1 will have the effect of rendering most of the
legacy browsers unusable in any case.

> magically stop previously successful attacks...

You are confusing people by using a valid attack against the algorithm to
argue against the trust model. PKIX is designed on the assumption that the
digest algorithm chosen is secure against a second preimage attack.

We have a lot of security issues to deal with right now and we want to make
sure we are paying attention to the ones that matter most. This is really
not helping.

-- 
Website: http://hallambaker.com/

---

From: Leif Johansson <[email-masked]>
Date: Thu, 2 Jan 2014 22:00:08 +0100

> 2 jan 2014 kl. 21:25 skrev Phillip Hallam-Baker <[email-masked]>:
> 
> 
> 
> 
> Anyone who trusts MD5 for signing any form of keying material is vulnerable to this type of attack. It does not matter whether there is a CA involved or not or the number of sub CAs. A variation of the attack could be performed on PGP or DNSSEC.
> 
> The fix here is to disable MD5 completely in the browser or for CAs to not use MD5 in any certificate. The industry has chosen to do the second since we can't actually recall legacy browsers. However, Microsoft's recent decision to end of life SHA-1 will have the effect of rendering most of the legacy browsers unusable in any case.
> 
> 
> 
> You are confusing people by using a valid attack against the algorithm to argue against the trust model. PKIX is designed on the assumption that the digest algorithm chosen is secure against a second preimage attack.

The fundamental flaw in the pkix trust model is that there is no deployable mechanism for limiting the impact of such an attack.

That realization should inform future design and that bit is certainly on topic ;-)

> 
> We have a lot of security issues to deal with right now and we want to make sure we are paying attention to the ones that matter most. This is really not helping.
> 
> -- 
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 2 Jan 2014 16:57:57 -0500

On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson <[email-masked]> wrote:

> The fundamental flaw in the pkix trust model is that there is no
> deployable mechanism for limiting the impact of such an attack.
>

It is on topic but not limited to PKIX.

We have since learned that algorithm agility is not quite the security
benefit we once thought as the security of the system is determined by the
weakest algorithm you support, not the strongest one you implement.

Problem is that I can't see a way to really control this type of attack
without a very considerable cost in usability and I think it would
constrain other defenses.

Anyone using Windows XP in the Enterprise for any purpose other than
finding viruses is guilty of security malpractice at this point. It is an
obsolete OS that would have been at EOL if lazy sysadmins hadn't begged to
keep it.

My current solution in my email project is to attempt to require SHA512 for
all certificates. But I am not sure that is actually sustainable.

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 2 Jan 2014 22:09:08 +0000

LTANS WG had produced an RFC (RFC 5698) to protect the relying parties from weak algorithms.

If that RFC is implemented on the certificate consuming side, these attacks will be thwarted.

From: therightkey [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, January 02, 2014 4:58 PM
To: Leif Johansson
Cc: [email-masked]; Paul Hoffman; Jacob Appelbaum
Subject: Re: [therightkey] DNSNMC deprecates Certificate Authorities and fixes HTTPS security

On Thu, Jan 2, 2014 at 4:00 PM, Leif Johansson <[email-masked]<mailto:[email-masked]>> wrote:

We have since learned that algorithm agility is not quite the security benefit we once thought as the security of the system is determined by the weakest algorithm you support, not the strongest one you implement.

Problem is that I can't see a way to really control this type of attack without a very considerable cost in usability and I think it would constrain other defenses.

Anyone using Windows XP in the Enterprise for any purpose other than finding viruses is guilty of security malpractice at this point. It is an obsolete OS that would have been at EOL if lazy sysadmins hadn't begged to keep it.

My current solution in my email project is to attempt to require SHA512 for all certificates. But I am not sure that is actually sustainable.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 2 Jan 2014 23:16:27 +0100

> 2 jan 2014 kl. 22:57 skrev Phillip Hallam-Baker <[email-masked]>:
> 
> 
> 
> 

A trust model based on shorter-time-to-live keys would have limited the impact too.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Jan 2014 14:50:42 -0800

On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum <[email-masked]> wrote:

> I control the private key for the rouge CA that we created.

True. However, that rogue CA is not trusted in any root pile, right? You holding a private key for a trusted CA was, appropriately a big deal. You holding a private key for an untrusted CA is uninteresting.

> I'm not sure where you came to this impression?

By counting the number of CAs who used MD5 and had predictable serial numbers.

> There were a few CAs who

All true, but no longer relevant.

> to time constraints - it will probably still work for MITM attacks.

It sounds like you are saying that the contents of the issued certificates don't need to be predictable for the collision to happen. That would be absurd. Again, please don't overstate the value of your demonstration. It was a very good thing because it got people to look and *and fix* the problem. Can you point to a single CA in any of the common trust stores that both use MD5 and issue certificates with less than 2^64 bits of unpredictability?

> Many

Which is just fine. It should be up to the people putting together the trust pile to do the checking, not the relying parties.

> I'm not overstating anything.

We disagree.

> I think you don't understand what we

Ummm, where did I say anything about "patching"? I said that I believed that there were no more CAs who were vulnerable, and asked you to show where you thought there was. If you're right, then that's very valuable information. I don't see any more in the trust piles that I look through, but I could be missing something.

--Paul Hoffman

---

From: Leif Johansson <[email-masked]>
Date: Fri, 03 Jan 2014 13:07:53 +0100

> True. However, that rogue CA is not trusted in any root pile, right? You holding a private key for a trusted CA was, appropriately a big deal. You holding a private key for an untrusted CA is unint…

My understanding of what Jakob wrote is that he holds the key for a
subordinate CA. Unless the CA that "signed" that subordinate has been
removed from trust lists then that subordinate would still be useful, yes.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 03 Jan 2014 14:24:09 +0100

Hi,

> subordinate CA. Unless the CA that "signed" that subordinate has
> been removed from trust lists then that subordinate would still be
> useful, yes.

The subordinate certificate is blacklisted in browsers. Furthermore,
Mozilla does not accept any non-root certs with MD5 signatures since
mid-2011.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Leif Johansson <[email-masked]>
Date: Fri, 03 Jan 2014 15:29:58 +0100

> Mozilla does not accept any non-root certs with MD5 signatures since

Assumes you run an updated browser, right?

Blacklisting isn't part of the PKIX trust model, but a band-aid used to
fix the lack of deployed/able revocation.

        Cheers Leif

---

From: Rob Stradling <[email-masked]>
Date: Fri, 03 Jan 2014 15:28:11 +0000

> Assumes you run an updated browser, right?

Yes.

There's only so much we can do to protect folks who don't update their 
browsers.  It seems very unlikely that MD5 signatures are the biggest 
threat that they face.

> fix the lack of deployed/able revocation.

So?

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

---

From: Ralph Holz <[email-masked]>
Date: Fri, 03 Jan 2014 18:12:22 +0100

Hi,

> Assumes you run an updated browser, right?

I think the cert was blacklisted immediately after the publication/talk,
that means at least 4 years ago. At least in IE, the auto-update may
have helped. Not sure about the Fox.

There really is nothing we can do for users that haven't updated since.
Any 2nd Web site they may visit may exploit those old vehicles.

> fix the lack of deployed/able revocation.

Tell me something new. ;-) Although in fact, the whole thing goes much
deeper. A broken hash algorithm means root cert-like compromise as it
means the capacity to imitate a correct signature by a root cert. There
is no fix for this but blacklisting. Not in any model with TTPs, by the way.

Ralph

---

From: Carl Wallace <[email-masked]>
Date: Fri, 03 Jan 2014 12:15:31 -0500

>is no fix for this but blacklisting. Not in any model with TTPs, by the

You mean blacklisting the algorithm, right?

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 03 Jan 2014 17:18:28 +0000

<list moderator hat on>

Folks - Phill is right that the subject line here is wrong.

Please fix if there's more to be discussed on this topic.

And I'd welcome some more discussion on CT and the proposal
to form a WG. Some drafts would be even better!

S.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 03 Jan 2014 18:19:42 +0100

Hi,

> You mean blacklisting the algorithm, right?

Ultimately, yes. That's what Moz etc. did, but you cannot force CAs to
switch to new algorithms at once. New root certs have to be added to the
root stores, new certs issued for existing customers, etc. Thus the
grace period until 2011.

In the meantime, all you can do is blacklist known-rogue certs.
Alternatively, pull the root cert from which MD5 signatures were issued.
As the MD5 attack still had considerable cost (for the hobby blackhat,
not a 3-letter agency), it was deemed that this must suffice for a while.

Ralph

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 03 Jan 2014 17:42:17 +0000

Leif Johansson:
>> True. However, that rogue CA is not trusted in any root pile,
>> right? You holding a private key for a trusted CA was,
>> appropriately a big deal. You holding a private key for an
>> untrusted CA is uninteresting.
>> 
> 

Yes, that is correct. And only people like Firefox actually ship it and
explicitly distrust it, I believe. Perhaps others have followed since
our original research. There are a few reasons a browser or program may
not trust it - generally speaking, the expiry date is what we added to
ensure that it wouldn't be abused. That is easy to solve though - just
attack NTP first! :-)

All the best,
Jacob