Subject: [TLS] Status of X.509v3 TLS Feature Extension?

From: Klemens Baum <[email-masked]>
Date: Thu, 24 Apr 2014 21:55:53 +0200

After the whole Heartbleed incident, it has become obvious that the
current mechanisms for Certificate Revocation are inadequately
enforced by clients.

To combat the issue, it would seem desirable for a security-conscious
server operator to be able to require the use of OCSP stapling on a
per-certificate basis. There was already an Internet-Draft (now
expired) for an X.509v3 extension which would provide this feature:
https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/

Clients supporting the extension could display an enhanced security
indicator (e.g. "Certificate Status: Not revoked") for certificates
carrying the extension which pass validation, which would also
motivate more widespread adoption of OCSP stapling in favor of CRLs
and client-initiated OCSP requests.

Since the draft looked very promising, I suggest that it should be
unexpired. If anyone with the authority to do so agrees, please submit
a request for resurrection per the guidelines at
http://www.ietf.org/ietf-ftp/1id-guidelines.txt.

A few minor clarifications may still be needed so that it can be
quickly implemented by major browsers and the CAs:

- The tls-feature OID is currently specified with a value of { id-pe 1
}, which corresponds to 1.3.6.1.5.5.7.1.1 (authorityInfoAccess, itself
already an X.509v3 extension). Surely a new OID in the
pkix.privateExtension arc will need to be allocated by IANA and if
this is the case, it should be noted in the section "IANA
Considerations".

Please share your opinions!

---

From: Tom Ritter <[email-masked]>
Date: Sun, 27 Apr 2014 08:07:51 -0400

There isn't much gain in requiring it on a per-certificate basis, but
on a host basis it makes a lot more sense. (Not that putting it on a
cert is bad, just insufficient.)  There were a couple ideas for making
this a header here:
http://www.ietf.org/mail-archive/web/tls/current/msg10351.html I too
would like Must Staple to come back.

-tom

On 24 April 2014 15:55, Klemens Baum <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 Apr 2014 12:02:18 +0100

> would like Must Staple to come back.

AIUI, PHB intends to progress the tls-feature draft just as soon as IANA 
allocates an OID for the new certificate extension.  It's not dead, just 
resting.

An OID allocation request was submitted well over a year ago.  The 
reason for the delay is that following the shutdown of the PKIX WG, 
control of the PKIX OID registry is being transferred to IANA.  IINM, 
the transfer is still not yet complete.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 09:39:29 -0400

> An OID allocation request was submitted well over a year ago.  The reason for the delay is that following the shutdown of the PKIX WG, control of the PKIX OID registry is being transferred to IANA.  IINM, the transfer is still not yet complete.

You know, the really cool thing about OID's is that just about anyone can get an arc and that they are really just distributed opaque identifiers. (Kinda like XML namespace UIR's I suppose.)  I'm sure there are many folks who would volunteer if needed.

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Rob Stradling <[email-masked]>
Date: Mon, 28 Apr 2014 15:06:10 +0100

> You know, the really cool thing about OID's is that just about anyone can get an arc and that they are really just distributed opaque identifiers. (Kinda like XML namespace UIR's I suppose.)  I'm s…

I'm well aware of that.

See https://cabforum.org/pipermail/public/2013-November/002333.html

---

From: Russ Housley <[email-masked]>
Date: Mon, 28 Apr 2014 10:13:49 -0400

> An OID allocation request was submitted well over a year ago.  The reason for the delay is that following the shutdown of the PKIX WG, control of the PKIX OID registry is being transferred to IANA.…

The IESG has assigned me as the expert for this IANA registry.  If the document is ready for approval, we can work the review in parallel.

Russ

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Apr 2014 14:20:29 +0000

> allocates an OID for the new certificate extension.  It's not dead, just

OCSP stapling gives no indication of when a verifier is to consider
a particular status response to be stale.  Without any indication
of how often a server is supposed to provide a (more) fresh response,
it is not clear that OSCP stapling enforcement can be implemented
scalably in an interoperable manner, with servers obtaining and
stapling new OCSP responses before clients decide that the extant
response is too old.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 10:32:10 -0400

