<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Robin Alden <span dir="ltr"><<a href="mailto:robin@comodo.com" target="_blank">robin@comodo.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 lang="EN-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">I think that the logic of his argument, like Adam Langley’s before him (</span><a href="https://www.imperialviolet.org/2011/03/18/revocation.html" target="_blank" style="font-family:Calibri,sans-serif;font-size:11pt">https://www.imperialviolet.org/2011/03/18/revocation.html</a><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">), is predicated on the belief that because boring old revocation[1] is not perfect it is therefore worthless and should be discarded.</span></p></div></blockquote><div><br></div><div>This is a terrible mischaracterization of my argument. I encourage people to read what I actually wrote, instead of relying on misleading summaries of it.</div><div><br></div><div>Robin, I will point out the flaw in your reasoning.</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-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Whilst the short lifetime of the certificate may mean that a user who has already encountered the certificate and its associated OCSP response before the revocation event will have a cached ‘Valid’ (i.e. unrevoked) OCSP response for that certificate, a user who has not previously encountered the certificate will pick up a fresh OCSP response and will discover the certificate’s revocation.</span></p></div></blockquote><div><br></div><div>No, this is not true. In order for the certificate to be useful for the attacker, the attacker must have the private key for the certificate and the attacker must be able to MitM the network connection.</div><div><br></div><div>Given those conditions, let's observe what happens when the user who has not previously encountered the certificate tries to connect to the site, in this case <a href="https://example.com">https://example.com</a>.</div><div><br></div><div><b>What happens when we use OCSP as the revocation mechanism?</b></div><div><br></div><div>0. Beforehand, the attacker periodically polls the CA's OCSP responder, getting the freshes OCSP response for the certificate that the CA provides. At some point, the CA's OCSP responder will respond with a REVOKED response. At that point, the attacker saves the newest GOOD response.</div><div><br></div><div>1. The user attempts to connect to <a href="https://example.com">https://example.com</a> by starting the TLS handshake with the server it thinks is <a href="http://example.com">example.com</a>.</div><div><br></div><div>2. The attacker intercepts the connection, and completes the TLS handshake, stapling the last GOOD response into the connection, using the (stolen) private key of the certificate he is using for the attack.</div><div><br></div><div>3. The user's browser sees the stapled GOOD OCSP response and accepts the certificate without attempting any other revocation checking.</div><div><br></div><div>According to the Baseline Requirements, this attack will work for 10 days (see section 4.9.10: "OCSP responses from this service MUST have a maximum expiration time of ten days.").</div><div><br></div><div><b>What happens when short lived certificates are used, without any CRL DP extension in the certificate?:</b></div><div><br></div><div><div>1. The user attempts to connect to <a href="https://example.com">https://example.com</a> by starting the TLS handshake with the server it thinks is <a href="http://example.com">example.com</a>.</div><div><br></div><div>2. The attacker intercepts the connection, and completes the TLS handshake, stapling the last GOOD response into the connection, using the (stolen) private key of the certificate he is using for the attack.</div><div><br></div><div>3. The user's browser sees that the certificate doesn't have any OCSP or CRL URL, and so accepts the certificate as not revoked.</div></div><div><br></div><div>The attack will work for 3 days, because the proposed short-lived certificates ballot says that the certificate must have a notAfter date no longer than 3 days after the issuance date.</div><div><br></div><div>Thus, by the CABForum's own standards, OCSP permits attacks to work for 7 days longer than if short-lived certificates were in use. Thus, short-lived certificates would be a more effective revocation mechanism.</div><div><br></div><div><b>What happens when we add the CRL DP extension to the short-lived certificate in Firefox, Chrome, and Opera (assuming Opera is the same as Chrome)?:</b></div><div><br></div><div><div><div>1. The user attempts to connect to <a href="https://example.com">https://example.com</a> by starting the TLS handshake with the server it thinks is <a href="http://example.com">example.com</a>.</div><div><br></div><div>2. The attacker intercepts the connection, and completes the TLS handshake, stapling the last GOOD response into the connection, using the (stolen) private key of the certificate he is using for the attack.</div><div><br></div><div>3. The user's browser sees that the certificate doesn't have any OCSP URL, and so accepts the certificate as not revoked.</div></div></div><div><br></div><div>This is exactly the same as if the CRL DP extension were not present.</div><div><br></div><div><b>How, what happens in a browser (maybe Microsoft's?) that actually supports the CRL DP extension?</b></div><div><br></div><div><div><div>1. The user attempts to connect to <a href="https://example.com">https://example.com</a> by starting the TLS handshake with the server it thinks is <a href="http://example.com">example.com</a>.</div><div><br></div><div>2. The attacker intercepts the connection, and completes the TLS handshake, stapling the last GOOD response into the connection, using the (stolen) private key of the certificate he is using for the attack.</div><div><br></div><div>3. The user's browser sees that the certificate doesn't have any OCSP URL, and so attempts to download the CRL.</div></div></div><div><br></div><div>4. The attacker blocks the CRL download.</div><div><br></div><div>5. The user's browser gives up trying to check the certificate for revocation, and accepts the certificate.</div><div><br></div><div><div>This is exactly the same as if the CRL DP extension were not present.</div></div><div><br></div><div><b>What happens in the case where a short-lived certificate is used, and the browser insists on having an OCSP response (Must-Staple or OCSP "hard fail" mode)?</b></div><div><b><br></b></div><div><div>0. Beforehand, the attacker periodically polls the CA's OCSP responder, getting the freshes OCSP response for the certificate that the CA provides. At some point, the CA's OCSP responder will respond with a REVOKED response. At that point, the attacker saves the newest GOOD response.</div><div><br></div><div>1. The user attempts to connect to <a href="https://example.com">https://example.com</a> by starting the TLS handshake with the server it thinks is <a href="http://example.com">example.com</a>.</div><div><br></div><div>2. The attacker intercepts the connection, and completes the TLS handshake, stapling the last GOOD response into the connection, using the (stolen) private key of the certificate he is using for the attack.</div><div><br></div><div>3. The user's browser sees the stapled GOOD OCSP response and accepts the certificate without attempting any other revocation checking.</div><div><br></div><div>According to the Baseline Requirements, this attack will work for 3 days, because the short-lived certificate must expire within 72 hours of the issuance date, according to the proposal. OCSP does not shorten the duration of the attack window because the baseline requirements allow the use of an OCSP response that is up to 10 days old (see section 4.9.10: "OCSP responses from this service MUST have a maximum expiration time of ten days.").</div></div><div><br></div><div><b>Conclusion</b><br></div><div><b><br></b></div><div>Requiring the CRL DP extension and/or the AIA extension with an OCSP responder URL to be present in the end-entity certificate does not have any significant advantage, but it does have a significant disadvantage in that it makes the certificates larger and thus less efficient to use in TLS. </div><div><br></div><div>More below.</div><div> <br></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-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">> There In fact, because the maximum validity period of a</span><br></p><span class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> short-lived certificate is shorter than the maximum lifetime <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> of an OCSP response, short-lived certificates are actually <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> a *safer* form of revocation than a stapled OCSP response.<u></u><u></u></span></p></span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">No, it isn’t.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Firstly, they are not alternatives.  We are not considering the alternatives of a short lived certificate (exclusive) OR an OCSP response. </span></p></div></blockquote><div><br></div><div>The main goal of short-lived certificates is for them to be an alternative to OCSP and CRLs. In any case, as you can see above, </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-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"> We are considering, given the premise of the ballot which is to have short lived certificates, whether there should also be an associated revocation status (OCSP or CRL).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">The short lifetime of the certificate, of course, limits the damage than can be done with it, but that damage can be limited further by its association with the existing revocation mechanisms.</span></p></div></blockquote><div><br></div><div>No. See the analysis above.</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-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><span class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">> Note that a CA isn't required to include the AIA OCSP</span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> responder URL in a certificate if the customer promises <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> to always staple an OCSP response. <u></u><u></u></span></p></span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">True, and although the BRs do permit what you describe that language in the BRs needs revising or removing.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">It should only be permitted with must-staple (rfc7633). The high-traffic case it considers should have additional security considerations if the revocation pointer is to be absent.</span></p></div></blockquote><div><br></div><div>No. See the analysis above.</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-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p><span class=""><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">> A short-lived certificate is a way of enforcing that the</span><br></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> customer keep that promise. <u></u><u></u></span></p></span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">No, it isn’t.  Using must-staple (rfc7633) is a way of enforcing that the customer keep that promise.</span></p></div></blockquote><div><br></div><div>Both are ways of enforcing the customer keep that promise. Short-lived certificates do a better job because a stale short-lived certificate cannot be used as long as a staled OCSP response. See the analaysis above.</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-GB" link="blue" vlink="purple"><span class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> Also note that it is critically important that certificate <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> chains get smaller due to the nature of the TCP and TLS <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> protocols, especially when combined with CT, which makes <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> them significantly larger. <u></u><u></u></span></p></span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">CT in certificate bodies is not the only fruit.  CT does not require certificate bloat – although presumably getting the SCT in a TLS extension doesn’t reduce the bytes over the wire any.</span></p></div></blockquote><div><br></div><div>Right. One way or another, the server has to send the CT info in the TLS extension, which means that CT, no matter how the info is delivered, puts additional pressure on us to keep certificate chains small.</div><div><br></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-GB" link="blue" vlink="purple"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">But I smell the old point about initcwnd.  What % of deployed servers can't (and/or don't?) set the initcwnd?</span></p></div></blockquote><div><br></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6667px">Increasing the initcwnd works often, for servers that do it. There are a lot of scenerios where it doesn't work even in an all-TCP scenerio. In the case of Internet of Things applications, TCP (initcwnd) isn't the only limiting factor.</span><br></div><div><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:14.6667px"><br></span></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-GB" link="blue" vlink="purple"><span class=""><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> One of the main purposes of OCSP <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> stapling is to help make the certificate-related parts of <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> the TLS handshake more efficient in this respect, and the <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> requirement for adding the CRL DP extension, which is <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> relatively large, is counterproductive to this primary <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> purpose. <u></u><u></u></span></p></span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Really?  I thought the main purposes of OCSP stapling <snip></span></p></div></blockquote><div> </div><div>Sorry, I meant "one of the main purposes of short-lived certificates", not OCSP stapling.</div><div><br></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-GB" link="blue" vlink="purple"><span class=""><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">> If people want this in order to support CRLSets/OneCRL/etc.</span><br></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> then it would be better to find an efficient out-of-band <u></u><u></u></span></p></span><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> method for advertising the CRL URLs to support those out-<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> of-band revocation methods.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Finally we’re starting to reach something we might agree on.  When there’s a better way to get revocation status information out there then let’s use it, but let’s not throw the existing mechanisms away until there is a superior replacement for them.</span></p></div></blockquote><div><br></div><div>This ballot proposes exactly that: short-lived certificates.</div><div><br></div><div>Cheers,</div><div>Brian</div></div>
</div></div>