<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">They note that the Short-Lived Certificates have a validity period of 4 days,</p></div></div></blockquote><div><br></div><div>3 days from issuance. notAfter - notBefore may be 4 days so that a CA can back-date the certificate by up to one day, to account for clock skew.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal"> and that OCSP responses must be updated at least every 4 days under BR </p></div></div></blockquote><div><br></div><div>This detail is not relevant to the security analysis. Even if the CA produces a new REVOKED response before the last GOOD response expires, the attacker can just staple the last GOOD response.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">4.9.10 (but are good for up to 10 days).</p></div></div></blockquote><div><br></div><div>Right. This 10 day validity period for OCSP responses is the thing that matters.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">Because a Short-Lived Certificate will expire in the same time as
 the maximum update period for OCSP responses, then then make the logical leap that SLCs with no OCSP pointers are “just as good” as SLCs with OCSP pointers because [somehow] the SLCs with no OCSP revocation information will all expire
<u>before</u> some users will ever learn they were revoked.<br></p></div></div></blockquote><div><br></div><div>It isn't a "logical leap". If somebody is actually MitMing a user and know the certificate's private key, then they can successfully staple the last GOOD OCSP response until that OCSP response expires. If there is no MitM attacker or the MitM doesn't know the certificate's private key then it doesn't matter whether the certificate is revoked or not because the user and server aren't being attacked.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal"></p><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal"><u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">It’s true that visitors to websites secured by a SLC who receive a “good” OCSP response, and who then return to the website before its revoked SLC expires, probably will not any receive updated revocation information because the first OCSP response is cached. 
 But that’s the *only* case where the two SLCs (one with an OCSP pointer, and one with no OCSP pointer) are roughly the same from a user security standpoint.  And that’s probably a very small minority of users who visit a site secured by an SLC over its 4 day
 validity period.  The other users who visit the site after revocation over the same period would all benefit from OCSP revocation information.</p></div></div></blockquote><div><br></div><div>That is only the case in the situation where there is no MitM attacker. But, again, when there is no MitM attacker, it doesn't matter whether the browser notices that the certificate has been revoked or not, as far as the security of the user/site is concerned. I believe the rest of your email is also only considering the case where there is no MitM attacker.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">It’s true that some OCSP queries are blocked or users receive no response – but that doesn’t mean it’s not work checking for revocation of a certificate via OCSP.  Suppose as many as 10% of OCSP queries don’t receive a response – that’s still 90% that do, which
 would protect 81,000 of the 90,000 users in the example above.  Without any revocation checking at all, those users are sitting ducks.</p></div></div></blockquote><div><br></div><div>I think this is overlooking the fact that the attacker can always staple the last GOOD OCSP response, in order to prevent the browser from ever trying to fetch the OCSP response at all.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal"><u></u></p>
<p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">To address this problem, the proponents of Ballot 153 have suggested that including a CDP pointing to a CRL is just as good as an AIA OCSP pointer for revocation checking.</p></div></div></blockquote><div><br></div><div>To be clear, I also disagree with the people that think it is useful/good to include a CDP in short-lived certificates.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">So if a user visits Site A on Monday and downloads and caches the current CRL, that stale CRL will effectively block the user from ever receiving any additional revocation information about *any* other certificate, including SLCs, issued by the same CA for
 the next 10 days.  Again, bad user security.<br></p></div></div></blockquote><div><br></div><div>This, and many other reasons, are why CRLs are a poor choice in general.</div><div><br></div><div>Plus, browsers aren't required to download CRLs even when there is no way for it to do OCSP, and many users' browsers don't do CRLs (or even OCSP) at all.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">Let’s not go backward on the revocation security improvements the Forum has made over the past four years.</p></div></div></blockquote><div><br></div><div>I understand that it seems counter-intuitive that a short-lived certificate without an AIA OCSP pointer or a CRL DP extension could be more secure than a normal (not short-lived) certificate with an AIA OCSP pointer or a CRL DP extension. However, please read the analysis I provided in the other thread, where I showed that the counter-intuitive result is correct.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">In fact, we should start ratcheting down on the maximum validity period for current OCSP responses, from 4 days to maybe 2 days, for greater user security.</p></div></div></blockquote><div><br></div><div> Again, the problem with OCSP isn't the "must update every 4 days" requirement for OCSP. The problem with OCSP is that OCSP responses are allowed to be valid for up to 10 days. I agree with your sentiment that OCSP should be improved. I've often advocated reducing the maximum validity period of OCSP responses to be the same as what is being proposed for short-lived certificates (notBefore >= 1 day before issuance, notAfter <= 3 days after issuance).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div><p class="MsoNormal" style="margin-bottom:0in;margin-bottom:.0001pt;line-height:normal">We can help solve the OCSP response infrastructure problems of both browsers and CAs by aggressively promoting stapling and working with server makers to turn on stapling by default – that’s the right way to proceed.<br></p></div></div></blockquote><div><br></div><div>Besides doing those things, there are two other things that would be required:</div><div><br></div><div>1. Servers and clients must implement Must-Staple.</div><div>2. As noted above, the maximum validity period of OCSP responses must be reduced to the same as the proposed maximum validity period of short-lived certificates.</div><div><br></div><div>Then OCSP would work pretty good. However, there still would be a strong demand for short-lived certificates without OCSP or CRL checking, because short-lived certificates are a significantly more efficient encoding of the same information as a certificate + stapled OCSP response + Must-Staple extension or CRL DP extension or AIA OCSP pointer.</div><div><br></div><div>Cheers,</div><div>Brian</div></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a></div><div><br></div></div></div></div></div></div></div>
</div></div>