> OCSP stapling gives no indication of when a verifier is to consider a particular status response to be stale.

Not sure what you mean; thisUpdate, nextUpdate, producedAt aren't sufficient?

	/r$

---

From: Watson Ladd <[email-masked]>
Date: Mon, 28 Apr 2014 07:41:00 -0700

> stapling new OCSP responses before clients decide that the extant

That can be easily fixed by adding a field to the OCSP response, or
more easily by adding the duration of the response to the relevant
OCSP stapling document. I think 24-48 hours ought to be the right
range, but I don't have any strong feeling for why. People with more
clue should weigh in.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Apr 2014 14:52:50 +0000

On Mon, Apr 28, 2014 at 10:32:10AM -0400, Salz, Rich wrote:

> > OCSP stapling gives no indication of when a verifier is to
> > consider a particular status response to be stale.
> 

Well, "nextUpdate" is optional per RFC 6960, and even when present
it is not clear that the frequency of server updates of stapled
OCSP responses is expected to provide responses whose nextUpdate
is always in the future.

Yes, RFC 5019 suggests that nextUpdate is not optional, and that
OCSP clients retry before nextUpdate, as further modified by
"cache-control:max-age", but 

  * What happens if the server can't reach the OCSP responder at that time?
  * How often should it retry?
  * What multiple of the "[thisUpdate, nextUpdate]" window should a client
    use as a grace-period?
  * Do OCSP responders at CAs generally implement RFC 5019?
  * What is the operational experience with fail-closed OCSP?
    (AFAIK most implementations fail open when no OCSP response
    can be obtained).

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 10:57:50 -0400

Those are all really good questions, but seem to me that they're a matter of local trust policy and not policy that should be nailed down in an RFC.  Do you disagree?

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Apr 2014 15:10:53 +0000

On Mon, Apr 28, 2014 at 10:57:50AM -0400, Salz, Rich wrote:

> Those are all really good questions, but seem to me that they're
> a matter of local trust policy and not policy that should be nailed
> down in an RFC.  Do you disagree?

If the protocol is to fail closed (as is I think suggested by the
extension) then it must be possible to implement it interoperably,
in which case these questions should have answers.  As it stands,
I don't see how one would implement an interoperable fail-closed
client and server for OCSP stapling.

Current client implementations probably just set a fixed generous
upper bound, but there is no reason to expect that all CAs produce
new CRLs or new OCSP responses within the arbitrarily locally
selected maximum time.  Nor is it clear that servers obtain new
OCSP responses in a timely manner, and how much extra time to give
them to allow for adverse conditions.

For example a DDoS of a CAs OCSP responder may last longer than
the "[thisUpdate, nextUpdate]" interval, how long is long enough
to allow a CA to recover and for servers to obtain new stapled
responses?  How often should servers retry (don't want the servers
trying to get overdue updates perpetuating the DDoS)?

The protocol looks under-specified to me.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 11:34:02 -0400

> The protocol looks under-specified to me.

I don't read it as fail-closed; there is no definition of "satisfactory" at the end of section eight, and the server is free to not send an OCSP response.

If you consider it to be not fail-closed, are your concerns lessened?
	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Apr 2014 15:47:42 +0000

> If you consider it to be not fail-closed, are your concerns lessened?

What's the point if it does not fail-closed?  The client insists
that the server provide an OCSP response, but then does not validate
it (some notion of freshness is surely part of validation, but no
freshness algorithm is indicated).

Does the server have to provide OCSP responses for every intermediate
CA in the chain?  Or just for the leaf certificate?  Or only for
the leaf certificate and those intermediate CAs whose certificates
happen to include the proposed TLS feature extension?

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Apr 2014 12:04:19 -0400

> What's the point if it does not fail-closed?  The client insists that the server provide an OCSP response, but then does not validate it (some notion of freshness is surely part of validation, but no freshness algorithm is indicated).

A client can always ask for an OCSP response, but it is up to that client to decide whether or not the response is satisfactory. If there's a hurricane bearing down on me, I might be willing to accept a stale status response from my local Red Cross chapter, for example. 

