Re: [therightkey] algorithm blacklisting
> Yes. SHA1 is next. There used to be some hesitation to switch to SHA1 Apply s/1/2/ on the last word, please. 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 ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] algorithm blacklisting
Hi, >> Although, in the case you mention, that would not help all that much. >> Fortunately, the days of MD5 in X.509 are over. > > 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. >> 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. > > 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 -- 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 ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] algorithm blacklisting
Leif Johansson: > On 2014-01-02 23:50, Paul Hoffman wrote: >> On Jan 2, 2014, at 10:57 AM, Jacob Appelbaum >> 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. >> > > 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. 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 ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] algorithm blacklisting
On 1/3/14, 12:37 PM, "Ralph Holz" wrote: >Hi, > >>> 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. > >Although, in the case you mention, that would not help all that much. >Fortunately, the days of MD5 in X.509 are over. I imagine other algorithms will see a similar fate at some point. > >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. Yes, better monitoring tools would be very helpful. > >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. 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. > >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 >___ >therightkey mailing list >therightkey@ietf.org >https://www.ietf.org/mailman/listinfo/therightkey ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] algorithm blacklisting
Hi, >> 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. 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 ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
Re: [therightkey] algorithm blacklisting
On 1/3/14, 12:19 PM, "Ralph Holz" 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. ___ therightkey mailing list therightkey@ietf.org https://www.ietf.org/mailman/listinfo/therightkey
