<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 17, 2013 at 6:41 PM, Wayne Thayer <span dir="ltr"><<a href="mailto:wthayer@godaddy.com" target="_blank">wthayer@godaddy.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>
<div>
<div>Ryan – thanks for the detailed response you’ve provided below.  You’ve presented a great case for why CT is important, and I agree with all of your points, yet they still leaves me with the sense that CT – even in the transformed state that Ben mentioned
 – won’t prevent a certificate from being mis-issued and used maliciously, at least for a while.  It might be a short while in the case of a bad certificate when the company has tight central control over cert approvals, an automated log monitoring/alerting
 system, and a clear understanding of how to respond to the incident.  It might be a very long while if any of these conditions isn’t met.  Is that what’s implied when Ben says that CT could be transformed into a “preventative” system, or am I still missing
 something?</div><span class=""><font color="#888888">
</font></span></div><span class=""><font color="#888888">
</font></span></div><span class=""><font color="#888888">
<div><br>
</div>
<div>Wayne</div></font></span></div></blockquote><div><br></div><div>I don't hope to speak for Ben, but my understanding of your question, and CT's design - whether in it's present form or in the transformed state that Ben has hinted at - DOES NOT prevent misissuance certificates.</div>
<div><br></div><div>It does, however, provide a global auditable log of all certificates, so that individual parties can examine for misissuance. Under today's system, there is no way for the affected site operators to know if a CA has mis-issued a certificate for their domain - whether through legal means ("compelled CA") or extra-legal means (CA compromise by hackers or state-level actors). CT closes that hole.</div>
<div><br></div><div>The distinction between the two forms of CT is effectively a distinction of how much trust is given to these global, auditable logs. The transformed, "preventative" measure that Ben mentioned is designed to prevent a log from misleading a relying party. The current system, as implemented within Chrome and defined in RFC 6962, leaves a small window for a CT log to mislead relying parties. However, this deception is ALSO auditable and contains a non-repudiatable proof, which allows for action to be taken </div>
<div>against CT logs that act dishonestly.</div><div><br></div><div>There have been, to this date, zero proposals for how to provide a guaranteed prevention of misissuance. CT accepts this as a nigh-impossible task - as there are already too many 'soft-knobs' in the Baseline Requirements and EV guidelines that can't be programatically checked - and instead seeks to provide a guaranteed detection mechanism for the public - both the site operators and parties interested in the SSL/TLS PKI ecosystem.<br>
</div><div><br></div><div>Does that clarify things?</div><div><br></div><div><br></div><div><br></div><div><br></div><div>For those who want the gory details, the current SignedCertificateTimestamp design is, in effect, a cryptographic promise by the CT log that it will log the given certificate and make those details available via the RFC 6962 API at a point in the future. A client can, at any point, check to see if the promise has been fulfilled. A client that checks these SCTs can enforce a Maximum Merge Delay (Section 3 / Section 5 of RFC 6962), which if the SCT is not integrated by the MMD, it knows the log has failed it's promise. A client does not necessarily need to check each SCT immediately after the MMD has expired - it could, for example, defer this to a later point as a general "the system is working well", and only alert for any SCTs that hadn't been integrated by the MMD.</div>
<div><br></div><div>A maliciously behaving log would issue SCTs, but then fail to incorporate them within the CT log, thus preventing the public (and auditors) from being aware of the fact that these certificates were issued. However, because every CT-validating client will expect to receive an SCT, they will have cryptographic proof of the logs dishonesty - and can then take action against the log, without necessarily taking action against the CA. Detecting log dishonesty is handled through Section 5 of RFC 6962.</div>
<div><br></div><div>One possible way that CT can be 'retooled' to be stricter - but which induces additional delays into the issuance pipeline - is to embed the proof of presence within the log, rather than the promise of presence within the log. However, this requires a delay from the time a CA submits a certificate to the log to when the log reaches it's eventually-consistent state and provides that proof of presence.</div>
<div><br></div><div>It offers a much stronger guarantee of the log's honesty to clients and auditors, but the increased issuance delay (effectively, the Maximum Merge Delay of the Log) was too much for some CAs to feel comfortable.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div><div class="h5">
<div><br>
</div>
<span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">Moving this to the public list, with Wayne and Rick's consent.<br>
<div><br>
<br>
<div class="gmail_quote">On Tue, Dec 17, 2013 at 10:41 AM, Wayne Thayer <span dir="ltr"><<a href="mailto:wthayer@godaddy.com" target="_blank">wthayer@godaddy.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>>Wayne, I think what Ben means is that CT can be tuned to be "preventative"<br>
><br>
if CAs would be willing to withhold a certificate from the customer until<br>
>monitors and auditors have had a chance to see it and agree that it was<br>
>properly issued.<br>
<br>
</div>
Yes, that's my understanding.  But what does it mean for a monitor to agree that a cert was properly - or more importantly to agree a cert was improperly - issued?  And what do they do about it?  For instance, if a small European CA issues a cert for '<a href="http://www.eu.bankofamerica.com/" target="_blank">www.eu.bankofamerica.com</a>',
 how does anyone other than B of A know if it's mis-issued?  How long will it take for them to figure it out?  And how long will it take to distrust/revoke the cert once all of this is established?<br>