> Does the server have to provide OCSP responses for every intermediate CA in the chain?  Or just for the leaf certificate?  Or only for the leaf certificate and those intermediate CAs whose certificates happen to include the proposed TLS feature extension?

Well RFC 6066 says "only one OCSP response may be sent" and while RFC 2560 allows multiple answers, it says that they are a "response for each of the certificates in the request."  Since the server's SSL cert is implied by 6066, and since there is no other way to specify additional certs, then the answer to your questions would be "just the leaf."

	/r$

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Apr 2014 16:24:59 +0000

On Mon, Apr 28, 2014 at 12:04:19PM -0400, Salz, Rich wrote:

> A client can always ask for an OCSP response, but it is up to
> that client to decide whether or not the response is satisfactory.
> If there's a hurricane bearing down on me, I might be willing to
> accept a stale status response from my local Red Cross chapter,
> for example.

That's nice for an informed, security-literate user operating a
browser, but completely impractical for, say, an SMTP server.  A
reasonably interoperable algorithm is required for deciding which
responses are required and how fresh they need to be before failing
closed.

> > Does the server have to provide OCSP responses for every
> > intermediate CA in the chain?  Or just for the leaf certificate?
> > Or only for the leaf certificate and those intermediate CAs whose
> > certificates happen to include the proposed TLS feature extension?
> 
> Well RFC 6066 says "only one OCSP response may be sent" and while
> RFC 2560 allows multiple answers, it says that they are a "response
> for each of the certificates in the request."  Since the server's
> SSL cert is implied by 6066, and since there is no other way to
> specify additional certs, then the answer to your questions would
> be "just the leaf."

Which leaves the intermediate CAs out of scope...  I plan to continue
to treat CRLs, OCSP and OCSP stapling as variants of the emperor's
new clothes.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 12:33:43 -0500

> Those are all really good questions, but seem to me that they're a matter of local trust policy and not policy that should be nailed down in an RFC.  Do you disagree?

IMO:

 - freshness requirements are indeed ultimately a local policy issue

 - but a server-side freshness commitment is something that can be
pinned to, therefore adding value when local freshness policy is
loose.

The freshness commitment might come from the OCSP responder, but it's
optional.  And the text of the RFC makes it seem very likely that
nextUpdate is all about OCSP responders that poll CRLs, and that OCSP
responders that have direct access to the revocation Truth might well
never include nextUpdate.

The freshness commitment might come from the TLS server -- where?

This might be an item for TACK.

Nico
--

---

From: Adam Langley <[email-masked]>
Date: Mon, 28 Apr 2014 10:34:16 -0700

> The IESG has assigned me as the expert for this IANA registry.  If the document is ready for approval, we can work the review in parallel.

For what it's worth: I support adding a certificate extension to
indicate OCSP Must Staple and
https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ appears
to achieve that.

It's going to take a while for various parts of the ecosystem to get
into shape (including browsers), but it would be good not to block on
OID assignment.

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Mon, 28 Apr 2014 19:42:40 +0200 (CEST)

Viktor Dukhovni wrote:
>Salz, Rich wrote:

There exist 2 different TLS extension for OCSP responses.

Old Single OCSP response:  rfc6066 (originally defined in rfc3546)

New Multiple OCSP responses: rfc6961 

https://tools.ietf.org/html/rfc6961

>>Viktor Dukhovni wrote:

With fail-closed you probably mean "fail-hard"?

EV certs seem to be able to provide a benefit without "fail-hard".

It is difficult to define a global/universal guaranteed service
quality for the OCSP responder service of the CA, and it is
difficult to define a minimum service quality for the server,
in which time an admin will notice and fix a problem with the
OCSP response refreshing of his server.

It is really a client-side local policy issue.  The client could
also perform OCSP request itself for the server's cert (chain),
whenever it does not consider the server's response "fresh enough".

There are two possible "attack" scenarios:

(1) the attacker steals (or breaks) the server's real key&cert,
    so that the Certificate extension will indicate whatever the
    original admin requested when he purchased the certificate

(2) the attacker manages to subvert the RA process of a public CA
    and gets a different cert without the certificate extension issued.

