On Thu, 16 Apr 2020 13:56:34 +0100 Neil Dunbar via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote: > For the avoidance of doubt (and my own poor brain) - does 'GOOD' here > mean OCSP status code 'successful' (0) AND returning a 'good' status > for the certificate, or does it just mean status code 'successful'? > The GTS case here was returning OCSP exception status 'unauthorized' > (6). GOOD means _at least_ the good CertStatus (also 0) in OCSP. We'll see why in a moment. Ryan provides a considerably longer list of stupid things that might go wrong in item (2) from https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 You should consider all of them reasons the answer shouldn't replace an existing GOOD answer you have. > I would have thought that an OCSP-stapling implementation which got > an OCSP status code 'successful' (0) with a 'revoked' status for the > certificate would want to pass that on to the client, replacing any > prior OCSP successful/status-good report, whether that prior report > was still valid. But why? We are us, why would we want to announce that our certificate is revoked? What possible benefit could accrue to us from choosing to do this? Remember we cannot choose the behaviour of an adversary. So if we choose to tell clients our certificate is revoked, but an adversary asserts their copy is still good, clients will continue to talk to the adversary which is almost certainly a worse outcome. If your model of TLS still looks like early SSL, with implicit RSA authentication then I can see that if you squint advertising your own revocation isn't completely stupid. Maybe the revocation means an adversary knows our private key, and so in continuing to talk to clients with this key we make things worse, we should admit it's revoked instead. I'd argue that if this was a scenario you care about the right thing is for the server to shut down instead, not staple revoked responses. But anyway sites which actually care about security should never use implicit authentication (and it doesn't exist in TLS 1.3). As a result there is zero risk from pressing on, you are definitely you, the only question is whether you can continue to convince clients that this is so, and stapling a non-GOOD answer will never help you do that so it's never the correct thing to do. Nick. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
