On May 9, 2014, at 6:50 PM, Nico Williams <[email protected]> wrote: > That's all I'll do for now. I don't have time to engage your position > at this time.
As you say, noted. > Surely others already have anyways. Actually not really, this email, and the randombit thread that I linked to (which didn't get a reply), has been about it. Part of the reason, I think, is because I haven't really spelled out in detail what the problems with CT are, just alluded to them, which may make it easy for folks to dismiss the comments as "he doesn't know what he's talking about." It's something I just need to find the time to do. > By "noted" I meant to say that yes, I took note of your position but I > don't want to discuss that topic in the context of "DNSSEC needs CT" > -- the two matters are separable. To discuss your response in the > same thread would just create noise. At any rate, I don't have time > to address it separately anyways. Feel free to educate us though. The fact that the folks on this list are supposed to be CT specialists makes it easier for me to write very brief critiques (without having to explain the details of how CT works). CT is X.509 on steroids, and I mean that in the most negative of ways possible. The crux is just this then: CT makes X.509 even more complicated than it already is. This inherently makes it less secure than even today's already totally insecure X.509 system (more moving parts). CT does not prevent Man-in-the-Middle (MITM) attacks. Given that the purpose of CT is supposedly to protect from such attacks, this is embarrassing and shameful. Expanding on 2: CT takes today's PKI and divides it up into "The Server" (the NSA), "The CA" (the NSA), and "The Log Server" (the NSA). This is how MITM works, it doesn't matter if the NSA doesn't actually own those servers because they effectively do by controlling the network itself. Clients have no way of detecting a MITM attack because the RFC gives them no such powers. If this complicated system were implemented perfectly, then most of the security rests not on the log servers, but on the "gossip protocols" that the RFC alludes to but does not describe. These protocols are supposed to be described in other documents, but as far as I'm aware they do not exist. Nor is any hint given as to their feasibility or to how the gossip channels themselves will be protected from MITM. CT centralizes security into the hands of a limited amount of CAs and Log Servers that must be trusted by everyone on the internet. It explicitly excludes support for self-signed certificates, ensuring lots and lots of $$$$ for those that run those servers, making todays pay-for-insecurity system even worse than it is. It effectively takes the security of the entire internet for ransom and puts it into the hands of government intelligence agencies and anyone else with MITM capabilities. CT does not actually care about preventing MITM attacks and places the burden of detecting such attacks squarely on the shoulders of domain owners and individuals. Attacks will happen successfully CT explicitly takes no steps to stop them as they happen. CT's very existence distracts the internet from real solutions that actually prevent MITM attacks, are far simpler, and provide security to everyone for ~$0. This alone makes it a significant threat to global security. Maybe I'll post a more detailed version of this later (with citations, illustrations, etc.). But seeing as this is a technical list, I hope it will do for now. Cheers, Greg Slepak -- Please do not email me anything that you are not comfortable also sharing with the NSA.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
