[cabfpub] Certificate lifetimes: end state or trajectory?

[Ben Wilson]

+1  (Sometimes it depends on the type of crash you're involved in.)

-----Original Message-----
From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Robin Alden
via Public
Sent: Friday, March 10, 2017 3:44 PM
To: 'CA/Browser Forum Public Discussion List' <public at cabforum.org>; 'Kirk
Hall' <Kirk.Hall at entrustdatacard.com>; 'Phillip Hallam-Baker'
<philliph at comodo.com>
Cc: Robin Alden <robin at comodo.com>
Subject: Re: [cabfpub] Certificate lifetimes: end state or trajectory?

Adam is cleverer than a whole box-full of the rest of us, but he isn't
infallible and you cannot quote his blog as incontrovertible fact.

It is not true that it only works when you don't need it.
It is true that it doesn't always work when you need it, but that is not the
same thing by any manner of means.

> This is because "[A]n attacker who can intercept HTTPS connections [so 
> as to use their bad cert for an MITM] can also make online revocation 
> checks appear to fail and so bypass the revocation checks."
Maybe.  Maybe not.
It depends where the attacker is situated.
If you're in the same coffee shop as him, you're toast.
If the attacker is sitting in the data center that hosts the site with the
cert, then the attacker can't touch the path between the client and the CA,
so you've overstated the case.

The perfect can be the enemy of the good.

Regards
Robin Alden
Comodo


> -----Original Message-----
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Gervase 
> Markham via Public
> Sent: 10 March 2017 12:37
> To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public 
> Discussion List <public at cabforum.org>; Phillip Hallam-Baker 
> <philliph at comodo.com>
> Cc: Gervase Markham <gerv at mozilla.org>
> Subject: Re: [cabfpub] Certificate lifetimes: end state or trajectory?
> 
> On 03/03/17 20:34, Kirk Hall wrote:
> > Gerv - on the issue of revocation checking, not everyone is asking 
> > for browsers to turn on hard fail if the browser fails to get a 
> > response to a revocation query in a reasonable time..  We would be 
> > very happy to continue with soft fail - but please, turn on 
> > revocation checking again.  Even if the browser doesn't get a timely 
> > response in (say) 10% of queries, if it does receive a response 
> > "revoked" in the other 90% of queries, and displays that to users, 
> > that would be a great increase in user security.
> 
> As noted by Adam Langley, "[S]oft-fail revocation checks are like a 
> seat-belt that snaps when you crash. Even though it works 99% of the 
> time, it's worthless because it only works when you don't need it."
> 
> https://www.imperialviolet.org/2012/02/05/crlsets.html
> 
> This is because "[A]n attacker who can intercept HTTPS connections [so 
> as to use their bad cert for an MITM] can also make online revocation 
> checks appear to fail and so bypass the revocation checks."
> 
> Gerv
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170310/13f10324/attachment.p7s>