<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-7"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Dear Paul,<div><br></div><div><blockquote type="cite">By calling it "Google CT", it purposefully ignores the fact that this<br>is an IETF standard: RFC 6962.</blockquote></div><div><br></div><div>I called it "Google's CT" as a convenience to the reader in order to distinguish it from other implementations of certificate transparency, namely blockchain certificate transparency.</div><div><br></div><div>I did not "purposefully ignore" that it's being developed as part of an IETF working group.</div><div><br></div><div>My understanding is that this was originally conceived of, and funded by, Google, so I called it "Google's CT". If I'm mistaken about that, please let me know.</div><div><br></div><div>Also, if you know of a more accurate way of distinguishing between the different types of certificate transparency I would be happy to update the article. As the article is for a semi-lay audience, it would be appreciated if you could keep the terminology simple and accurate.</div><div><br></div><div>"IETF CT", for example, has too many acronyms and could conflict with potential future IETF working groups (if such groups decide to create other implementations of CT).</div><div><br></div><div><blockquote type="cite">Second, the 6962bis work explicitly includes a gossip protocol to<br>address this. Some even envision all browsers to be gossipers (although<br>some fear that leaks too much brower history). Regardless, there will<br>be very many logs/auditors/gossipers. So this is pretty much a red<br>herring. A first draft was presented last Monday at IETF 92 in Dallas:<br><br><a href="http://tools.ietf.org/html/draft-linus-trans-gossip-ct-01">http://tools.ietf.org/html/draft-linus-trans-gossip-ct-01</a></blockquote></div><div><br></div><div>When we discussed the idea of sharing SCTs between browsers and servers on the [trans] list back in September of 2014 [1], I thought that the idea had been dismissed. I did not know it was later picked up by the group. My apologies for having missed the publication of this document earlier in the month.</div><div><br></div><div>[1] <a href="https://www.ietf.org/mail-archive/web/trans/current/msg00600.html">https://www.ietf.org/mail-archive/web/trans/current/msg00600.html</a></div><div><br></div><div>Reading over it, I still have several concerns, which I will voice here but let me know if it would be better to also voice them on [trans].</div><div><br></div><div>In Section 3.1.1, it says:</div><div><br></div><div><begin></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><pre class="newpage">HTTPS servers MUST perform a number of sanity checks on SCTs from
clients before storing them:
1. if a bit-wise compare of the SCT matches one already in the
store, discard<span style="background-color: rgb(255, 255, 153); border: thin solid rgb(255, 204, 102);" pfid="20131123212204" dbtype="local" id="bits_marker_local20150326130027">
2. if the SCT can't be verified to be a valid SCT for the
accompanying leaf cert, issued by a known log, discard</span>
3. if the leaf cert is not for a domain that the server is
authoritative for, discard
Check number 1 is a pure optimisation. Check number 2 is to prevent
spamming and attacks where an adversary can fill up the store prior
to attacking a client. Check number 3 is to help misbehaving clients
from leaking what sites they visit.</pre></div></blockquote></div><div></end></div><div><br></div><div><div>Concern #1: Discarding invalid SCTs</div><div>============================</div></div><div><br></div><div>It is not clear to me what's going on in (2) above.</div><div><br></div><div>Specifically:</div><div><br></div><div>- How is the server verifying the SCT for validity?</div><div><br></div><div>- Why is the server discarding the SCT if it is invalid?</div><div><br></div><div>Wouldn't discarding an invalid SCT totally undermine the point of clients sharing them?</div><div><br></div><div>Concern #2: The use of the word SHOULD</div><div>=================================</div><div><br></div><div>The doc states:</div><div><br></div><div>(with ref to server => auditor comms):</div><div><begin></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><pre class="newpage"><span style="background-color: rgb(255, 255, 153); border: thin solid rgb(255, 204, 102);" pfid="20131123212204" dbtype="local" id="bits_marker_local20150326130603">HTTPS servers SHOULD share all SCTs and certificate data they see
that pass the checks above</span></pre></div></blockquote></end></div><div><br></div><div><begin></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><pre class="newpage">Auditors <span style="background-color: rgb(255, 255, 153); border: thin solid rgb(255, 204, 102);" pfid="20131123212204" dbtype="local" id="bits_marker_local20150326131306">SHOULD</span> provide the following URL accepting HTTPS POSTing of
SCT feedback data:</pre></div></blockquote></end></div><div><br></div><div><begin></div><div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><pre class="newpage">Auditors <span style="background-color: rgb(255, 255, 153); border: thin solid rgb(255, 204, 102);" pfid="20131123212204" dbtype="local" id="bits_marker_local20150326131311">SHOULD</span> regularly <span style="background-color: rgb(255, 255, 153); border: thin solid rgb(255, 204, 102);" pfid="20131123212204" dbtype="local" id="bits_marker_local20150326131335">poll</span> HTTPS servers at the well-known sct-
feedback URL. <span style="background-color: rgb(255, 255, 153); border: thin solid rgb(255, 204, 102);" pfid="20131123212204" dbtype="local" id="bits_marker_local20150326131331">How to determine which domains to poll is outside the
scope of this document</span></pre><div><br></div></div></blockquote></end></div><div><br></div><div><br></div><div>As per RFC2119, "SHOULD" means the advice is free to be ignored after the implications are "carefully weighed".</div><div><br></div><div>This means that so far the document provides no guarantees that a misbehaving log will be caught.</div><div><br></div><div>It is also disconcerting that instead of taking direct action themselves, servers are supposed to initiate yet another HTTPS connection to an auditor. This is cumbersome and will probably leave open holes for a global MITM to prevent SCTs from reaching auditors, yet again undermining the entire point of sharing SCTs.</div><div><br></div><div>While it's definitely a positive sign that the sharing of SCTs and certificate chains is now an official recommendation, I am concerned that the particular implementation is without any teeth to deliver concrete results, and so until these concerns are addressed I am not convinced that the problem has been fully addressed.</div><div><br></div><div><blockquote type="cite"><span class="Apple-tab-span" style="white-space: pre;"> </span>Domain owners either have to put their trust in the CA they˘ve<br><span class="Apple-tab-span" style="white-space: pre;"> </span>to correctly monitor all logs 24/7 for fraudulent issuance, or<br><span class="Apple-tab-span" style="white-space: pre;"> </span>have to monitor all logs themselves (something they are extremely<br><span class="Apple-tab-span" style="white-space: pre;"> </span>to do).<br><br>This is also incorrect. See page 6 of the presentation that Daniel Kahn<br>Gillmor gave at trans:<br><br><a href="http://www.ietf.org/proceedings/92/slides/slides-92-trans-3.pdf">http://www.ietf.org/proceedings/92/slides/slides-92-trans-3.pdf</a><br><br>You can see that web clients, when detecting a new SCT or Certificate<br>will exchange this with the website.</blockquote><br></div><div>Yes, as per the new Experimental Internet-Draft discussed above, I see that this has changed since I last looked.</div><div><br></div><div>I will therefore update this part of the blog post (hopefully later today after I get back from a doctor's appointment which I've gotta run to).</div><div><br></div><div>Thanks you for pointing that out and for addressing this concern. I want to make sure that everything we say about CT is accurate and up-to-date.</div><div><br></div><div><blockquote type="cite">I did not read the blog post further as for why their solution is<br>better, mostly because I personally (no hats) do not believe in<br>protocols depending on bulk CPU power and heating up the world.</blockquote><br></div><div>There's more than one way to skin a blockchain*, so you may want to read about other consensus mechanisms (like bonded proof of stake) that do not require spending significant CPU power.</div><div><br></div><div>Alternatively, you may also want to support green power initiatives.</div><div><br></div><div>Kind regards,</div><div>Greg Slepak</div><div><br></div><div>* As a vegan, I am against the practice of skinning anything. That expression is meant to be interpreted as a convenient figure of speech. ;)</div><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><div>On Mar 25, 2015, at 7:51 PM, Paul Wouters <<a href="mailto:paul@cypherpunks.ca">paul@cypherpunks.ca</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Wed, 25 Mar 2015, Greg wrote:<br><br><blockquote type="cite">Wherein Google's CT is compared with blockchains against the goals that Google set for CT.<br>Also, a mechanism for keeping DNSChain servers honest is presented at the end.<br><a href="https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/">https://blog.okturtles.com/2015/03/certificate-transparency-on-blockchains/</a><br></blockquote><br>Note: I am the IETF co-chair of the trans working group responsible for CT. You can read<br>up on the drafts at: <a href="https://datatracker.ietf.org/wg/trans/documents/">https://datatracker.ietf.org/wg/trans/documents/</a><br><br>By calling it "Google CT", it purposefully ignores the fact that this<br>is an IETF standard: RFC 6962.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>CA/log combos can use hidden Merkle trees to hide certificate<br><span class="Apple-tab-span" style="white-space:pre"> </span>issuance, even in a world where CT is mandatory for all CAs. The CT spec<br><span class="Apple-tab-span" style="white-space:pre"> </span>allows only one SCT to accompany a certificate, making this attack<br><span class="Apple-tab-span" style="white-space:pre"> </span>feasible. If clients require SCTs from more than one log, the likelihood<br><span class="Apple-tab-span" style="white-space:pre"> </span>of this attack can be reduced.<br><br>Second, the 6962bis work explicitly includes a gossip protocol to<br>address this. Some even envision all browsers to be gossipers (although<br>some fear that leaks too much brower history). Regardless, there will<br>be very many logs/auditors/gossipers. So this is pretty much a red<br>herring. A first draft was presented last Monday at IETF 92 in Dallas:<br><br><a href="http://tools.ietf.org/html/draft-linus-trans-gossip-ct-01">http://tools.ietf.org/html/draft-linus-trans-gossip-ct-01</a><br><br><span class="Apple-tab-span" style="white-space:pre"> </span>Domain owners either have to put their trust in the CA they˘ve<br><span class="Apple-tab-span" style="white-space:pre"> </span>to correctly monitor all logs 24/7 for fraudulent issuance, or<br><span class="Apple-tab-span" style="white-space:pre"> </span>have to monitor all logs themselves (something they are extremely<br><span class="Apple-tab-span" style="white-space:pre"> </span>to do).<br><br>This is also incorrect. See page 6 of the presentation that Daniel Kahn<br>Gillmor gave at trans:<br><br>http://www.ietf.org/proceedings/92/slides/slides-92-trans-3.pdf<br><br>You can see that web clients, when detecting a new SCT or Certificate<br>will exchange this with the website. This means that the domain owner<br>receives reports automatically of all rogue certficates once the<br>web client is no longer under attack and connects to the legitimate<br>site.<br><br><br>I did not read the blog post further as for why their solution is<br>better, mostly because I personally (no hats) do not believe in<br>protocols depending on bulk CPU power and heating up the world.<br><br>Paul<br>_______________________________________________<br>The cryptography mailing list<br>cryptography@metzdowd.com<br>http://www.metzdowd.com/mailman/listinfo/cryptography</blockquote></div><br></div></body></html>