Subject: [TLS] OCSP in RFC7525bis

From: Yaron Sheffer <[email-masked]>
Date: Wed, 19 Jan 2022 16:57:07 +0200

Hi,

RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail if they don’t get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it’s trying to solve.

So for the new BCP, we have three options:

Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.

Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.

We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be very useful.

Thanks,

Peter, Thomas and Yaron

PS: apologies for cross-posting.

[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5

[2] https://github.com/yaronf/I-D/pull/279/files

[3] https://cbw.sh/static/pdf/chung-imc18.pdf

---

From: Hanno Böck <[email-masked]>
Date: Wed, 19 Jan 2022 17:01:45 +0100

Hi,

On Wed, 19 Jan 2022 16:57:07 +0200
Yaron Sheffer <[email-masked]> wrote:

> But this raises a larger question: many client-side implementations
> soft-fail if they don’t get an OCSP response within the handshake,
> i.e. they just ignore the problem. As far as we understand, this
> makes OCSP stapling completely ineffective for what it’s trying to
> solve.

I think the missing piece here is the so-called OCSP "must staple"
extension (RFC 7633).
This allows telling a client in the certificate that a certificate may
only be used if it has a valid staple.

This hasn't seen widespread use yet as far as I know, and one reason is
that up until recently major OCSP stapling implementations were quite
fragile and would behave strangely under conditions like the CA being
offline (kinda also defeating the purpose of stapling). Adding a
hard-fail stapling requirement to a fragile stapling implementation is
not a good idea. This has improvde in Apache recently, however requires
a maybe not widely known option ("MDStapling") that is not the default.
I'm not sure about the situation in nginx.

-- 
Hanno Böck
https://hboeck.de/

---

From: Mohit Sahni <[email-masked]>
Date: Wed, 19 Jan 2022 08:57:50 -0800

Hi,
> Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.
I don't think that OCSP is not adding value in its current form. I
have seen a lot of OCSP implementations with hard fail, especially on
the server side for authenticating clients using private PKI
certificates. Although OCSP does not add much value on the client side
as it's a bit fragile for public PKI and client side checks because of
the matrix of multiple OCSP status producers and consumers at scale.

-Mohit

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 19 Jan 2022 13:45:53 -0500

For additional context, here's s research study we published a few years
back on OCSP must-staple in the Web context:
https://cbw.sh/static/pdf/chung-imc18.pdf

Nick

On Wed, Jan 19, 2022 at 11:58 AM Mohit Sahni <[email-masked]> wrote:

> > Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly
> also TLS 1.2 implementations) to fail the handshake if the OCSP response is
> missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 19 Jan 2022 10:49:32 -0800

On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer <[email-masked]> wrote:

> Hi,
>
>
>
> RFC 7525 (the TLS BCP) has a section [1] with “weak” recommendations to
> use OCSP and OCSP stapling. We are changing these recommendations [2] in
> view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.
>
>
>
> soft-fail if they don’t get an OCSP response within the handshake, i.e.
> they just ignore the problem. As far as we understand, this makes OCSP
> stapling completely ineffective for what it’s trying to solve.
>

Well, many browser implementations have just stopped using OCSP entirely,
in favor of centralized revocation information a la CRLSets, etc.

I don't know what non-browser implementations do.

>    - Add a SHOULD-level requirement (for TLS 1.3 implementations,
>    possibly also TLS 1.2 implementations) to fail the handshake if the OCSP
>    response is missing or invalid. (As far as we can tell, RFC 8446 is silent
>    on this.)
>
>
I don't think this is a good idea.

>    -
>    - Remove the whole discussion of OCSP, saying that in its current form
>    it’s not adding value.
>    - Maintain the status quo, where many people implement OCSP on the
>    server side, but clients rarely benefit.'
>
> I think if we are to have anything here it would need to actually describe
the situation and why people soft fail and/or are moving away from OCSP.

I might be able to provide some text from the browser perspective, though
perhaps AGL or Carrick could also chime in?

-Ekr

>
>    -
>
>
>
> We would be grateful for feedback based on implementation experience. In
> particular if you have quantitative data on the use or quality of OCSP
> that’s more recent than Chung18 [3], that would be very useful.
>
>
>
> Thanks,
>
>                 Peter, Thomas and Yaron
>
>
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 19 Jan 2022 13:59:56 -0500

> On 19 Jan 2022, at 9:57 am, Yaron Sheffer <[email-masked]> wrote:
> 
> 	• Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

IMHO unrealistic and self-defeating.

> 	• Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.

Largely this.

> 	• Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.

Or this.

> We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that’s more recent than Chung18 [3], that would be ve…

For example "Let's Encrypt" supports issuing certificates with "must staple",
but this an opt-in feature.  So as an attacker who can impersonate the subject,
I won't ask for "must staple", and so this is just security theatre.

In Postfix, I have elected to not waste time supporting either CRLs or OCSP.
If one wants TLS-authenticated SMTP one can use DANE, where there's no need
for "revocation", just publish a fresh TLSA RRset that does not match any
compromised keys or unauthorised certificates.

-- 
	Viktor.

---

From: Andrei Popov <[email-masked]>
Date: Wed, 19 Jan 2022 21:46:00 +0000

