Sorry in advance for brevity (deadlines fast approaching, no time!): On Aug 22, 2014, at 6:27 PM, Trevor Perrin <[email protected]> wrote:
> On Fri, Aug 22, 2014 at 4:29 PM, Tao Effect <[email protected]> wrote: >> >> 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. > > Can we tone the language down, and try keep discussions technical and > objective? Certainly, that was something I'd written a while ago that I pasted into the email. I wholeheartedly agree about keeping the language as civil as possible. I apologize for any inflammatory remarks I've made (that I am unfortunately prone to making), both in these discussions and discussions prior. > Greg's alternative would be to replace the HTTPS namespace with > Namecoin and replace DNS servers with Namecoin lookup servers. Not quite as drastic... DNSChain is backwards compatible with today's system. I don't expect immediate radical change, but do expect (and hope for) a smooth transition. Also, doesn't have to be Namecoin, it's just the most useful blockchain for doing this atm. > CT changes the browser's certificate acceptance criteria from > "certificate from CA" to "certificate from CA plus signature from a > log promising to publish the certificate". That's a good summary. > A bad-certificate attacker would have to compromise *both* a CA and a > log to issue an unpublished certificate. That raises the bar for > attack Compromise can be simply in the form of a national security letter or there might not be a "compromise" at all (if a CA covertly belongs to NSA). > particularly since there will be many fewer logs than CAs. Google says in the FAQ there will be "one log for each major CA". They could run on the same machine/network as the rest of the CA mechanism. > Also, such an attack could be detected via post-facto lookup / gossip > protocols. The attack would probably not be detected, because: 1. Detecting attacks post-facto would require all browsers to store all the certs they've ever seen. They're unlikely to do this. 2. Gossip protocols do not exist currently, and should they exist are unlikely to be MITM-proof. Also, they would need to be MITM-proof and be used during the TLS session negotiation to prevent MITM attacks. That already seems like a non-starter for various reasons (for one, if they worked, there'd be no need for the rest of the system). Post-facto also seems an unnecessarily low bar to aim for since the blockchain prevents such attacks altogether. > For further discussion, I encourage Greg and others to discuss CT at > the IETF "trans" and "therightkey" Working Groups, which are chartered > to discuss CT, and key management in HTTPS more generally. Roger. At your request, this will be my last email about CT in this thread. Feel free to send replies off-list if you'd like. Sorry again for brevity! Kind regards, Greg -- Please do not email me anything that you are not comfortable also sharing with the NSA. > > CT is out of scope here, but people keep drawing analogies from it, so > I'll briefly explain in the hope we can focus back on end-to-end > messaging. > > --- > > CT was designed around various constraints (performance, operational, > deployment) that exist in HTTPS. I've touched on some of that here: > > https://moderncrypto.org/mail-archive/messaging/2014/000636.html > https://moderncrypto.org/mail-archive/messaging/2014/000653.html > > Greg's alternative would be to replace the HTTPS namespace with > Namecoin and replace DNS servers with Namecoin lookup servers. That > would be extremely difficult due to the large installed base of HTTPS > and DNS servers, and expectations around existing URL names. CT > attempts to upgrade HTTPS security without requiring changes in > existing DNS and HTTPS servers and the existing web namespace. > > CT changes the browser's certificate acceptance criteria from > "certificate from CA" to "certificate from CA plus signature from a > log promising to publish the certificate". > > A bad-certificate attacker would have to compromise *both* a CA and a > log to issue an unpublished certificate. That raises the bar for > attack, particularly since there will be many fewer logs than CAs. > Also, such an attack could be detected via post-facto lookup / gossip > protocols. > > These protocols are not yet defined, but that's an issue the IETF is working > on. > > For further discussion, I encourage Greg and others to discuss CT at > the IETF "trans" and "therightkey" Working Groups, which are chartered > to discuss CT, and key management in HTTPS more generally. > > > Trevor
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
