[cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

Tue Feb 7 04:00:49 UTC 2017

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.

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).

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.

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.

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.

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.

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.

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...

On Mon, Feb 6, 2017 at 7:34 PM, Eric Mill <eric at konklone.com> wrote:

> > * No, not really.  Expired certificates let you click-through while
> revoked certificates are a hard fail, the way it should be (per Rob)
>
> I don't think this (or Rob's original comment) are accurate as stated.
>
> *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.
>
> So during many kinds of attack, a revoked certificate *can* 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.
>
> 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 (
> https://https.cio.gov).
>
> Even without HSTS present, expired certificates *can**not* 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.
>
> 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".
>
> -- Eric
>
> On Mon, Feb 6, 2017 at 5:25 PM, Doug Beattie via Public <
> public at cabforum.org> wrote:
>
>>
>>
>>
>>
>> *From:* Ryan Sleevi [mailto:sleevi at google.com]
>> *Sent:* Friday, February 3, 2017 6:01 PM
>> *To:* Doug Beattie <doug.beattie at globalsign.com>
>> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
>> *Subject:* Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of
>> Certificates
>>
>>
>>
>> I'll try to simplify the replies, because it seems that giving a long
>> list of reasons is causing too much confusion:
>>
>> * 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.
>>
>>
>>
>> * Did you know that Google’s CAA record is not correct? – Google is
>> issuing SSL certificates to their domains but google.com is not listed
>> in the CAA record.  Am I misinterpreting CAA?
>>
>>   https://toolbox.googleapps.com/apps/dig/#ANY/google.com
>>
>>   *google.com <http://google.com>. 86399 IN CAA 0 issue "symantec.com
>> <http://symantec.com>"*
>>
>> * 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?
>>
>> https://static.googleusercontent.com/media/pki.google.com/en
>> //GIAG2-CPS-1.4.pdf
>>
>>
>>
>>
>>
>> 1) Do you acknowledge and agree that a shorter-lived certificate makes
>> for a natural revocation?
>>
>> * No, not really.  Expired certificates let you click-through while
>> revoked certificates are a hard fail, the way it should be (per Rob)
>>
>> * 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
>>
>> * Wouldn’t a WebPKI revocation system help more than shorter validity
>> period certificates?
>>
>>
>>
>> 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?
>>
>> * 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.
>>
>>
>>
>> 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?
>>
>>
>>
>> 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.
>>
>> CAA – Google isn’t even doing CAA for their CAs yet, so how important can
>> it really be?
>>
>> SHA-1 – as I’ve said before, not related to short validity certificates
>>
>>
>>
>> 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?
>>
>>
>>
>>
>>
>>
>>
>> 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.
>>
>> * 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> 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.
>>
>>
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>
>
> --
> konklone.com | @konklone <https://twitter.com/konklone>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170206/bab25533/attachment-0003.html>