<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 22, 2013 at 5:59 PM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank" class="cremed">Rick_Andrews@symantec.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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m not sure I’m following you, Ryan. Are you saying that short-lived certs don’t need an AIA pointer as long as the OCSP response is stapled?</span></p>
</div></div></blockquote><div><br></div><div style>No. I'm saying that an AIA pointer is meaningless (because it's ignored) in the presence of stapling.</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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> I buy that, but what happens when the stapled response has expired or can’t be cryptographically validated or doesn’t get returned at all? If the client hard-blocks, I buy that too. </span></p>
</div></div></blockquote><div><br></div><div style>This is orthogonal - but the OCSP must-staple use case explores the staple-or-hard-fail scenario. Ryan Hurst has discussed at length the "can't be cryptographically validated" case.</div>
<div style><br></div><div style>These are separate from short-lived certs, but I did want to make sure you were aware that conversations are going on.</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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">But I doubt browsers would do that, and I’d prefer that there was a fallback method. That’s why I’d like to see AIA extensions even in short lived certs.</span></p>
</div></div></blockquote><div style><br></div><div style>As stated before, the AIA is pointless if the attacker can return a cryptographically valid, un-expired response. Which they can, and since the whole point of stapling to begin with is to avoid the need to chase down the response, the AIA provides no added security value for the client.</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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">My logic was this: I see a 2-year cert that was issued one day ago; the CA must have thought it was valid or it wouldn’t have issued it; the CA very likely also issued an OCSP response that says the cert is good for the first 7 days; even without fetching the OCSP response I can conclude that even if I fetched one or got one via stapling, it would say that the cert was valid.</span></p>
</div></div></blockquote><div><br></div><div style>No, that's not a fair assumption. We're not proposing psychic browsers - we're just showing how, by very design of the protocol itself, it can be exploited by an attacker for a certain period of time - the same time period being proposed for short-lived certs.</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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> Since I already know the answer, I don’t have to ask the question.</span></p>
</div></div></blockquote><div><br></div><div style>That's not something that has been proposed by anyone on this list - that's why I objected.</div><div style><br></div><div style>We're not proposing not asking the question - but we have demonstrated that when you do ask the question, IF you got a valid answer within the validity period, then from a security perspective, there is no added security from repeatedly asking the question - because even if the answer changes, you can be repeatedly lied to.</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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Orthogonal idea: If CAs feel they want to experiment with short-lived certs and they must be signed under public roots, would it make sense to spin up new roots just for that, perhaps with a meta-data bit that browsers would use to expect that only such roots would sign short-lived certs?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Rick </span></p>
</div></div></blockquote><div><br></div><div style>If we accept the effective security is identical, then the only effect such a proposal would have would be to unnecessarily increase the barriers to entry.</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="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank" class="cremed">sleevi@google.com</a>] <br>
<b>Sent:</b> Friday, March 22, 2013 5:44 PM<br><b>To:</b> Rick Andrews<br><b>Cc:</b> <a href="mailto:ben@digicert.com" target="_blank" class="cremed">ben@digicert.com</a>; CABFPub</span></p><div class="im"><br><b>Subject:</b> Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal<u></u><u></u></div>
<p></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal" style="margin-bottom:12.0pt"><u></u> <u></u></p><div><p class="MsoNormal">On Fri, Mar 22, 2013 at 5:38 PM, Rick Andrews <<a href="mailto:Rick_Andrews@symantec.com" target="_blank" class="cremed">Rick_Andrews@symantec.com</a>> wrote:<u></u><u></u></p>
<div><div class="h5"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I’m very much in agreement with Eddy on this.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Consider this: If I take the basic argument that you don’t need to check revocation on a short lived cert (say, valid for 7 days) because the CA’s OCSP responses are also good for 7 days, then I would claim that when SSL clients (browsers) see a long-lived SSL certificate, they can skip revocation checking if the cert is less than 7 days old. I certainly wouldn’t want browsers to do that.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">-Rick</span><u></u><u></u></p>
</div></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">I'm not sure I follow your logic, Rick.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
If the browser has obtained a valid OCSP response (eg: via OCSP stapling), they can skip obtaining fresh revocation information - because to every compliant implementation, it IS fresh revocation information.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">If there's NO revocation information, I don't think the same argument applies.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p>
</div><div><p class="MsoNormal">The point of the discussion here is not about what the exact behaviour is - but what the effective security is. And in the case of short-lived certs, the effective security is identical.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">It's certainly reasonable to discuss whether the effective security is IDEAL, but that's a separate discussion than the one we're having - which is establishing whether or not the effective security of a short-lived cert is the same effective security as providing revocation information.<u></u><u></u></p>
</div></div></div></div></div></div></div></div></div></blockquote></div><br></div></div>