Subject: Re: [therightkey] algorithm blacklisting

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

On 1/3/14, 12:19 PM, "Ralph Holz" <[email-masked]> wrote:

>Hi,
>
>>> 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.
>> 
>> 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.

IMO, individuals ought to be able to turn off obsolete algorithms and
suffer whatever peril comes as a result (none in many cases).  Disabling
algorithms on a per-CA basis may be good enough without requiring users to
get involved.  

>
>In the meantime, all you can do is blacklist known-rogue certs.

Or whitelist certificates you require (which is more or less what you
suggest below).  

>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.

To make the discussion CT-compliant, having logs provide a list of
algorithms that are used by each CA would be a nice feature to enable
decisions like this.

---

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

Hi,

> algorithms that are used by each CA would be a nice feature to enable

Although, in the case you mention, that would not help all that much.
Fortunately, the days of MD5 in X.509 are over.

But in fact, I've been thinking for a while that an additional
monitoring infrastructure would be a nice-to-have thing in addition to
CT --- and, FWIW, also TACK --- I view both drafts as naturally
complementing each other.

CT, for example, is not meant to address the issue of whether
certificates have been deployed correctly (e.g. correct host). I think
active scans are still worthwhile to collect such information.

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: Carl Wallace <[email-masked]>
Date: Fri, 03 Jan 2014 12:45:32 -0500

>Fortunately, the days of MD5 in X.509 are over.

I imagine other algorithms will see a similar fate at some point.

>complementing each other.

Yes, better monitoring tools would be very helpful.

>active scans are still worthwhile to collect such information.

Identifying types of metrics that are useful to draw from a CT collections
seems like a worthwhile exercise.  Improved awareness of how a CA is used
sits under many suggestions, such as yours above to remove root CAs that
have used MD5.   

>_______________________________________________
>therightkey mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/therightkey

---

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

Hi,

> I imagine other algorithms will see a similar fate at some point.

Yes. SHA1 is next. There used to be some hesitation to switch to SHA1
due to, IIRC, concerns that older Windows versions wouldn't be able to
make the switch. With Microsoft themselves announcing EOL for SHA1, that
problem seems to be gone.

> Yes, better monitoring tools would be very helpful.

I also think that the possibilities of auditors and monitors are
woefully underspecified. Of course, the draft cannot add too many
distinct use cases.

For the monitors, I think it might be nice to have, say, a BCP-like text
that specifies how a CA or a larger company can monitor their domain
names occur only in the correct certificates. Some kind of
straight-forward set of instructions. Maybe extended with a few more
algorithms to check logged certs for other things -- compliance with BR
or EV comes to mind.

As for auditors, I am wondering if anyone is working on a FF or Chrome
add-on that tests consistency of a log. I appreciate it's not a prime
priority.

Ralph

---

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

> Yes. SHA1 is next. There used to be some hesitation to switch to SHA1

Apply s/1/2/ on the last word, please.

Ralph