Speaking for a broader-than-browser implementation: PKI stack in Windows found hard failure on OCSP non-deployable.
This is not to say that OCSP is entirely useless; OCSP information is considered as part of certificate validation.
A very much simplified summary:

  *   If OCSP says "revoked", certificate validation fails.
  *   Without positive OCSP response, CRL processing is used.
  *   "Must staple" extension is supported.
  *   Apps have latitude in how they handle "revocation offline" scenarios.

Cheers,

Andrei

From: Uta <[email-masked]> On Behalf Of Eric Rescorla
Sent: Wednesday, January 19, 2022 10:50 AM
To: Yaron Sheffer <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [Uta] OCSP in RFC7525bis

On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

RFC 7525 (the TLS BCP) has a section [1] with "weak" recommendations to use OCSP and OCSP stapling. We are changing these recommendations [2] in view of OCSP stapling in TLS 1.3 and the obsolescence of RFC 6961.

But this raises a larger question: many client-side implementations soft-fail if they don't get an OCSP response within the handshake, i.e. they just ignore the problem. As far as we understand, this makes OCSP stapling completely ineffective for what it's trying to solve.

Well, many browser implementations have just stopped using OCSP entirely, in favor of centralized revocation information a la CRLSets, etc.

  *   Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

  *
  *   Remove the whole discussion of OCSP, saying that in its current form it's not adding value.
  *   Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.'
I think if we are to have anything here it would need to actually describe the situation and why people soft fail and/or are moving away from OCSP.

I might be able to provide some text from the browser perspective, though perhaps AGL or Carrick could also chime in?

-Ekr

  *

We would be grateful for feedback based on implementation experience. In particular if you have quantitative data on the use or quality of OCSP that's more recent than Chung18 [3], that would be very useful.

Thanks,
                Peter, Thomas and Yaron

[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7525%23section-6.5&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150629004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7889gR6y%2FLANzyYcMKnoaRQWTsOCekiZ3t3mGdh9xBo%3D&reserved=0>
[2] https://github.com/yaronf/I-D/pull/279/files<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fyaronf%2FI-D%2Fpull%2F279%2Ffiles&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150629004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6zhOrdItJwexqo3TjZ%2F8Xr7ox9VveirU0QktippCURM%3D&reserved=0>
[3] https://cbw.sh/static/pdf/chung-imc18.pdf<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcbw.sh%2Fstatic%2Fpdf%2Fchung-imc18.pdf&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150678992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=b1OpjmGl2nVNIN85yOq2RSbmAEgPsr3xIgLxRSgGhC8%3D&reserved=0>

_______________________________________________
Uta mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/uta<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Futa&data=04%7C01%7CAndrei.Popov%40microsoft.com%7C8903718cbfd047a9f2ee08d9db7ca6cb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637782151150678992%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=6QlOv9WDCw0Z8WnjYUHb1HhSiYqrjd5tAzXZ5N6EI5w%3D&reserved=0>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 20 Jan 2022 09:59:56 +0000

Hi Yaron,

Where do you believe OCSP will be a good fit and why?

Ciao
Hannes

From: TLS <[email-masked]> On Behalf Of Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: [email-masked]; [email-masked]
Subject: [TLS] OCSP in RFC7525bis

Hi,

  *   Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)
  *   Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.
  *   Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.

Thanks,
                Peter, Thomas and Yaron

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Hanno Böck <[email-masked]>
Date: Thu, 20 Jan 2022 14:40:54 +0100

Reading the discussion so far I want to raise something to consider.

There are separate questions that shouldn't be confused:
1. Is OCSP stapling with soft-fail (absent further enforcement
mechanisms like muststaple) actually useful?
2. Should server operators enable OCSP stapling?

For 1. one can reasonably argue that it is not, as an attacker can
potentially rely on the softfail property.

However for a server operator the question isn't just whether OCSP
stapling serves its purpose. A server operator naturally will have to
deal with a variety of clients that have a variety of behaviors. Some
clients will do OCSP requests when no stapled response is sent.

Thus even if you think OCSP stapling and the whole process of revocation
is useless, there are still good reasons for a server operator to enable
stapling:
1. It avoids an extra connection for clients to the OCSP server, thus
making client connections potentially faster.
2. It avoids a potential privacy issue for clients who would otherwise
leak their intent to connect to a specific host to their CA.

tl;dr I think enabling OCSP stapling on servers almost always makes
sense.

-- 
Hanno Böck
https://hboeck.de/

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 20 Jan 2022 16:17:52 +0200

Hi Hannes,

This is not about my personal beliefs. RFC 7525 looks at certificate revocation in the context of TLS (and not only TLS for Web use but the broader ecosystem) and recommends OCSP and OCSP Stapling as the best available techniques to enable effective certificate revocation, but with caveats. It’s been more than 6 years since the RFC was published, and we are reviewing our recommendations, which may or may not still be valid.

Thanks,

Yaron

From: Hannes Tschofenig <[email-masked]>
Date: Thursday, January 20, 2022 at 12:00
To: Yaron Sheffer <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: OCSP in RFC7525bis

Hi Yaron,

Ciao

