On Wed, Jan 19, 2022 at 6:57 AM Yaron Sheffer <yaronf.i...@gmail.com> 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. I don't know what non-browser implementations do. > 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.) > > 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 > > > > 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 > > > _______________________________________________ > Uta mailing list > u...@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
