<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div>On Aug 22, 2014, at 5:23 PM, Chris Palmer <<a href="mailto:snackypants@gmail.com">snackypants@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thu, Aug 21, 2014 at 11:09 AM, Tao Effect <<a href="mailto:contact@taoeffect.com">contact@taoeffect.com</a>> wrote:<br><br><blockquote type="cite">- CT cannot to deliver on its promise to document every certificate that is<br>issued. It makes it possible for malicious actors to issue fraudulent certs<br>and never actually log or report them. [2] [3]<br>- Certs must be purchased via yearly subscriptions, whereas with Namecoin /<br>DNSChain they are free.<br>- CT does not prevent MITM attacks, whereas DNSChain does.<br>- Whereas certificate revocation for compromised certificates is not an<br>issue in Namecoin / DNSChain, it is still an unsolved problem with CT. [4]<br></blockquote><br><a href="http://www.certificate-transparency.org/how-ct-works">http://www.certificate-transparency.org/how-ct-works</a><br><br>"""During the TLS handshake, the TLS client receives the SSL<br>certificate and the certificate’s SCT. As usual, the TLS client<br>validates the certificate and its signature chain. In addition, the<br>TLS client validates the log’s signature on the SCT to verify that the<br>SCT was issued by a valid log and that the SCT was actually issued for<br>the certificate (and not some other certificate). If there are<br>discrepancies, the TLS client may reject the certificate. For example,<br>a TLS client would typically reject any certificate whose SCT<br>timestamp is in the future."""<br><br>Thus, clients can (and should) reject any certificate not issued in public.<br><br>Just wanted to clear that up.<br></blockquote></div><br><div>Please read again reference [2]: <a href="http://www.ietf.org/mail-archive/web/trans/current/msg00233.html">http://www.ietf.org/mail-archive/web/trans/current/msg00233.html</a></div><div><br></div><div>See point #2 in said link. Here, I will copy the relevant portion:</div><div><br></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><li>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.</li><ol><li>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.</li><li>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.</li></ol></div></blockquote><br></div><div><br></div><div>I think the problem is that Google left out some words in its explanation of "How CT Works":</div><div><br></div><div><div>> "During the TLS handshake, the TLS client receives the SSL certificate and the certificate’s SCT [from the NSA]"</div></div><div><br></div><div>;)</div><div><br></div><div>-Greg</div><div><br></div><div><div><span style="orphans: 2; widows: 2;">--</span><br style="orphans: 2; widows: 2;"><span style="orphans: 2; widows: 2;">Please do not email me anything that you are not comfortable also sharing</span><span style="orphans: 2; widows: 2;"> with the NSA.</span></div></div><div><span style="orphans: 2; widows: 2;"><br></span></div></body></html>