Hannes

Hi,

1.      Add a SHOULD-level requirement (for TLS 1.3 implementations, possibly also TLS 1.2 implementations) to fail the handshake if the OCSP response is missing or invalid. (As far as we can tell, RFC 8446 is silent on this.)

2.      Remove the whole discussion of OCSP, saying that in its current form it’s not adding value.

3.      Maintain the status quo, where many people implement OCSP on the server side, but clients rarely benefit.

Thanks,

Peter, Thomas and Yaron

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 20 Jan 2022 12:18:25 -0500

> leak their intent to connect to a specific host to their CA.

Without wanting to debate the merits too much, because I am cognizant that
opinions are mixed, I would want to push back on the first assertion there.

>From a server perspective, this involves potentially sending the response
on every connection, where a client initiated (or out of band delivered)
request would amortize that cost over the lifetime of the response.

That is, in the context of RFC 5019, which has long been seen as the only
“internet scale” way to deliver OCSP (by leveraging HTTP and
intermediary/CDN caching), the client doesn’t need to request a new
response for the lifetime of the response/caching directives.

However, in the server stapled case, it is not able to effectively / safely
slide that. There was a lot of discussion about this imbalance during the
discussion of TLS cached info, and the tradeoffs there, but I hope we can
agree that even then, it’s not widely supported.

In practice, for most clients, OCSP stapling will add non-trivial overheads
to the connection establishment, especially given the lack of widely
adopted OCSP response profiles and practices (e.g. CAs including more
certificates than necessary).

I don’t dispute the theoretical value of your second point, and the nature
of the chicken-and-egg problem of “If a client wants privacy, should it
rely on the server to change, or should it change” (which we see similarly
playing out with things like DoH or ECH). However, it’s worth highlighting
that OCSP stapling is not the only way to achieve those privacy goals, and
it’s not as low cost as your first point suggests.

Unsurprisingly, this means I agree with EKRs recommendations for the path
forward on this draft, namely, avoiding the SHOULD. It would be interesting
to explore that tradeoff space, as he suggests, but I realize that this
discussion likely highlights that it will be a delicate needle to thread to
do so in a timely fashion.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 20 Jan 2022 22:30:41 -0500

On Wed 2022-01-19 16:57:07 +0200, Yaron Sheffer wrote:
> * Add a SHOULD-level requirement (for TLS 1.3 implementations,
> possibly also TLS 1.2 implementations) to fail the handshake if the
> OCSP response is missing or invalid. (As far as we can tell, RFC 8446
> is silent on this.)

This sounds a lot like a "SHOULD BUT WE KNOW YOU WONT".  Why would a
client deliberately fail a connection when the problem might be a flaw
with an unrelated network service or a client-specific routing failure?

I think we can definitely explicitly recommend:

 A) clients MUST require valid stapled OCSP response when encountering a
    certificate with "must staple" extension.  (this is just following
    the specs, but i don't think it's as widely supported as it should
    be; maybe we need some public naming/shaming?)

I'm less sure about, but could be convinced of:

 B) server operators SHOULD use certificates with "must staple"
    extension.

Figuring out how to properly incentivize (B) is the hard part.

It looks a lot like the "you should adopt DNSSEC" argument.  Most
sysadmins find that unconvincing, because they hear it as "your network
services need this additional point of failure".

Plus, adopting this for your own certificates only helps in the event of
secret key theft that the legit admin notices -- she can then respond by
revoking the key and trusting the OCSP responder to not issue valid OCSP
responses.

