<div dir="ltr">Note that even if we accept Rob's hypothetical 'perfect' revocation system from the other thread, and we imagine a WebPKI ecosystem that universally deployed it - which is no small task to imagine in and of itself - we still have the issue that even revoked certificates will devolve into expired certificates, so whatever benefits are temporary. That is, revocation information is no longer published after a certificate has expired, and so eventually whatever is revoked will once again 'upgrade' to being expired.<div><br></div><div><div>Now, it might be that our 'perfect' revocation system has grown additional requirements (be an immutable ledger of all revoked certificates, efficient at scale while still being reliably and consistently delivered even under attack), but this is why there is considerable danger in engaging in such thought experiments - because we find that the set of requirements will continue to grow, and that perfect system will grow further out of reach. Meanwhile, we have the existing system (which behaves as described).</div><div><br></div><div>I'm sure there are some CAs that would argue this is proof as to why _no_ TLS error should be bypassable; the user should never be given any choice or say as to how the system operates, and the user agent, despite both the name and its priority of constituencies, should act to prevent the user from themselves by refusing to give them a choice. This is a line of thinking of some in the security community, and critics generally refer to it as 'security paternalism.' Despite whatever appeal it might have, and despite whatever innate appeal it might have at first blush, in general, such thinking is hostile to people tasked which actually using the machines. When faced with such an option, people handle the problem the same way the Internet does - treat it as damage and route around it.</div><div><br></div><div>The role of user agents is to serve as the user's agent, and through care and the research you see presented routinely at the CA/Browser Forum by those attempting to address these issues via scientific rigor, try to balance those competing needs of functioning as the user's agent while also avoiding the paradox of choice.</div><div><br></div><div>The point I highlight here is that such broad and sweeping statements as "Browsers shouldn't allow it to be bypassed", however appealing, ignore the behavioural science and ignore the basic technological specifications that we're discussing, and thus don't meaningfully provide a critique of the proposal.</div></div><div><br></div><div>Note that this ignores the very nature of whether revocation errors themselves _should_ be bypassable. For the argument presented here (specifically, phishing/"bad acting"), if you actually examine the systems that do scale to address these problems (Microsoft's SmartScreen or Google's SafeBrowsing database), and their consuming implementations, you'll find that the teams responsible for those have generally declined to make any error 'un-bypassable'. Certainly, there is no specification that it guarantees as such, and as mentioned above, there's little to no evidence to support it as the correct decision - in many cases, it was simply a historic precedent set without any firm support or backing. Thus, even if we imagine our perfect and reliable revocation system as above, and its universal deployment, it would very likely be accompanied by a change that would allow such errors to be bypassed, in order to accomodate the very real and very likely issue of "accidental" revocations.</div><div><br></div><div>As I know of some CA participants in the Forum responsible for "accidental" revocations that have cost millions of dollars in damages, and knowing how many CA participants have encountered some form of Baseline Requirements violation, it seems reasonable to conclude that in our imaginary world of perfect revocation, it would be critically necessary for user agents to offer the user a way to correct CA mistakes.</div><div><br></div><div>Unless, of course, our perfect world also imagines CAs as capable of not making mistakes. Which I think is unlikely, since to err is human...</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 7:34 PM, Eric Mill <span dir="ltr"><<a href="mailto:eric@konklone.com" target="_blank">eric@konklone.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="">> * No, not really.  Expired certificates let you click-through while revoked certificates are a hard fail, the way it should be (per Rob)<div><br></div></span><div>I don't think this (or Rob's original comment) are accurate as stated. </div><div><br></div><div>*If* revocation messages are presented, Firefox disallows clickthrough. But Firefox doesn't fail on an absence of revocation data (which is what "hard fail" means), and Chrome doesn't implement revocation for most situations at all. IIRC, I don't believe that Safari or IE/Edge hard fail on revocation errors either. </div><div><br></div><div>So during many kinds of attack, a revoked certificate <b>can</b> be silently used, without generating any warnings at all. If the certificate is added to OneCRL, crlset, or MS' disallowedcert list, that's a hard-fail, but that's obviously not "revocation" at scale.</div><div><br></div><div>On the other hand, expired certificates will reliably generate interstitials in all modern browsers. Some users may click through those warnings. However, site owners can use HSTS to disallow clickthrough of all warnings, including expired certificates. This is a major reason why the US government requires HSTS of public-facing federal web services (<a href="https://https.cio.gov" target="_blank">https://https.cio.gov</a>).</div><div><br></div><div>Even without HSTS present, expired certificates <b>can</b><b>not</b> be silently used in most attacks (a warning will be seen) -- and site owners have a way to easily opt in to HSTS to prevent users from clicking through those warnings.</div><div><br></div><div>So yes, I would classify expiration as a much more effective way of ending a certificate's utility than revocation, and I would not classify Firefox's disabling of clickthrough for revoked certificates as "hard fail".</div><div><br></div><div>-- Eric</div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Mon, Feb 6, 2017 at 5:25 PM, Doug Beattie via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">





<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_-1468572387562638581m_3149168173434735421m_7769052086426692430m_-9014250093704490588m_7490496162248078601WordSection1">
<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"><a name="m_-1468572387562638581_m_3149168173434735421_m_7769052086426692430_m_-9014250093704490588_m_7490496162248078601__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></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 #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Friday, February 3, 2017 6:01 PM<br>
<b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>><br>
<b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><span><br>
<b>Subject:</b> Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates<u></u><u></u></span></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">I'll try to simplify the replies, because it seems that giving a long list of reasons is causing too much confusion:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#1f497d">* I agree, but I think there were some meaningful responses to the concerns you raised.  This long email may be better served via a collaborative document or wiki, then follow up at the F2F.  I’ll see what I
 can do, because there are valuable points that were dropped in this response.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">* Did you know that Google’s CAA record is not correct? – Google is issuing SSL certificates to their domains but <a href="http://google.com" target="_blank">google.com</a> is not listed in the CAA record.  Am I misinterpreting CAA?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">  <a href="https://toolbox.googleapps.com/apps/dig/#ANY/google.com" target="_blank">https://toolbox.googleapps.c<wbr>om/apps/dig/#ANY/google.com</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">  </span><b><span style="font-size:10.0pt;font-family:"Courier New";color:#006600;background:white"><a href="http://google.com" target="_blank">google.com</a>. 86399 IN CAA 0 issue "<a href="http://symantec.com" target="_blank">symantec.com</a>"</span></b><span style="color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">* Current CPS says you’re not checking CAA – as the proponent of CAA shouldn’t you be checking it, else how can you criticize CAs for dragging their feet?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><a href="https://static.googleusercontent.com/media/pki.google.com/en//GIAG2-CPS-1.4.pdf" target="_blank">https://static.googleuserconte<wbr>nt.com/media/pki.google.com/en<wbr>//GIAG2-CPS-1.4.pdf</a><u></u><u></u></span></p>
<p class="MsoNormal"><span style="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>
<div><span>
<p class="MsoNormal">1) Do you acknowledge and agree that a shorter-lived certificate makes for a natural revocation?<u></u><u></u></p>
</span><p class="MsoNormal"><span style="color:#1f497d">* No, not really.  Expired certificates let you click-through while revoked certificates are a hard fail, the way it should be (per Rob)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">* Phishing sites that have a 3 month certificate and that are identified on day 1 as being bad have a full 89 days to continue phishing without certificate expiration, so, there is no help with shorter validity
 period certificates there<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">* Wouldn’t a WebPKI revocation system help more than shorter validity period certificates?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