</blockquote>
<div><br>
</div>
<div>I think it's important to compare with today's scheme, which is there is no means of detecting. CT works at present as a "detect-only" - it does not serve to revoke improperly issued certificates, nor does it seek to provide an additional check to prevent
 improper certificates from being issued.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div><br>
</div>
<div>Who can evaluate whether a certificate is bad:</div>
<div><br>
</div>
<div>To answer your question directly, on a formal level, only BoA - or anyone it has contracted with (ala MarkMonitor or any open monitor DBs that may rise) - can evaluate whether or not that certificate was authorized. Alternatively, if they published policy
 information (perhaps in machine readable form, like CAA or HPKP), it might be possible for monitors to flag it as potentially misissued. This is no different than the existing flows today - only the customer is capable of determining whether or not it's authorized.
 They can outsource this authorization check to competent third parties, but in the end, they're the only ones who know what they're doing or have done.</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>How long does it take for them to figure out out:</div>
<div><br>
</div>
<div>If the certificate is logged in CT, it takes up to the maximum merge delay of the log for it to be visible within the log, and then however long it takes monitors to query the log for updates and evaluate.</div>
<div>If the certificate is not logged in CT, then it behaves like our existing system for detection (ie: there is none).</div>
<div>Chrome's push to require CT for EV certificates, with the eventual goal of requiring for all certificates, acts as a forcing function to get a certificate logged. If a certificate is not logged, it's no different than any other self-signed or distrusted
 certificate, and the risk to users is the same. By having all certificates logged, we reduce the detection from "The time someone wonders about this weird thing they saw this one time" to something that can be programatically done (mod the issue I discuss
 below about log dishonesty)</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span><span>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div>
<div dir="ltr">
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>How long does it take to distrust/revoke the certificate:</div>
<div><br>
</div>
<div>CT does not change the revocation flow at all. Presumably this small European CA will update its CRLs and OCSP responders to revoke the certificate according to their CPS. In practice, I'm sure one of these small European CAs will have forgotten to configure
 a CRL or OCSP responder URL, or will have set it to be so laughably bad (eg: nextUpdate 3 years in the future) that it will require a more reactive response of user agents, such as MSFT's Certificate (Dis)trust List, Chrome's CRLSets, or Firefox's not-yet-implemented-but-similar-to-the-above-two
 methods (or through blacklisting + Firefox security update)</div>
<div><br>
</div>
<div>Still, under today's world, no one will ever notice or cause this certificate to be revoked, unless/until it happens to be picked up by some scan such as those by the EFF SSL Observatory or Netcraft and is suspicious enough for someone to blog post about
 it. (Mandatory) CT closes this detection gap.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><br>
>If CAs have pushed back on this, it's probably because customers would push<br>
>back on us. We've probably all had customers who need a certificate 10 minutes<br>
>ago because they missed their cert's expiration and they're running with an expired cert.<br>
><br>
>I have no idea what's a reasonable time period for monitors and auditors to satisfy<br>
>themselves that a newly-issued cert was intentional or mis-issued. Each customer<br>
>who cared would probably have to make some human available 24x7 to respond to<br>
>alerts from monitors.<br>
<br>
</div>
That fits my understanding, and is why I question how CT can be transformed to a "preventative" mode.<br>
</blockquote>
<div><br>
</div>
<div>In the current implementation of CT, there is ample opportunity for the log to be dishonest. While this can be eventually detected (through clients gossipping or sharing observed CT proofs), and alternative scheme for CT would embed much stronger certificate
 proofs into the certificate, so that any dishonesty can be (nearly immediately) detected. However, in order to get to that stronger guarantee against log dishonesty, it would require certificates be held from issuance until the log was in a consistent state.</div>