As Victor rightly points out, a more likely threat model today is that
the adversary spoofs your DNS or your routing, and uses that spoofing to
get one of the ACME providers (e.g., let's encrypt) to issue new
certificates entirely.

So the right set of fixes to defend against all these kinds of attacks
are:

- enable DNSSEC for your zone

- signal in your DNS (e.g. via CAA, RFC 8659) that you only want a
  specific set of CAs to issue certificates in your zone (CAA doesn't
  explicitly describe an option to require that the CA use must-staple,
  but it looks like any CA could declare a CAA parameter that would
  offer that guidance.  for example:
  https://github.com/letsencrypt/boulder/issues/5903)

- ensure that your account with those CAs requires must-staple (either
  with your CA's preferred CAA parameter, or some other way)

- monitor CT logs for certificates that violate your CAA policy

This should close all the gaps that i can see, making the whole chain as
strong as your control over what gets signed by your zone's DNSSEC
signing key (and your CA's adherence to CAA policy, of course).

        --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 20 Jan 2022 23:51:22 -0500

>     be; maybe we need some public naming/shaming?)

Isn't this also a "MUST, BUT WE KNOW YOU WON'T AND PROBABLY SHOULDN'T"?

There are good reasons that clients have not, and potentially will never,
support Must-Staple, whether it be for the technical reasons that many
servers are unfit to support it, or for policy reasons, such as wanting to
be careful about the security policies of their products, and how much of
that is outsourced to CAs. The choice about whether to require stapling or
not _is_ a policy decision relevant not only to server operators, but also
relying parties, and can be easily abused by CAs if given that lever. Given
the concerning practices already seen with respect to revocation, which are
detrimental to the security goals of both server operators and end users, a
full-throated MUST seems a bit incompatible with the notion of allowing
policy flexibility. For example, in a world where a client delivers
revocation information out of band, as nearly every major web browser does
today (as one example), "must staple" is of questionable benefit.

> signing key (and your CA's adherence to CAA policy, of course).

Without wanting to detract too much from the core question of the thread,
how does this address the routing gap? The adversary at the routing layer
just redirects the host being validated to control the key that way, and
simply interrupts the nameserver during the CAA check. In the threat model
you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA
checks.

The assumption here for this model to hold is that the CAA information is
infallibly guaranteed to be delivered to the CA (it is not), and that the
CA will properly adhere to it for all threats that are concerning (they do
not). Without those properties, this doesn't provide any value, and that
rather significantly undermines the argument for the MUST for Must-Staple
being made for clients/relying parties.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 21 Jan 2022 09:48:49 -0500

Hi Ryan--

I share your skepticism, but i'm still trying to salvage something
useful -- for the purpose of defending against CA malfeasance -- from
the mechanisms we have available.

On Thu 2022-01-20 23:51:22 -0500, Ryan Sleevi wrote:
> that is outsourced to CAs.

If certificate validation is the process of confirming what a CA says,
then a CA that has said "this certificate should not be considered valid
unless you also have a reasonable proof of freshness" is pretty
unequivocal.  maybe the MUST should be "MUST NOT accept unless a
reasonable proof of freshness is available, for example a stapled OCSP
response"?

Of course a client is free to ignore what the CA says and accept the
certificate anyway.  But once you're ignoring what the CA actually wrote
and signed in the certificate, you're on your own.

https://datatracker.ietf.org/doc/html/rfc7633#section-4.2.3.1 only says
"SHOULD" here, but then it's a bit fuzzy about the exceptional cases for
the "SHOULD".  the first paragraph of exception is "if it has some other
proof of freshness", and the second paragraph is "if you'd fallback to
cleartext anyway" -- does the final caveat of "MUST NOT distinguish that
connection as secure" refer to both cases, or just the latter?

> The choice about whether to require stapling or not _is_ a policy
> decision relevant not only to server operators, but also relying
> parties, and can be easily abused by CAs if given that lever.

What kind of abuse are you anticipating here?  can you spell it out in
more detail?

> Given the concerning practices already seen with respect to
> revocation, which are detrimental to the security goals of both server
> operators and end users, a full-throated MUST seems a bit incompatible
> with the notion of allowing policy flexibility.

Do you think that a MUST validate the intended DNS name against the sAN
in the certificate is also incompatible with the noton of allowing
policy flexibility?

> For example, in a world where a client delivers revocation information
> out of band, as nearly every major web browser does today (as one
> example), "must staple" is of questionable benefit.

do major web browsers deliver revocation out of band for end entity
certificates?  My impression was that most CRLSets would only be updated
and pushed for known-compromised CA certs (intermediate or root) and
very widely-visited end entities.  I don't think a small end entity will
benefit from CRLSet distributions, but i'd love to be wrong.

> you're concerned about (Web PKI), DNSSEC is soft-fail, particularly for CAA

If DNSSEC is soft-fail for the CA verifying CAA checks, then i agree
this is insufficient.  The letsencrypt implementation is apparently at
least logging the info about DNSSEC signatures.

   https://github.com/letsencrypt/boulder/issues/2700

Do you think that DNSSEC should be soft-fail for CAA checks, or should
we urge the CAs to be more strict here?  Perhaps that would be another
recommendation.

> not).

I agree that CAs are not guaranteed to follow the policy guidelines.
However, a server operator can choose a CA that it believes *will*
follow this guidance, and use a CAA record to indicate that all other
CAs would be misissuing if they grant a cert for the operator's name.
Then they can use CT to identify the misissuing CA, and use, uh,
political(?) channels to try to get that CA taken down for failing to
meet the BR.  That's where the CRLSet comes in, right?

This is a teetering chain of ugly dependencies.  I'm not very happy with
it.  But i don't see what the alternative is in the current landscape if
we want folks to be better protected against misissued certificates.

> Without those properties, this doesn't provide any value, and that
> rather significantly undermines the argument for the MUST for
> Must-Staple being made for clients/relying parties.

I don't see why it undermines the MUST for RP's supporting Must-Staple.

fwiw, this whole revocation system seems much closer to "so complex
there are no obvious problems" than "so simple that there are obviously
no problems" :(

   --dkg

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Jan 2022 15:23:56 +0000

For that, you mainly want certificate transparency, no?

    unequivocal.

While I like this sentiment, I think there are a couple of arguments against it. First, there's the ever-present escape hatch of out of band, or local policy. Second, there is the history of poor behavior by some CA's, which leads to the primary user agent (browsers, or perhaps TLS runtimes) not being able to just completely trust them. Perhaps that historic era has passed, and it is time for user agents to end their probation of CA's? Not for me to say.

> But once you're ignoring what the CA actually wrote

It's not that I'm on my own, but that the user agent is deciding.  Now, I grant that the vast majority of users are not capable of making a decision, let alone an informed one, but I think it might be useful for us to keep phrasing things in terms of user agent.

+1  I suppose they could DoS their own customers, or upcharge them or something.

And +1 to getting answers to the rest of DKG's questions.  In theory, this note shouldn't need any reply :)

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 21 Jan 2022 10:38:23 -0500

On Fri 2022-01-21 15:23:56 +0000, Salz, Rich wrote:
> Second, there is the history of poor behavior by some CA's, which
> leads to the primary user agent (browsers, or perhaps TLS runtimes)
> not being able to just completely trust them. Perhaps that historic
> era has passed, and it is time for user agents to end their probation
> of CA's? Not for me to say.

The argument of "we don't trust (some of) the CAs" is usually used to
mean "we are not willing to accept their cryptographic assertions of
identity in certain contexts".

But here, you're using it to mean "we are going to accept their
cryptographic assertions of identity even in contexts that they claim
are not valid".

This is a surprising inversion.

     --dkg

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Jan 2022 11:56:04 -0500

> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor <[email-masked]> wrote:
> 

CAA lookups must not softfail.  This needs to be the case whether the
domain is signed or not.  For signed domains this means that validation
of the response (positive or denial of existence) must succeed.  Bogus
replies, lame delegations, timeouts, REFUSED, SERVFAIL, ... need to all
be hard errors (for signed and unsigned domains alike).

-- 
	Viktor.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 21 Jan 2022 13:29:32 -0500

> the mechanisms we have available.

Indeed, I think the goal is admirable, but I'm not sure these technologies
are the right way to achieve this.

> and signed in the certificate, you're on your own.

There is an ample amount of information that CAs can put in certificates
which are not processed or are not relevant to achieving a particular goal.
The distinguished name is one such example (of having limited technical
value in practice, other than as an opaque ID), but equally, elements like
policy qualifications are another. In theory, systems could try to process
these, and there's no question that some non-Internet focused SDOs do try
to do this (e.g. the Qualified Certificate specifications and expressions),
but those are somewhat at odds with the goals mentioned in RFC 5280,
Section 2.3.

This may sound a bit abstract and wishy-washy, but my point is that not
everything a CA puts in a certificate is necessarily aligned in the
interests of relying parties, users, and server operators. If we had an
X.500 directory, in which the choice of a given PKI was an emergent
property discovered from The Directory, this is a non-issue for server
operators, because any server operator can simply declare a new set of CAs
for their organization. Similarly, in a model of DANE, in which DNS becomes
the source of truth for discovering who your chosen CA is, this is also a
non-issue. Yet in a model in which we work from common trust bundles,
including things like Qualified Trust Lists, there's an imbalance created,
and thus the ability to decline a CA that works against the server
operators interests is non-existent. All of the previous solutions equally
have issues for reflecting the end-users interests - if your DANE entry
uses RSA-1024 or expresses an authorization for an RSA-1024 bit key, that's
not necessarily aligned with end users/relying parties.

So the statement that "But once you're ignoring what the CA actually wrote
and signed in the certificate, you're on your own" is, I think, taking the
classic X.500 approach, that everything the CA asserts is of equal value
and merit, and if it wasn't, server operators would chose a different CA.
The reality we have is somewhat different, in which relying parties/end
users/user agents authorize CAs to make some assertions (e.g. domain
validation), but do not necessarily trust them or use other expressions. A
concrete example of this is Logotype, which is widely ignored.

> What kind of abuse are you anticipating here?  can you spell it out in

You may want to check the mozilla.dev.security.policy discussions going on
around the topic of revocation, as Mozilla tries to narrowly define the
scope of reasons that CAs use for certain types of revocation.

Concrete, real world examples we see in the Web PKI case:
1) If you get a single certificate from any other CA, we will revoke all of
your certificates.
2) If there is a business dispute, we will revoke your certificate.
3) If any entity claiming to be associated with any government or
regulatory body (even without evidence of association) claims we need to
revoke your certificate, we will revoke your certificate.
4) If any content posted on your website is something we disagree with, we
will revoke your certificate.
5) We do not "issue" certificates, we "rent" you certificates at a variable
monthly rate. If you fail to pay the increase / fail to maintain X
certificates with us, we will revoke all your certificates.

