Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue CAcertificate

From: [email-masked] (Peter Gutmann)
Date: Fri, 02 Jan 2009 00:11:01 +1300

"Santosh Chokhani" <[email-masked]> writes:

>We are simply not vigilant enough.  This issue has been on our plate since
>2004.

It's not just this, the fact that there were CA certs out there with the CA
flag (in basicConstraints) not set was known for at least five years before
widespread bad publicity forced CAs to address it, the RSA exponent=1 debacle
was known for at least that long but no-one cared until there was lots of bad
publicity about it... there's a really serious problem with CAs and vendors
simply not caring about PKI security until bad publicity forces a change, the
curent MD5 issue (and the mozilla.com cert debacle and the Gromozon malware-
signing cert issue and ...) are just the latest examples.  It's like the
Microsoft of ten years ago, security holes just get ignored until bad
publicity forces a fix (and even then it's often more of a sidestep to avoid
further criticism than an actual fix).

It's small wonder that there's such widespread cynicism about PKI when even
the organisations pushing it don't seem to care whether it's done properly or
not.

Peter.
_______________________________________________
Cfrg mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Sean Shen <[email-masked]>
Date: Sun, 04 Jan 2009 14:56:55 +0800

Hi,
I agree with the value of some document providing analysis of crypto threats
on IETF protocols, RFC4270 (Attacks on Cryptographic Hashes in Internet
Protocols
) did a good job on this. I think more analysis for different IETF protocols
can be provides and this type of information document can be updated
periodically (at least when there is big cryptoanalysis improvement).
Thanks,

Sean 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of RJ Atkinson
>Sent: Thursday, January 01, 2009 3:50 AM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [saag] [Cfrg] Further MD5 breaks: Creating a 
>rogue CAcertificate
>
>
>On  31 Dec 2008, at 14:14, Rich Graveman wrote:
>> For an expert, authoritative, and incredibly up-to-date tutorial on 
>> the state of hash functions, go to http://www.inscrypt.cn/, get the 
>> invited talks, and see the one by Preneel. If the intro material is 
>> boring, flip to slide 45 and start reading. No, MD5 and 
>SHA-1 are not 
>> quite in the same boat.
>
>Those talk about the hash functions generally, but they do not 
>really address the question specifically *as such functions 
>are actually employed by some number of IETF protocols*.  (And 
>just to be clear, I'm thinking quite broadly -- well beyond 
>the narrow realm of hashes as used by certificates.)
>
>A collision attack on some hash function f() might or might 
>not be an issue if f() is used in any of several different 
>modes, for example.
>
>> Unfortunately, the ways cryptologists look at these things and the 
>> ways the IETF uses them are not always the same, so there is 
>more work 
>> to do.
>
>Right.  What I was asking for, specifically, was analysis that 
>considered the various ways that various IETF protocols 
>actually use them -- not abstract concerns that might or might 
>not relate to the way they are actually used by various IETF protocols.
>("ways" means not just deployment model, but also the mode of 
>operation).
>
>One could easily imagine, for example, that some uses of these 
>algorithms might be viewed as entirely fine, with other uses 
>being clearly unsuitable, with a wide range of possibilities 
>in between those two extremes.
>
>It is this specific analysis that is missing, needed, and 
>would be most valuable to various IETF WGs -- if available in 
>a public document (ideally an Informational RFC, developed 
>jointly as a public group effort, such as by the IRTF CFRG, 
>and including full references to the public literature).
>
>My apologies for somehow being unclear in my earlier note.
>
>Thanks,
>
>Ran
>[email-masked]
>
>
>saag mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/saag
>

---

From: [email-masked] (Peter Gutmann)
Date: Tue, 06 Jan 2009 21:43:56 +1300

"Timothy J. Miller" <[email-masked]> writes:

>The only reliable way to nuke a trusted cert from Windows is touch management
>of workstations.

It's worse than that, there is no reliable way to remove trusted certs from
Windows.  See Paul Hoffman's analysis at
http://www.proper.com/root-cert-problem/.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 08 Jan 2009 17:21:22 +1300

"Viviani Paz" <[email-masked]> writes:

>1- browser vendors strongly encouraging the CA organisations vulnerable to
>this problem (using MD5) to get their act together. I'd like to see the
>browser vendors giving them a cut off timeframe and remove these root certs
>from their trust lists for good.

The problem with this is that it's not going to be so easy to tell who's at
fault, the first MD5 cert may not appear until several levels down the food
chain so there's no way to tell whether a particular root ends in an MD5 cert.
And if you do remove a root because some unrelated party five steps down the
food chain uses MD5 I can see lawsuits happening...

>2- meanwhile browser vendors could issue a warning when certificates relying
>on MD5 are in use, this is simpler to be done and shame goes a long way
>sometimes. It doesn't resolve the problem, but sets things in motion.

That one would definitely work, but has the downside of penalising innocent
customers of the CA that issued the cert and not the CA that made the mess.
You'd have to convince the CA to issue free replacements for this to work,
possibly by framing the warning message in terms of the CA using unsafe
practices rather than the site itself being insecure.  Even then it's a rather
indirect approach that doesn't really target the guilty party since you're
scaring the user who is supposed to exert pressure on the site which is then
supposed to pressure the CA for a fix.

(This is one of those great all-care-and-no-responsibility situations, the CAs
can pretty much screw up as much as they want but there's no real
repercussions for anyone because of the collateral damage issue.  The debate
on the Mozilla forums shows this, there's all manner of knee-jerk reactions
possible to make an example of someone convenient but none of them really get
to the root of the problem).

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 08 Jan 2009 20:23:55 +1300

Jeffrey Hutzelman <[email-masked]> writes:

>Perhaps a solution to this is a new model.  

A good start...

>which for a fee provides 

... and it just failed right there.

Peter :-).

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 09 Jan 2009 02:17:44 +1300

Jeffrey Hutzelman <[email-masked]> writes:

>Note that charging a fee for this service is not absurd.  Lots of people
>(consumers) pay fees for up-to-date lists of virus signatures, phishing
>sites, spam-blocking rules, and so on.

Conceptually it's not absurd, but how are you going to persuade a billion-odd
users that they need to pay for something that they've been conditioned to get
for free?  Will you promise to indemnify them against identity theft (via
phishing) if they sign up to your service?  What value-add will you offer that
will convince the drool-and-click masses to pay for your service?

Peter.