<div><br>
</div>
<div>The current form of CT is very much akin to the notion of public audits of CA's issuance practices. This may not seem like a 'strong' security guarantee, because CAs can still "cook the books", it at least increases the risk that any CA who does or is
 cooking the books will get detected.</div>
<div><br>
</div>
<div>Additionally, we have seen with the past several multi-vendor security incidents, CAs are still having trouble detecting their own misissuances and adhering to their stated CPSes. CT helps CAs makes this easier, by crowd-sourcing their audits. As long
 as there is nothing to hide, there's no risk, but significant public benefit.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
By the way, none of this changes my belief that CT is a useful detection mechanism.<br>
<div><br>
><br>
>-Rick<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:management-bounces@cabforum.org" target="_blank">management-bounces@cabforum.org</a> [mailto:<a href="mailto:management-" target="_blank">management-</a><br>
> <a href="mailto:bounces@cabforum.org" target="_blank">bounces@cabforum.org</a>] On Behalf Of Wayne Thayer<br>
> Sent: Tuesday, December 17, 2013 8:50 AM<br>
> To: Ben Laurie<br>
> Cc: <a href="mailto:management@cabforum.org" target="_blank">management@cabforum.org</a><br>
> Subject: Re: [cabfman] Improving the security of EV Certificates<br>
><br>
> Ben - with the following statement, you've touched on a part of CT<br>
> that I don't think I fully understand:<br>
><br>
> It is worth noting that CT has various tunable parameters which can<br>
> transform it from "detect after the fact" to "preventative", but CAs<br>
> have already objected to tuning in that direction. To be clear, to<br>
> turn CT into a fully preventative system, all that is needed is for<br>
> the certificate to not be valid until the log has sequenced it and<br>
> monitors have acknowledged they have seen it.<br>
><br>
> In my mind a perfect "preventative" solution would cause the<br>
> certificate to stop working prior to being relied on by anyone.  A<br>
> good "preventative" solution would work like pinning where a large<br>
> percentage of site visitors should be protected.  I understand that CT<br>
> could allow monitors to see a mis-issued cert prior to first use, but<br>
> I don't understand how that in turn prevents the cert from being<br>
> relied upon?  I assume that Google will be monitoring their domains,<br>
> but who will monitor (for instance) all the banking domains?  And once<br>
> a bad certificate is found, how is that cert disabled/revoked?  CRL Sets?<br>
> I'm trying to understand how long it will take to confirm that a<br>
> "typical" cert has been mis-issued and how long it will take to<br>
> disable it.  By "typical", I mean one where the legitimate domain<br>
> owner isn't actively monitoring a number of CT logs.<br>
><br>
> Thanks,<br>
><br>
> Wayne<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:management-bounces@cabforum.org" target="_blank">management-bounces@cabforum.org</a> [mailto:<a href="mailto:management-" target="_blank">management-</a><br>
> <a href="mailto:bounces@cabforum.org" target="_blank">bounces@cabforum.org</a>] On Behalf Of Ben Laurie<br>
> Sent: Tuesday, December 17, 2013 5:29 AM<br>
> To: Rick Andrews<br>
> Cc: <a href="mailto:management@cabforum.org" target="_blank">management@cabforum.org</a><br>
> Subject: Re: [cabfman] Improving the security of EV Certificates<br>
><br>
> It has been brought to my attention that I somehow neglected to<br>
> respond to this.<br>
><br>
> Apologies for the delay.<br>
><br>
> _______________________________________________<br>
> Management mailing list<br>
> <a href="mailto:Management@cabforum.org" target="_blank">Management@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/management" target="_blank">https://cabforum.org/mailman/listinfo/management</a><br>
_______________________________________________<br>
Management mailing list<br>
<a href="mailto:Management@cabforum.org" target="_blank">Management@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/management" target="_blank">https://cabforum.org/mailman/listinfo/management</a><br>
</div>
<div><br>
</div>
</blockquote>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Dec 17, 2013 at 10:41 AM, Wayne Thayer <span dir="ltr">
<<a href="mailto:wthayer@godaddy.com" target="_blank">wthayer@godaddy.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>>Wayne, I think what Ben means is that CT can be tuned to be "preventative"<br>
><br>
if CAs would be willing to withhold a certificate from the customer until<br>
>monitors and auditors have had a chance to see it and agree that it was<br>
>properly issued.<br>
<br>
</div>
Yes, that's my understanding.  But what does it mean for a monitor to agree that a cert was properly - or more importantly to agree a cert was improperly - issued?  And what do they do about it?  For instance, if a small European CA issues a cert for '<a href="http://www.eu.bankofamerica.com" target="_blank">www.eu.bankofamerica.com</a>',
 how does anyone other than B of A know if it's mis-issued?  How long will it take for them to figure it out?  And how long will it take to distrust/revoke the cert once all of this is established?<br>