These are interests of revocation that may not be in the interests of
server operators or end users, but these are entirely understandable
positions that CAs may take. This is partly why the real world of
revocation is so complex, even setting aside the many technical issues. A
policy such as clients MUST support Must-Staple is an example of further
centralizing that control and (implicitly) power/privilege to the CA.

I recognize and agree that Section 4.2.3.1 of RFC 7633 lives a policy hole
you could drive a truck through, and that would easily be used to justify
the lack of implementation of a MUST today. So the MUST doesn't necessarily
add value here, other than elide the complexity of the space, and
disregards both the technical and policy tradeoffs that exist for why
clients have largely not yet adopted this.

> in the certificate is also incompatible with the noton of allowing

It's not clear to me if this is a rhetorical question, because it's not
clear how it follows from the previous remarks. Hopefully, the above
remarks clarify that the extent of expectation on the client needs to be
aligned with the degree of trust and delegation of certain actions to CAs,
and different actions (e.g. validation vs revocation) are not at all
created or treated equally.

Again, this is an artifact of the lack of a global directory (which allows
any CA, whether in long-existence or created seconds ago) to be used, and
the need for some degree of pre-provisioned distribution to be effectively
used. Because that selection is limited, and because all are functionally
equivalent, a greater degree of skepticism to the privileges afforded to
them is necessary.