A fail-hard on the certificate extension can not protect you from (2).

-Martin

---

From: [email-masked] (Martin Rex)
Date: Mon, 28 Apr 2014 20:02:18 +0200 (CEST)

Salz, Rich wrote:
> RFC 2560 allows multiple answers, it says that they are a
> "response for each of the certificates in the request."
> Since the server's SSL cert is implied by 6066, and since there
> is no other way to specify additional certs, then the answer to your
> questions would be "just the leaf."

AFAIK, rfc2560 allows the OCSP response to contain the status
of more than one certificate, but it can only be signed by a single
OCSP responder.  I assume that each certificate in the server's
certificate refers to different OCSP responder.

Processing multiple OCSP responses from the TLS multiple certificate status
extension will also be interesting for TLS client that essentially throw
away everything but the Server certificate from the Server's TLS Certificate
handshake message and perform a new path discovery, because the resulting
path may be different from the one that was sent by the server.

This may happen more often with the certificate paths that are used
for backward compatibility, where the current 2048-bit RSA rootCA cert is
included as a cross-CA certificate to an old 1024-bit RSA trust anchor.

Google seems to be using two cross-certs in their forward path that
you may not be aware of if you look at the path of the server cert as
verified by a recent browser.

-Martin

---

From: Stephen Checkoway <[email-masked]>
Date: Mon, 28 Apr 2014 14:17:43 -0400

> EV certs seem to be able to provide a benefit without "fail-hard".

That's the first time I've ever heard that claim. What benefit do they provide users?

-- 
Stephen Checkoway

---

From: Geoffrey Keating <[email-masked]>
Date: 28 Apr 2014 12:26:38 -0700

> OCSP responses is expected to provide responses whose nextUpdate

My understanding is that 'nextUpdate' is essentially the expiry date
for the OCSP response, and that if it's not present, it's considered
to expire immediately (so should never appear in a stapled response?
or have some indeterminate client-determined expiry time that the
server doesn't know about?  or have the nonce matching the one that
the client probably didn't bother to send in the request_extensions
field?  If only there was a RFC that documented how this should
work...).

It is perhaps an unfortunately named field; the naming is based on the
history of OCSP, which was apparently designed to be (basically) CRL
lookup service, so an OCSP responder would just consult its local copy
of the CRL; nextUpdate was when the responder would next fetch a
new copy of the CRL and thisUpdate was the last time it did so.

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 14:35:56 -0500

> whenever it does not consider the server's response "fresh enough".

Right, however, servers cannot know what policies clients have, so how
can they work to provide fresh-enough responses?

A notification from the client, that it is rejecting the server's
credentials due to inadequate freshness, would not necessarily be all
that helpful.

A commitment to a given freshness definitely helps here: the client
can impose the min (or would that be max? :) freshness of local policy
and server commitment.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Apr 2014 14:40:24 -0500

> OCSP response refreshing of his server.

The server basically needs a "cron" job to fetch fresh OCSP responses
regularly.  A sufficiently long failure to get fresh responses should
trigger alerts to get admin attention.

Let's say the server's admins commit to 24 hour freshness (no response
will be older than 24hrs), with a cron job / daemon fetching new
responses every 8 hours.  A first failure to get a response might not
elicit any alerts, but a second should.  (A first failure might lead
to retrying sooner than the otherwise next-scheduled attempt in 8
hours.)

Nico
--

---

From: Geoffrey Keating <[email-masked]>
Date: 28 Apr 2014 12:44:24 -0700

> path may be different from the one that was sent by the server.

This is only a problem if the new path discovery might use
certificates which weren't sent from the server (built-in
intermediates or ones fetched from the web), for which of course the
server won't have sent OCSP responses.  Another way to put this is
that the server needs to send all necessary intermediates for OCSP
stapling to work properly.

---

From: Rob Stradling <[email-masked]>
Date: Tue, 29 Apr 2014 15:58:09 +0100

> The IESG has assigned me as the expert for this IANA registry.  If the document is ready for approval, we can work the review in parallel.

Thanks Russ.

BTW, Phill posted this a few weeks ago:
http://article.gmane.org/gmane.comp.mozilla.devel.security.policy/491