<div><br>
>If CAs have pushed back on this, it's probably because customers would push<br>
>back on us. We've probably all had customers who need a certificate 10 minutes<br>
>ago because they missed their cert's expiration and they're running with an expired cert.<br>
><br>
>I have no idea what's a reasonable time period for monitors and auditors to satisfy<br>
>themselves that a newly-issued cert was intentional or mis-issued. Each customer<br>
>who cared would probably have to make some human available 24x7 to respond to<br>
>alerts from monitors.<br>
<br>
</div>
That fits my understanding, and is why I question how CT can be transformed to a "preventative" mode.<br>
<br>
By the way, none of this changes my belief that CT is a useful detection mechanism.<br>
<div>
<div><br>
><br>
>-Rick<br>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:management-bounces@cabforum.org" target="_blank">management-bounces@cabforum.org</a> [mailto:<a href="mailto:management-" target="_blank">management-</a><br>
> <a href="mailto:bounces@cabforum.org" target="_blank">bounces@cabforum.org</a>] On Behalf Of Wayne Thayer<br>
> Sent: Tuesday, December 17, 2013 8:50 AM<br>
> To: Ben Laurie<br>
> Cc: <a href="mailto:management@cabforum.org" target="_blank">management@cabforum.org</a><br>
> Subject: Re: [cabfman] Improving the security of EV Certificates<br>
><br>
> Ben - with the following statement, you've touched on a part of CT<br>
> that I don't think I fully understand:<br>
><br>
> It is worth noting that CT has various tunable parameters which can<br>
> transform it from "detect after the fact" to "preventative", but CAs<br>
> have already objected to tuning in that direction. To be clear, to<br>
> turn CT into a fully preventative system, all that is needed is for<br>
> the certificate to not be valid until the log has sequenced it and<br>
> monitors have acknowledged they have seen it.<br>
><br>
> In my mind a perfect "preventative" solution would cause the<br>
> certificate to stop working prior to being relied on by anyone.  A<br>
> good "preventative" solution would work like pinning where a large<br>
> percentage of site visitors should be protected.  I understand that CT<br>
> could allow monitors to see a mis-issued cert prior to first use, but<br>
> I don't understand how that in turn prevents the cert from being<br>
> relied upon?  I assume that Google will be monitoring their domains,<br>
> but who will monitor (for instance) all the banking domains?  And once<br>
> a bad certificate is found, how is that cert disabled/revoked?  CRL Sets?<br>
> I'm trying to understand how long it will take to confirm that a<br>
> "typical" cert has been mis-issued and how long it will take to<br>
> disable it.  By "typical", I mean one where the legitimate domain<br>
> owner isn't actively monitoring a number of CT logs.<br>
><br>
> Thanks,<br>
><br>
> Wayne<br>
><br>
> -----Original Message-----<br>
> From: <a href="mailto:management-bounces@cabforum.org" target="_blank">management-bounces@cabforum.org</a> [mailto:<a href="mailto:management-" target="_blank">management-</a><br>
> <a href="mailto:bounces@cabforum.org" target="_blank">bounces@cabforum.org</a>] On Behalf Of Ben Laurie<br>
> Sent: Tuesday, December 17, 2013 5:29 AM<br>
> To: Rick Andrews<br>
> Cc: <a href="mailto:management@cabforum.org" target="_blank">management@cabforum.org</a><br>
> Subject: Re: [cabfman] Improving the security of EV Certificates<br>
><br>
> It has been brought to my attention that I somehow neglected to<br>
> respond to this.<br>
><br>
> Apologies for the delay.<br>
><br>
> _______________________________________________<br>
> Management mailing list<br>
> <a href="mailto:Management@cabforum.org" target="_blank">Management@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/management" target="_blank">https://cabforum.org/mailman/listinfo/management</a><br>
_______________________________________________<br>
Management mailing list<br>
<a href="mailto:Management@cabforum.org" target="_blank">Management@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/management" target="_blank">https://cabforum.org/mailman/listinfo/management</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
</span>
</div></div></div>

</blockquote></div><br></div></div>