> benefit from CRLSet distributions, but i'd love to be wrong.

Every browser has different priorities, recognizing the degree of deference
they give to CAs for certain actions. However, systems like Valid (Apple)
and CRLLite (Mozilla) do attempt to be more representative samples of the
set of certificates. There's significant debate as to the degree of
meaningful security, in a Web/HTTPS platform, that such systems provide,
but they are trying to provide more holistic datasets - albeit at
significant greater upfront cost to users. IIRC, it's ~50MB for Apple, ~1MB
for Mozilla, both of which are fairly prohibitive for mobile devices, but
still amortize better than a MUST of OCSP-Stapling, which simple back of
the napkin math against public statistics from browsers like Firefox show
would be massively cost-prohibitive in connection overheads.

> we urge the CAs to be more strict here?  Perhaps that would be another

I don't think that recommendation is germane for this discussion, at the
least. I think it's a broader policy question, and perhaps for a different
community, but I wanted to highlight it precisely because the conclusions
for this discussion somewhat rested upon it. I totally appreciate the
"chicken and egg" question here about which we fix first (similar to the
old DoH/DoT vs SNI), and I'm not trying to "whatabout" as a means of
delaying improvement, but it very much is a systems problem, and we need to
think about solutions as systems solutions, before trying to rush out
recommendations. That's why I think the OCSP question, broadly, is one that
isn't yet ready here.

> we want folks to be better protected against misissued certificates.

I think you're assuming that CAA is sufficient to prevent misissuance, but
it isn't. We continue to see examples of CAs who failed to do any
validation of domains or IPs, and even further, those CAs refusing to
revoke those certificates for weeks after the fact, because they didn't
think it was an issue. While mistakes happen, I think the assumption here
of CAA's value combined with Must-Staple, or OCSP in general, is
overstated, because it assumes a "well-behaved CA" as part of the threat
model. Both in terms of revocation, but also in issuance, we know mistakes
are regularly being made, and so the positive benefits here are overstated,
particularly under an adversarial model. An adversary who bypasses CAA both
bypasses the expressed desire for Must-Staple _and_ the restriction on who
the CA can be, thus providing no security benefit to the end user.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 21 Jan 2022 13:30:38 -0500

> be hard errors (for signed and unsigned domains alike).

Yes, and OCSP lookups must not softfail either, in order for them to be
useful.

Unfortunately, the real world is messy and complex, and the incentives for
getting to such a system for CAA are, unfortunately, greatly misaligned -
for CAs, but also for server operators and all the intermediaries along the
line.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 21 Jan 2022 14:15:03 -0500

>From where I sit, issuance is a much more critical process than
revocation, and sloppy practices should not be acceptable.  Postfix does
not ignore DNS lookup errors, and the sky has not fallen.  I don't see
why a CA should be at liberty to do so.

If some domain has broken DNS preventing certificate issuance, then they
need to fix that first.  Both the nameservers and the CA can be expected
to be on a better than hotel captive portal network, where DNS is
sufficiently reliable to return a valid answer, or be attended to if
there's a problem.

If CA/B Forum CAs are ignoring CAA lookup errors then the WebPKI is even
weaker than I thought it was.

-- 
    Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 21 Jan 2022 12:16:04 -0800

This discussion seems kind of out of scope for 7525-bis, which is about how
to use TLS, but doesn't seem to say much of anything in terms of how to
operate a CA.

The current draft seems not to say anything about what clients ought to do
and to say that servers SHOULD support OCSP and OCSP stapling (though the
citation to 6961 is weird because it seems to be referred to twice). My
sense is that it probably ought to say:

- Clients should have some mechanism for dealing with revocation, at least
in high value cases
  - For the reasons rsleevi indicates it may be desirable that it not be
totally unfiltered
  - None of the standardized mechanisms are acceptable here, OCSP for
privacy and performance reasons, and stapling for deployment reasons

- Servers SHOULD (MAY?) support stapling for clients which don't have
another mechanism, but shouldn't expect a lot of use.

This last seems a bit 6919ish, tbh.

-Ekr

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 21 Jan 2022 20:11:26 -0500

> be hard errors (for signed and unsigned domains alike).

fwiw, Let's Encrypt's ACME-compliant CA implementation "boulder"
apparently does not softfail for CAA validation:

   https://github.com/letsencrypt/boulder/issues/5903#issuecomment-1018932892

So there's at least one piece of good news in this thread.

   --dkg

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Jan 2022 10:30:54 +0000

Hi Yaron,

That’s exactly my worry. I have seen OCSP being proposed in EMU (with EAP-TLS) and also in IoT environments where it just don’t make a lot of sense to me. Hence, I would like to understand the motivation behind it and the use cases.

Ciao
Hannes

From: Yaron Sheffer <[email-masked]>
Sent: Thursday, January 20, 2022 3:18 PM
To: Hannes Tschofenig <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: OCSP in RFC7525bis

