Subject: [saag] Using short term certificates (instead of revocation)

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Oct 2017 22:03:06 +0300

Hi all

We’ve submitted this -00 draft for your consideration. It is still very rough with several sections missing, but we feel it’s good enough for starting a conversation.

There is quite a bit of interest in using short term certificates recently. There is a draft at ACME, a proposed draft at STIR, and many use cases in IT, whether these certificates are exchanged with TLS or with IKE or SSH. Some of these use cases are web, but many others are not.  The purpose of this draft is to list considerations, both operational and security, for using short term certificates without revocation.

If this effort is successful, the resulting document should guide both draft writers and IT people in answering two important questions:
 1. When is using short term certificates appropriate?
 2. What needs to be in place for a functional, reliable and secure deployment?

Any comments will be greatly appreciated.

Thanks

Yoav on behalf of the authors.

> Begin forwarded message:
> 
> 
> A new version of I-D, draft-nir-saag-star-00.txt
> has been successfully submitted by Yoav Nir and posted to the
> IETF repository.
> 
> Name:		draft-nir-saag-star
> Revision:	00
> Title:		Considerations For Using Short Term Certificates
> Document date:	2017-10-14
> Group:		Individual Submission
> Pages:		14
> URL:            https://www.ietf.org/internet-drafts/draft-nir-saag-star-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nir-saag-star/
> Htmlized:       https://tools.ietf.org/html/draft-nir-saag-star-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nir-saag-star-00
> 
> 
> Abstract:
>   Recently there has been renewed interest in an old idea: Issue
>   certificates with short validity periods and forego revocation
>   processing, reasoning that expiration is a sufficient replacement for
>   revocation as long as that expiration is not too far off.
> 
>   This document covers considerations, both security and operational,
>   for using such Short Term Auto Renewed (STAR) certificates for
>   various scenarios where Using a revocation protocol is considered
>   inappropriate.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Oct 2017 18:52:26 -0500

> Any comments will be greatly appreciated.

A note in passing from skimming the draft: TLS 1.3 will permit OCSP stapling
for client certificates.

-Ben

---

From: Jeremy Rowley <[email-masked]>
Date: Wed, 18 Oct 2017 00:46:04 +0000

If I can capture some of the other discussions around short-lived certs here. Note that this is a collection of the previous discussion points and not necessarily my view in all cases.

The reasons for it:
1) Unstable regimes. Some users deploy short-lived certificates to servers operating in unstable regions.  They want to shut off the server more rapidly than current revocation caching permits. Alternatively, these operators want to protect against government intervention, closing the certificate account to block additional issuance instead of waiting until the revocation information updates. This is especially vital where the government can block access to revocation information.  Although stapling provides similar results, some servers don't want to call out to a third party for this information.  I'm not sure why.
2) Smaller certificate sizes. Everyone loves smaller certs and handshakes. Cutting out revocation information reduces the size. Cutting out a signed blob of revocation information from the handshake makes it even better.  Why transmit revocation information if the cert will expire before its updated? I think almost every CA pre-signs their revocation responses, meaning that initial revocation response will always be "good" for clients caching the information.
3) Faster updates to certificate profiles.  If something goes wrong, an entity can shift their entire certificate production to short-lived certs within days. Say RSA is no long secure. With fast roll-overs, the entire server farm could shift to ECC within days by updating the delivered profile.
4) Current support. All UAs (I know of) support certificate expiration.  This means that short-lived certs will effectively work in all UAs, new or old. Stapling only works with servers and browsers specifically implementing stapling.  Mozilla already supports non-checking of revocation for short-lived certs.  Other UA's do not strictly support short-lived certificates but currently do not check revocation using traditional revocation mechanisms. Those that do provide soft-fail when the revocation response is not returned. Most (or all) fail on expired certificates. Entities using short-lived certs effectively migrate to hard-fail instead of soft-fail because of how UAs process expiration compared to revocation. This also leads to a more consistent user experience. Stapling may eventually result in hard-fail (https://blog.mozilla.org/security/2015/11/23/improving-revocation-ocsp-must-staple-and-short-lived-certificates/)? But see https://groups.google.com/a/chromium.org/forum/#!topic/chromium-discuss/F9oHW0u339E for the contrary.  5) Customized certs for dynamically changing domain names.  Devices we've seen use a name like [random].[identifier].example.com as their DNS identifier. Some of these identifiers change the random part occasionally. Using short-lived certs allows the device to update the digital certificates at the identifiers change, getting a new certificate as necessary to support the connected device.  I'm not sure why the identifiers change. Perhaps whenever it calls home to whatever monitoring service, such as a subscription account? 

