Re: [Uta] [TLS] OCSP in RFC7525bis
On Monday, 31 January 2022 21:18:52 CET, Ryan Sleevi wrote: On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote: 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. 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. I'm not aware of any OneCRL-like functionality in Windows... Do you have some pointers for that? Or are you talking just about the fact that Windows downloads and stores CRLs system wide? 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. The CA store used by OpenSSL as the -CAdir or X509_LOOKUP_hash_dir[1] can store CRLs too, making sort-of system-wide certificate revocation without need of OCSP possible too (NSS also supports a system-wide CRL store, I think only GnuTLS doesn't). 1 - https://www.openssl.org/docs/man1.1.1/man3/X509_load_cert_crl_file.html -- 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 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon, Jan 31, 2022 at 12:08 PM Hubert Kario wrote: > > 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. 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. > ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Friday, 21 January 2022 05:51:22 CET, Ryan Sleevi wrote: On Thu, Jan 20, 2022 at 10:31 PM Daniel Kahn Gillmor wrote: 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?) 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. 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 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis - summary of the discussion
> On 27 Jan 2022, at 4:45 pm, Yaron Sheffer wrote: > > So our plan moving forward is to essentially keep the new text on OCSP [1] > and add a reference to RFC 7633 (the certificate must-staple extension). But > only as a MAY. In addition, we will add a MUST requirement to perform (some > kind of) revocation checking. Usual lack of Internet Police noted, I feel I should mention that this "MUST" *will* be ignored in various quarters. I still have no plans to implement any revocation checks in Postfix, too much pain for too little (or no) gain. -- Viktor. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
> 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 on behalf of Daniel Kahn Gillmor Date: Monday, 24 January 2022 at 17:19 To: uta@ietf.org , t...@ietf.org Subject: Re: [Uta] [TLS] OCSP in RFC7525bis On Mon 2022-01-24 13:06:13 +, 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<http://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 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon, Jan 24, 2022 at 11:18 AM Daniel Kahn Gillmor wrote: > 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. 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" ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Mon 2022-01-24 13:06:13 +, 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 signature.asc Description: PGP signature ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Fri 2022-01-21 11:56:04 -0500, Viktor Dukhovni wrote: >> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor >> wrote: > >> 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. > > 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). 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 signature.asc Description: PGP signature ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
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 On Fri, Jan 21, 2022 at 10:31 AM Ryan Sleevi wrote: > > > On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni > wrote: > >> > 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. >> >> 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). >> > > 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. > ___ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Fri, Jan 21, 2022 at 01:30:38PM -0500, Ryan Sleevi wrote: > > > 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. > > > > 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). > > Yes, and OCSP lookups must not softfail either, in order for them to be > useful. >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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Fri, Jan 21, 2022 at 11:56 AM Viktor Dukhovni wrote: > > 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. > > 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). > 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
> On 21 Jan 2022, at 9:48 am, Daniel Kahn Gillmor > wrote: > >> 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. > > 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. 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
On Fri 2022-01-21 15:23:56 +, 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 signature.asc Description: PGP signature ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
>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. For that, you mainly want certificate transparency, no? > 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. 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 and signed in the certificate, you're on your own. 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. > 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? +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 :) ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
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 wrote: > Hi, > > 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. > > > 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 > > ___ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] [TLS] OCSP in RFC7525bis
Hi, > 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. > 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 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