Hi Hannes,

Thanks,
                Yaron

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 20, 2022 at 12:00
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: OCSP in RFC7525bis
Hi Yaron,

Ciao
Hannes

From: TLS <[email-masked]<mailto:[email-masked]>> On Behalf Of Yaron Sheffer
Sent: Wednesday, January 19, 2022 3:57 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [TLS] OCSP in RFC7525bis

Hi,

Thanks,
                Peter, Thomas and Yaron

---

From: John Mattsson <[email-masked]>
Date: Mon, 24 Jan 2022 13:06:13 +0000

Hi,

In EMU WG there was a stong consensus to mandate revocation checking in EAP-TLS 1.3. Mandatory OCSP Stapling was suggested by someone as a way to achieve this. The transition from EAP-TLS 1.2 to EAP-TLS 1.3 made this possible. The mandatory to use OCSP Stapling was softened after comments from Hannes, which was good. I think the used mechanism should the choice of the application. I don't think there was much discussion regarding specific use cases. The current text is:

  "the revocation status of all the certificates in the certificate chains
   MUST be checked (except the trust anchor)."

  "EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
   Requests (OCSP stapling) as specified in [RFC6066] and
   Section 4.4.2.1 of [RFC8446].  It is RECOMMENDED that EAP-TLS peers
   and EAP-TLS servers use OCSP stapling"

You probably already know this but NIST has introduced strong requirements on OCSP for TLS:

  "TLS servers shall be configured with certificates issued by a CA that publishes revocation information in Online Certificate Status Protocol (OCSP) [63] responses."

  "The server shall support the use of the following TLS extensions.
   5. Certificate Status Request extension"

   https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf

3GPP has also introduces requirements on OCSP and OCSP stapling:

   OSCP should be supported by CAs and "Certificate Status Request" should be supported by TLS clients and servers.

   https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2279
   https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=2293

Both OCSP and OCSP Stapling are quite widely supported. According to Wikipedia, 16/18 TLS implementations support OCSP. One of the two lacking implementations is from Ericsson, but I know that both OCSP and OCSP Stapling is in actively development right now.

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
https://github.com/erlang/otp/tree/5b6931f001a00bff730867fdf07a8580eb989e24/lib/ssl

I think it makes sense to strengthen recommendations and requirements on revocation, OCSP, and OCSP stapling and align RFC7525bis more with NIST.SP.800-52r2.

I think the one omission in RFC7525 that should be fixed in RFC7525 is a recommendation to do revocation checking. I think that is the most important thing, not how the revocation checking is done.

I think another omission in RFC7525 that should be fixed in RFC7525 is a discussion on certificate life-times, which is often discussed together with revocation checking- Short-lived certificates is an improvement over long-lived certificates, but not at all a replacement for revocation checking.

Cheers,
John

From: Uta <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Date: Monday, 24 January 2022 at 11:32
To: Yaron Sheffer <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Uta] OCSP in RFC7525bis
Hi Yaron,

Ciao
Hannes

Hi Hannes,

Thanks,
                Yaron

Ciao
Hannes

Hi,

Thanks,
                Peter, Thomas and Yaron

[1] https://datatracker.ietf.org/doc/html/rfc7525#section-6.5
[2] https://github.com/yaronf/I-D/pull/279/files<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ec3c68b8ad6f51f9&q=1&e=e5bbdeed-379b-48d2-945b-0fb2813e9ffa&u=https%3A%2F%2Fgithub.com%2Fyaronf%2FI-D%2Fpull%2F279%2Ffiles>
[3] https://cbw.sh/static/pdf/chung-imc18.pdf<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a9bcddc9d2ae3288&q=1&e=e5bbdeed-379b-48d2-945b-0fb2813e9ffa&u=https%3A%2F%2Fcbw.sh%2Fstatic%2Fpdf%2Fchung-imc18.pdf>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 24 Jan 2022 11:18:13 -0500

On Mon 2022-01-24 13:06:13 +0000, John Mattsson wrote:
> I think another omission in RFC7525 that should be fixed in RFC7525 is
> a discussion on certificate life-times, which is often discussed
> together with revocation checking- Short-lived certificates is an
> improvement over long-lived certificates, but not at all a replacement
> for revocation checking.

This might be overstating the case a little bit.  If revocation checking
is done by OCSP stapling, then the OCSP validity window *is* in effect
the duration of a "short-lived certificate".  To the extent that a
short-lived certificate has the same validity period as an OCSP
response, it is indeed a replacement for revocation checking.

As an example, the validity window of the stapled OCSP response i see
according to the cert i get on port 443 of www.ietf.org has this
validity window:

		This Update: Fri Jan 21 01:21:02 UTC 2022
		Next Update: Fri Jan 28 00:36:02 UTC 2022

But when i query the OCSP responder directly i get this validity window:

		This Update: Mon Jan 24 01:21:00 UTC 2022
		Next Update: Mon Jan 31 00:36:00 UTC 2022

The week-long range is pretty comon, and a week-long certificate would
offer just as much protection against certificate misuse (an adversary
misusing a certificate with stapled OCSP could cache the last "good"
OCSP response and continue stapling it until it expires).

