<div dir="ltr">I doubt the substance of the conversation will change much here - it's an emergent fact that our organizations have differing expectations of security, and how much or how little cost we externalize to our users to achieve that definition.<div><br></div><div>I can appreciate that CAs are both much more relaxed in their definition - by virtue of the fact that their goals are not aligned with browsers' goals, in ways both positive and negative for the ecosystem - and that CAs are not concerned about those costs, because they are costs they do not directly bear. So it's very easy to have opinions - that browsers should relax their expectations of user security, or to accept these costs as acceptable - but it's rather difficult to actually make that case a compelling argument, and as such, we're unlikely to make progress.</div><div><br></div><div>I'm not sure a police officer, if she pulled me over, would find much solace in my argument that I wasn't wearing a seatbelt, because I only planned to crash gently. So too should we be suspicious of arguments that fail to protect users from attack.</div><div><br></div><div>However, I also suspect that this disagreement relates to our fundamental disagreement about what is a 'valid' attack - and what are 'attacks' for which CAs are concerned about, but which browsers and site operators are not.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 10, 2017 at 6:06 PM, Ben Wilson via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">+1  (Sometimes it depends on the type of crash you're involved in.)<br>
<span class="im HOEnZb"><br>
-----Original Message-----<br>
From: Public [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@<wbr>cabforum.org</a>] On Behalf Of Robin Alden<br>
via Public<br>
</span><div class="HOEnZb"><div class="h5">Sent: Friday, March 10, 2017 3:44 PM<br>
To: 'CA/Browser Forum Public Discussion List' <<a href="mailto:public@cabforum.org">public@cabforum.org</a>>; 'Kirk<br>
Hall' <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a><wbr>>; 'Phillip Hallam-Baker'<br>
<<a href="mailto:philliph@comodo.com">philliph@comodo.com</a>><br>
Cc: Robin Alden <<a href="mailto:robin@comodo.com">robin@comodo.com</a>><br>
Subject: Re: [cabfpub] Certificate lifetimes: end state or trajectory?<br>
<br>
Adam is cleverer than a whole box-full of the rest of us, but he isn't<br>
infallible and you cannot quote his blog as incontrovertible fact.<br>
<br>
It is not true that it only works when you don't need it.<br>
It is true that it doesn't always work when you need it, but that is not the<br>
same thing by any manner of means.<br>
<br>
> This is because "[A]n attacker who can intercept HTTPS connections [so<br>
> as to use their bad cert for an MITM] can also make online revocation<br>
> checks appear to fail and so bypass the revocation checks."<br>
Maybe.  Maybe not.<br>
It depends where the attacker is situated.<br>
If you're in the same coffee shop as him, you're toast.<br>
If the attacker is sitting in the data center that hosts the site with the<br>
cert, then the attacker can't touch the path between the client and the CA,<br>
so you've overstated the case.<br>
<br>
The perfect can be the enemy of the good.<br>
<br>
Regards<br>
Robin Alden<br>
Comodo<br>
<br>
<br>
> -----Original Message-----<br>
> From: Public [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@<wbr>cabforum.org</a>] On Behalf Of Gervase<br>
> Markham via Public<br>
> Sent: 10 March 2017 12:37<br>
> To: Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a><wbr>>; CA/Browser Forum Public<br>
> Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>>; Phillip Hallam-Baker<br>
> <<a href="mailto:philliph@comodo.com">philliph@comodo.com</a>><br>
> Cc: Gervase Markham <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>><br>
> Subject: Re: [cabfpub] Certificate lifetimes: end state or trajectory?<br>
><br>
> On 03/03/17 20:34, Kirk Hall wrote:<br>
> > Gerv - on the issue of revocation checking, not everyone is asking<br>
> > for browsers to turn on hard fail if the browser fails to get a<br>
> > response to a revocation query in a reasonable time..  We would be<br>
> > very happy to continue with soft fail - but please, turn on<br>
> > revocation checking again.  Even if the browser doesn't get a timely<br>
> > response in (say) 10% of queries, if it does receive a response<br>
> > "revoked" in the other 90% of queries, and displays that to users,<br>
> > that would be a great increase in user security.<br>
><br>
> As noted by Adam Langley, "[S]oft-fail revocation checks are like a<br>
> seat-belt that snaps when you crash. Even though it works 99% of the<br>
> time, it's worthless because it only works when you don't need it."<br>
><br>
> <a href="https://www.imperialviolet.org/2012/02/05/crlsets.html" rel="noreferrer" target="_blank">https://www.imperialviolet.<wbr>org/2012/02/05/crlsets.html</a><br>
><br>
> This is because "[A]n attacker who can intercept HTTPS connections [so<br>
> as to use their bad cert for an MITM] can also make online revocation<br>
> checks appear to fail and so bypass the revocation checks."<br>
><br>
> Gerv<br>
> ______________________________<wbr>_________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
</div></div><br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>