Phill, can we progress this now?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Apr 2014 16:20:01 -0400

I just submitted an update to keep it current.

http://www.ietf.org/id/draft-hallambaker-tlsfeature-03.txt

The issue is not the OID, it is support in the browsers. If there is
support from one browser provider we can get backing to publish the
draft. Without implementation in at least one of the browsers it does
not help.

-- 
Website: http://hallambaker.com/

---

From: Rob Stradling <[email-masked]>
Date: Tue, 29 Apr 2014 21:33:05 +0100

AGL wrote: "For what it's worth: I support adding a certificate 
extension to indicate OCSP Must Staple and 
https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ appears 
to achieve that."

Brian Smith wrote: "I think we'll be able to finish the Must-Staple
implementation soon. Check with David (Keeler)".

So ISTM that this I-D has the backing of at least two browsers.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 29 Apr 2014 13:57:25 -0700

>stapling to work properly.

Yes.  This is critical.  Implementations currently do not support
OCSP stapling for intermediaries. Just fielded a system and we
Ended up not being able to support business models with more
than one level of usable hierarchy.  Stapling  is not useable
now for multi-level hierarchies.

Paul

---

From: Adam Langley <[email-masked]>
Date: Tue, 29 Apr 2014 14:09:36 -0700

> now for multi-level hierarchies.

It might well be that Must Staple is best done for just the leaf and
that pushed CRLs are used for intermediate revocations. That's the
deployment model that I think is mostly likely.

As for Chrome's support: it's tough because we use different libraries
on different platforms (CAPI on Windows, OS X's library there and NSS
in other places). We also have a lot happening with our switch to
OpenSSL. So, while we would like to support Must Staple, that is
currently delaying it. Hopefully Firefox can beat us to it.

Cheers

AGL

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Apr 2014 16:22:40 -0500

> currently delaying it. Hopefully Firefox can beat us to it.

The deployment model I imagine is:

 - servers run a daemon to get fresh OCSP Responses periodically
 - this daemon raises alerts if responses get too old
 - servers staple the responses fetched by this daemon

 - clients validate all stapled responses

Why couldn't that work?  There'd be a need to cache OCSP Responses for
intermediates, sure.  What else?

Nico
--

---

From: Adam Langley <[email-masked]>
Date: Tue, 29 Apr 2014 14:25:40 -0700

> intermediates, sure.  What else?

That's totally viable, I'm just suggesting that revocations of
intermediates are very rare and generally involve browser pushes in
any case. So the effort of getting a server that does multi-stapling
over just stapling, and of shipping the extra OCSP responses in every
handshake, might well win out. I think it would be quiet reasonable
for a site to have Must Staple just for the leaf certificate.

Cheers

AGL

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 29 Apr 2014 17:28:09 -0400

> It might well be that Must Staple is best done for just the leaf and that pushed CRLs are used for intermediate revocations.
> That's the deployment model that I think is mostly likely.

+1

---

From: Nico Williams <[email-masked]>
Date: Tue, 29 Apr 2014 16:57:52 -0500

> for a site to have Must Staple just for the leaf certificate.

I suspect that for intermediates closer to the server it'll be best to
staple responses.  For intermediates closer to the root issuer it'll
be best to deal with pushing.

We have to consider environments where long cert paths are involved,
and where network connectivity isn't universal.

Of course, in bridged PKIs the RPs have to handle revocation checking
for part of the cert path anyways.

I think the right thing to do may well be to implement full stapling
but configure partial stapling as appropriate:

a) stapled OCSP checking on the client side
b) CRL checking / push on the client side
c) full _and_ partial OCSP stapling on server sides

d) server admins need to configure stapling (and refreshing) of
whatever length of the server cert chains is appropriate, from the
leaf towards the root.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 29 Apr 2014 18:17:03 -0400

>> That's the deployment model that I think is mostly likely.

If we revoke an intermediate that doesn't have a name constraint in
then I can't see how we would not be doing some pretty aggressive
pushing out of the CRL.

Name constraints might change that calculus at some point in the
future, but not for quite a long time.