So unless "revocation checking" is defined to mean "out-of-band
confirmation with the issuing authority" (which would introduce both
latency and privacy concerns, so let's not go there), then a short-lived
certificate is indeed a replacement for revocation checking.

However, under the current certificate transparency regime, short-lived
certificates pose a challenge to CT logs, which scale with the number of
certificates issued over a given time period.  Replacing every 3-month
certificate with a corresponding number of 1-week certificates would
increase the size of CT logs by a factor of at least 12 -- probably
more, since certificates are generally issued with some overlap to
account for server-side work at cert transition and client-side clock
skew.

So, arguably, the advantage of revocation checking via OCSP stapling
over short-lived certificates today has to do with keeping CT logs a
manageable size, not with any particular security gain in terms of
revocation functionality.

        --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 24 Jan 2022 12:20:09 -0500

> revocation functionality.

Although I agree with your conclusion about equivalencies on revocation
being a function of the lifetime, an observation Dan Geer made 24 years ago
[1], a slight correction to the above remark.

This hasn't been a practical issue/concern for quite some time now,
especially with the adoption of "time-sharded" CT logs. The sharding
function of the logs can easily be adjusted to whatever target growth
function exists. That is, rather than sharding logs annually (where a log
only contains certificates expiring within a given calendrical year), it
could be sharded quarterly or semi-annually. Of course, modern logs are far
more scalable these days then original implementations, so even here, the
size of the log is more a function for monitors and auditors.

[1] https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html - Search
"Hence, a rule of thumb"

---

From: John Mattsson <[email-masked]>
Date: Tue, 25 Jan 2022 14:24:43 +0000

> This might be overstating the case a little bit.

Yes, I agree that “not at all” is overstating things. Revocation is a very complex issue, most absolute statements are probably wrong. “Not a replacement in general” might be a better formulation. It might be a replacement in some use cases, but these use cases would then have quite low requirements on revocation.

I agree that in your example, OCSP stapling with a week-long lifetime for the end-certificate only and a certificate with a week-long lifetime give exactly the same security. But

-                      Certificates with one-week lifetimes is not common and will maybe never be common. It also creates work for both the CA and the device. This is not practical for constrained IoT. CA systems in critical infrastructure often do not use OCSP at all due to the risk of denial-of-service attacks and rely purely on CRLs.

-                      The OCSP stapling example you give is a quite specific example (Web/HTTPS). The level of revocation checking in the example is quite low. For many current IPsec deployments, revocation checking is done daily or several times per day. (D)TLS is often replacing IPsec in virtualized environments. One week is quite a long time and in your example revocation checking is only done for the end-entity certificate. Some systems check the revocation status of all the certificates in the chain. In cases with fraudulently issues certificates, they are often used immediately and a week-long lifetimes  (certificates or OCSP responses does not help).

-                      And obviously short-term end-entity certificates do not protect against revoked intermediate or self-issued CA certificates.

John

From: Uta <[email-masked]> on behalf of Daniel Kahn Gillmor <[email-masked]>
Date: Monday, 24 January 2022 at 17:19
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [Uta] [TLS] OCSP in RFC7525bis

As an example, the validity window of the stapled OCSP response i see
according to the cert i get on port 443 of www.ietf.org<http://www.ietf.org> has this
validity window:

        --dkg

---

From: Hubert Kario <[email-masked]>
Date: Mon, 31 Jan 2022 18:08:51 +0100

On Friday, 21 January 2022 05:51:22 CET, Ryan Sleevi wrote:
>
>
> On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor 
> <[email-masked]> wrote:
> There are good reasons that clients have not, and potentially 
> will never, support Must-Staple, whether it be for the technical 
> reasons that many servers are unfit to support it, or for policy 
> reasons, such as wanting to be careful about the security 
> policies of their products, and how much of that is outsourced 
> to CAs. The choice about whether to require stapling or not _is_ 
> a policy decision relevant not only to server operators, but 
> also relying parties, and can be easily abused by CAs if given 
> that lever. Given the concerning practices already seen with 
> respect to revocation, which are detrimental to the security 
> goals of both server operators and end users, a full-throated 
> MUST seems a bit incompatible with the notion of allowing policy 
> flexibility. For example, in a world where a client delivers 
> revocation information out of band, as nearly every major web 
> browser does today (as one example), "must staple" is of 
> questionable benefit.

Browsers are the only software that use browser's implementation of 
certificate
verification and revocation.

And while they are significant users of TLS, they're definitely not the
only important users of TLS.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 31 Jan 2022 15:18:52 -0500

> only important users of TLS.

In the context of the thread, it’s hopefully clear I was not trying to
argue they are the only important user, but rather, a demonstration of a
practical alternative to deliver this information.

That said, on platforms like Apple’s *OS family (mac/i/tv), and, to a
lesser extent, Windows and Android, such distribution _is_ system wide, and
TLS-using applications, including non-browser, don’t need to take any
special action.

It’s really only in Linux that there isn’t some form of system-wide
capability available, and although Linux remains a significant in this
space, it shouldn’t be used to preclude more holistic approaches.