<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Sorry in advance for brevity (deadlines fast approaching, no time!):<div><br><div><div>On Aug 22, 2014, at 6:27 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Fri, Aug 22, 2014 at 4:29 PM, Tao Effect <<a href="mailto:contact@taoeffect.com">contact@taoeffect.com</a>> wrote:<br><blockquote type="cite"><br>CT does not prevent Man-in-the-Middle (MITM) attacks. Given that the purpose<br>of CT is supposedly to protect from such attacks, this is embarrassing and<br>shameful.<br></blockquote><br>Can we tone the language down, and try keep discussions technical and objective?<br></blockquote></div><div><br></div><div>Certainly, that was something I'd written a while ago that I pasted into the email.</div><div><br></div><div>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.</div><div><br></div><div><blockquote type="cite">Greg's alternative would be to replace the HTTPS namespace with<br>Namecoin and replace DNS servers with Namecoin lookup servers.</blockquote><div><br></div>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.</div><div><br></div><div>Also, doesn't have to be Namecoin, it's just the most useful blockchain for doing this atm.</div><div><br></div><div><blockquote type="cite">CT changes the browser's certificate acceptance criteria from<br>"certificate from CA" to "certificate from CA plus signature from a<br>log promising to publish the certificate".<br></blockquote><div><br></div><div>That's a good summary.</div><div><br></div><blockquote type="cite">A bad-certificate attacker would have to compromise *both* a CA and a<br>log to issue an unpublished certificate. That raises the bar for<br>attack</blockquote><br></div><div>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).</div><div><br></div><div><blockquote type="cite"> particularly since there will be many fewer logs than CAs.</blockquote><br></div><div>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.</div><div><br></div><div><blockquote type="cite">Also, such an attack could be detected via post-facto lookup / gossip protocols.</blockquote></div><div><div><br></div><div>The attack would probably not be detected, because:</div><div><br></div><div>1. Detecting attacks post-facto would require all browsers to store all the certs they've ever seen. They're unlikely to do this.</div><div>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).</div><div><br></div><div>Post-facto also seems an unnecessarily low bar to aim for since the blockchain prevents such attacks altogether.</div><div><br></div><div><blockquote type="cite">For further discussion, I encourage Greg and others to discuss CT at<br>the IETF "trans" and "therightkey" Working Groups, which are chartered<br>to discuss CT, and key management in HTTPS more generally.<br></blockquote><br></div><div>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.</div><div><br></div><div>Sorry again for brevity!</div><div><br></div><div>Kind regards,</div><div>Greg</div><div>
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;">--</span><br style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;">Please do not email me anything that you are not comfortable also sharing</span><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;"> with the NSA.</span>
</div>
<br><div><blockquote type="cite"><br>CT is out of scope here, but people keep drawing analogies from it, so<br>I'll briefly explain in the hope we can focus back on end-to-end<br>messaging.<br><br>---<br><br>CT was designed around various constraints (performance, operational,<br>deployment) that exist in HTTPS. I've touched on some of that here:<br><br><a href="https://moderncrypto.org/mail-archive/messaging/2014/000636.html">https://moderncrypto.org/mail-archive/messaging/2014/000636.html</a><br>https://moderncrypto.org/mail-archive/messaging/2014/000653.html<br><br>Greg's alternative would be to replace the HTTPS namespace with<br>Namecoin and replace DNS servers with Namecoin lookup servers. That<br>would be extremely difficult due to the large installed base of HTTPS<br>and DNS servers, and expectations around existing URL names. CT<br>attempts to upgrade HTTPS security without requiring changes in<br>existing DNS and HTTPS servers and the existing web namespace.<br><br>CT changes the browser's certificate acceptance criteria from<br>"certificate from CA" to "certificate from CA plus signature from a<br>log promising to publish the certificate".<br><br>A bad-certificate attacker would have to compromise *both* a CA and a<br>log to issue an unpublished certificate. That raises the bar for<br>attack, particularly since there will be many fewer logs than CAs.<br>Also, such an attack could be detected via post-facto lookup / gossip<br>protocols.<br><br>These protocols are not yet defined, but that's an issue the IETF is working on.<br><br>For further discussion, I encourage Greg and others to discuss CT at<br>the IETF "trans" and "therightkey" Working Groups, which are chartered<br>to discuss CT, and key management in HTTPS more generally.<br><br><br>Trevor<br></blockquote></div><br></div></div></body></html>