</div><span>
<div>
<p class="MsoNormal">2) Do you acknowledge and agree that a shorter-lived certificate ensures that policies regarding new issuance can come in effect quicker than the current system?<u></u><u></u></p>
</div>
</span><div>
<p class="MsoNormal"><span style="color:#1f497d">* Yes, but at I apparently place less value on this than you do.  Based on issuance date you know what policy it was issued under.  As I’ve said repeatedly, short validity certificate would have had no benefit
 to SHA-1 deprecation because it was the relying party applications that needed to be updated.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">What real world benefit of recent changes would have we have realized if we had 1-year max validity period in the past 3 years?
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">CT: The set of log servers is just getting to the point of being robust and stable and we’re all moving that way. Some CAs are ahead of others.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">CAA – Google isn’t even doing CAA for their CAs yet, so how important can it really be?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">SHA-1 – as I’ve said before, not related to short validity certificates<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d">So, what changes have we made or what changed do we envision needing to be applied to all active certificates in order for them to be trusted?  I suggested in the last email making DV short validity – can we
 at least try to build agreement on that before we boil the ocean?  I might even OK with warning users that receive certificates that are valid longer than 18+- months that they may need to reissue them to be trusted by browsers before they expire, if that
 helps get us to agreement.  What do you think of baby steps and making at least some progress forward?<u></u><u></u></span></p>
<p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="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><span>
<div>
<p class="MsoNormal">Your attempts to ignore the SHA-1 issue are surprising. I would have thought the data that Microsoft shared regarding their efforts to deprecate this - due to the security risk to their users - while minimizing impact - would have unquestionably
 shown why this was necessary. To recap and refresh - the significant challenge reported was due to the long-lived nature of the certificates meaning that disabling SHA-1 - thus protecting the ecosystem - would and did cause considerable impact.<u></u><u></u></p>
</div>
</span><div>
<p class="MsoNormal"><span style="color:#1f497d">* The issue with SHA-1 deprecation came from the user base where applications and systems just didn’t support SHA-256 and not CAs. I keep saying this is a bad example of a policy change that would have benefited
 from shorter validity period certificates.  I hope we can agree on this and drop deprecation of SHA-1 as a reason for needing shorter validity certificates.
<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>
<div><span>
<p class="MsoNormal">The irony here of your objections to continuing the SHA-1 discussion is that, anticipating these problems, Google tried to help communicate to users and site operators the risk that CAs' repeated failures would cause, and the CA Security
 Council objected to this. So we have a situation where CAs are not actually trying to help the ecosystem (or their users) be more secure, we have ample evidence how the practice of long-lived certs prevents meaningful improvement, and CAs objecting to any
 and all efforts to improve the ecosystem to date that don't involve CRLs/OCSP, a set of unusable technologies in part due to CAs poisoning that well. That's not a healthy ecosystem.<u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
</span><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Let’s identify the problems that we want to solve and come up with solutions rather than forcing a solution on the industry and trying to justify it.  I don’t
 know about the other CAs, but GlobalSIgn is fine with short validity certificates as long as all of our customers are.  Changing the max validity period is trivial. What we keep missing here is that the consumers of SSL certificates need to be part of this
 discussion, in fact, they are THE key element and the solutions needs to align with their technical and business needs. 
<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
</div>
</div>

<br></div></div><span class="">______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/l<wbr>istinfo/public</a><br>
<br></span></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_-1468572387562638581m_3149168173434735421m_7769052086426692430m_-9014250093704490588gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</font></span></div></div>
</blockquote></div><br></div>