Reasons against it:
1) Immediate revocation. Occasionally a CA may mis-issue a certificate and revoke the certificate prior to distribution to any end-point. In this case, the CA can revoke the certificate without worrying about UA caching. The rebuttal is that a CA is mis-issuing certificates is just as likely to omit the revocation information as make another mistake.
2) No value. Stapling accomplishes similar results, effectively negating any usefulness of short-lived certificates. Although stapling requires the server to communicate with the CA, this is no different than what's already required for short-lived certs. In fact, stapling is better. Most CAs publish revocation information via CDN, meaning it's highly available and easy to access. Certificate publication usually happens at an address controlled and operated by the CA, without use of a CDN. The availability of these addresses is sometimes questionable. 
3) Risk Analysis. If OCSP caching and stapled life-cycles are set to a lower value than the certificate lifecycle, OCSP stapling is superior because of the immediate revocation advantages.  If OCSP responses are refreshed every 24 hours, short-lived certs will remain valid for a longer period of time than the OCSP response and require more work because of installation and configuration requirements on the server side. Therefore, the solution is to simply lower OCSP responses to a shorter validity period and eliminate OCSP caching. 
4) Conflict with CT. Who wants to run a log full of short-lived certs? Short-lived certs undermine the industry attempts at creating additional transparency into the CA ecosystem by making logs unmanageable for the log operators and monitors. Trying to build a log scalable to that magnitude is hard - our current log couldn't do it.

-----Original Message-----
From: saag [mailto:[email-masked]] On Behalf Of Benjamin Kaduk
Sent: Tuesday, October 17, 2017 5:52 PM
To: Yoav Nir <[email-masked]>
Cc: Security Area Advisory Group <[email-masked]>
Subject: Re: [saag] Using short term certificates (instead of revocation)

> Any comments will be greatly appreciated.

A note in passing from skimming the draft: TLS 1.3 will permit OCSP stapling for client certificates.

-Ben

---

From: Yoav Nir <[email-masked]>
Date: Wed, 18 Oct 2017 08:19:59 +0300

On Tue, 2017-10-17 at 18:52 -0500, Benjamin Kaduk wrote:
> > We’ve submitted this -00 draft for your consideration. It is still
> > very rough with several sections missing, but we feel it’s good
> > enough for starting a conversation.
> > 
> > There is quite a bit of interest in using short term certificates
> > recently. There is a draft at ACME, a proposed draft at STIR, and
> > many use cases in IT, whether these certificates are exchanged with
> > TLS or with IKE or SSH. Some of these use cases are web, but many
> > others are not.  The purpose of this draft is to list
> > considerations, both operational and security, for using short term
> > certificates without revocation.
> > 
> > If this effort is successful, the resulting document should guide
> > both draft writers and IT people in answering two important
> > questions:

Hi, Ben.

Thanks. I should mention this in the draft. 

I guess that in a year or so, when TLS 1.3 is in OpenSSL, Windows and
the major Linux distributions (OK, maybe I'm being a bit optimistic)
this advantage will be gone.  Still it's nice that short term
certificates work with everything that's out there now and with what
will be considered legacy in the next few years.

Yoav

---

From: Michael StJohns <[email-masked]>
Date: Wed, 18 Oct 2017 10:18:17 -0400

> Yoav on behalf of the authors.

Hi Yoav -

The clockSkew commentary is useful, but misses the problem that you 
might not actually have a version of secure time available at all or 
consistently or different RPs may or may not have the same clocks. Some 
of the smaller IOT devices can't afford either an RTC or the power for 
an RTC and trusting mesh time might be problematic.  It would be helpful 
if you would expand upon your expectations for time domain support 
either in the intro or somewhere before you get into the discussions 
with skew. E.g. its OK to exclude IoT usages that depend on reliable 
time, but best to set expectations.

I've been trying to think about how to provide something that allows 
certs to expire or be validated without dependence on clock time - its 
not an easy problem.

Last - you may want to chat about the fact that - with clock skew - the 
certificate holder and the relying party may have different ideas about 
validity for a given cert and the error handling related to this problem.

Thanks - Mike

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Kent Watsen <[email-masked]>
Date: Mon, 23 Oct 2017 17:58:45 +0000

Ho Yoav,

You might be interested in this as well:

  Renewals instead of Revocations:
  https://tools.ietf.org/html/draft-ietf-anima-voucher-05#section-7.1

Thanks,
Kent

Hi all

Thanks

---

From: Yoav Nir <[email-masked]>
Date: Mon, 23 Oct 2017 22:01:04 +0300

Hi, Kent

Thanks for that.

One argument I’ve heard from people not associated with the IETF and PKIX tradition is that it seems to them redundant to have both a signed assertion (the certificate) and then another assertion (CRL or OCSP response) saying that the first assertion is valid. If you take revocation seriously you have to wonder how do we know the second assertion is valid. Quis custodiet ipsos custodes?

So it makes sense to make them just one assertion. It simplifies things. At least it should be an acceptable option.

Yoav

> On 23 Oct 2017, at 20:58, Kent Watsen <[email-masked]> wrote:
> 
> Ho Yoav,
>