<div dir="ltr">Kirk,<div><br></div><div>Thanks for your public reply to the ballot. While it appears that TrendMicro will not be convinced otherwise, I think some of the points you raise (and have raised for some time) deserve addressing on the public list, just as they've been repeatedly addressed on past calls and F2F.</div><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 30, 2015 at 10:35 AM, <a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a> <span dir="ltr"><<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>></span> wrote:<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 lang="EN-US" link="#0563C1" vlink="#954F72"><div>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
1. Revocation checking via OCSP is important for all certificates, including Short-Lived Certificates. While users who visit a site before a certificate is revoked will cache the “good” OCSP response and will not receive an OCSP update for up to 10 days under
BR 4.9.10, all other users who visit the site after revocation will be notified “revoked” by OCSP until the certificate expires – so potentially many users will be protected. This is essential for internet security, even for a 4-day certificate (many phishers
and fraudsters get their greatest use from a certificate during the first 48 hours after issuance). This same user protection will not occur with only CRLs for Short-Lived Certificates, as explained below.</p></div></div></blockquote><div><br></div><div>This, of course, presumes that the attacker will neither use</div><div>a) OCSP stapling as a means to disable clients OCSP behaviour</div><div>b) Network-level attacks to disrupt or replay past 'Good' OCSP responses.</div><div><br></div><div>In a realistic threat model (e.g. common browsers, common servers), both a) and b) are particularly relevant and applicable.</div><div><br></div><div>Since you raise Diginotar as an example for the necessity, it is worth pointing out that option b) could easily have been leveraged by the attackers, and almost certainly would be by any future attackers.</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 lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
2. The Forum has continuously been improving revocation checking over the past four years, moving from revocation checking via CRL to OCSP, and it would be a security mistake to go backwards now. Version 1 of the Baseline Requirements in 2011 covered OCSP
requirements for end-entity certificates. In later ballots the Forum required support of OCSP checking using the GET method for all end-entity certificates, required that CAs not provide a “good” response to unknown certificates, and also required CAs to
provide OCSP responses for the issuing sub-CA. CAs have spent a lot of money setting up robust OCSP responders to comply. All this was intended to improve user security, but Ballot 153 would move us back in time to less-secure CRLs, which is a bad idea.</p></div></div></blockquote><div><br></div><div>All of the above-mentioned improvements are equally valid (and arguably beneficial) for OCSP stapling, which is wholly independent.</div><div><br></div><div>These arguments are arguably against CRLs entirely - except that the Forum already permits CRLs to be used for subscriber certificates. I can understand if you don't want to see the 'furtherance' of CRL use, but it's useful to examine that in a 'threat model', this cow has already left the barn.</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 lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><u></u></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
4. Here is the most compelling argument against Ballot 153. CRLs are issued to cover all end-entity certificates that are issued and then later revoked by a single issuing sub-CA, and many CAs only use a single sub-CA to issue all certificates to all FQDNs
owned by all customers around the world. </p></div></div></blockquote><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 lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"> </p></div></div></blockquote><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 lang="EN-US" link="#0563C1" vlink="#954F72"><div>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
Under BR 4.9.7 the value of a nextUpdate field in a CRL is up to 10 days – so if a user visits *any* website secured by a certificate issued by a particular CA and downloads the related CRL, that user will not receive any updated revocation information for
*any other* website secured by a certificate from that same CA for a full 10 days.
<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
<u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
In other words, by visiting one secured FQDN and downloading that CA’s CRL for the issuing sub-CA, the user is effectively *blocked* from receiving *ANY* further revocation information from that CA for any other FQDN owned by any customer for 10 days – even
though the user is visiting other secured websites and FQDNs around the world. They will get no new revocation information.</p></div></div></blockquote><div><br></div><div>This is not factually/technically correct. CRLs can be segmented, and indeed, many CAs do.</div><div><br></div><div>If you're not familiar with this mechanism, RFC 5280, Section 5.2.5 can provide more details.<br></div><div><br></div><div>The failure of CAs to use this method has, among other things, contributed to why browsers prefer not to check CRLs.</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 lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal"><u></u></p>
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
Also, as we understand it, some browsers no longer do revocation checking by CRL, so even if the user downloads the current CRL for a Short-Lived Certificate and the CRL shows the certificate has been revoked, the browser will not report that to the user.</p></div></div></blockquote><div><br></div><div>Rather than attempt to dispel the incorrect assumptions here, I think it may be more useful to simply point to the empirical research side and hope you can see how it applies and disputes these claims:</div><div><br></div><div><a href="http://www.cs.umd.edu/~dml/papers/revocations_imc15.pdf">http://www.cs.umd.edu/~dml/papers/revocations_imc15.pdf</a><br></div><div><br></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 lang="EN-US" link="#0563C1" vlink="#954F72">
<p class="MsoNormal" style="margin-bottom:0.0001pt;line-height:normal">
5. So far as we can tell, the only reason for Ballot 153 is so CAs can stop providing OCSP revocation information for Short-Lived Certificates and thereby save money – there are no security advantages and no benefits to users. This is not a good reason to
degrade user security. Because of the problems with CRLs listed above, switching to CRLs effectively kills revocation checking for Short-Lived Certificates.</p></div></blockquote><div><br></div><div>This is, of course, not the only reason for Ballot 153, as has been repeatedly and extensively discussed, and as reflected in multiple meetings minutes. The numerous security advantages have been repeatedly explained to you and the Forum, including lengthy discussion about key compromise events.</div><div><br></div><div>While I can appreciate that you may disagree with these benefits, or that you may not appreciate the significance they represent to site operators, it's not correct to suggest there are no security advantages.</div><div><br></div><div>Further, the lengthy discussions of benefits to users, and the practical ways in which short lived certificates enable more sites to be protected by TLS, offering direct privacy and security benefits to users, are also seemingly being dismissed.</div><div><br></div><div>Rather than rehash this conversation in full, I think it's simply worthwhile to highlight that there's quite a bit of evidence counter to this claim.</div><div><br></div><div>If you would like to further understand the motivations for, and benefits from, Ballot 153, I would refer you to the minutes of our most recent F2F discussion - <a href="https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Short-Lived-Certificates">https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Short-Lived-Certificates</a></div><div><br></div></div></div></div></div>