[Godel_unicode]

You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.).

Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.

Boom, as the kids are saying.

[pfg]

> You might want to re-read my post more carefully, there is not necessarily an attacker per-se in an availability incident (although there certainly could be. Depends on how evil one wants to think.).

Well, that was the context of this thread. Both the OP and konklone are talking about attack surface. If you want to talk about how running a service via TLS and using HSTS makes HA harder, that's a different discussion.

> Backhoe eats the fiber to the ocsp responder and CRL distribution point, CRLs timeout after 24 hours.

OCSP and CRL is soft-fail by default in all browser I'm aware of. The server is also in control of it via OCSP Stapling, so it has all the tools it needs to keep the server available, assuming proper configuration and monitoring (which is true for a HTTP service as well).

[Godel_unicode]

Is the backhoe/squirrel/hurricane an attacker thus making this an "attack"? Semantics. Availability is part of the attack _surface_, which if we're being pedantic is what was being discussed. ("Look at the shiny new attack surface!")

> different discussion

My point is that, no, it's not. The three points of the triad are inextricably linked. More C and/or I means less A (and A tends to be sidelined in favor of C and I these days).

> OCSP and CRL is soft-fail by default in all browser I'm aware of.

Not on government systems they aren't (STIG id: v-44789). Also, if we're going all in on https we should go all in on https.

> ... Stapling

How is the server supposed to get a response to staple if the responder is unavailable?

Also, time. Also, client root of trust. Also, fat-fingering the hostname when the DNS gets updated. Also, public wifi which does mitm...

Bottom line: this is a decision which prioritizes confidentiality and integrity over availability for the entire .gov with (seemingly) no recourse.

Edit: quote from upstream, corrected STIG id

[konklone]

To quote my comment from above - bear in mind that when it comes to plain HTTP, it's not just the system's confidentiality and integrity that you need to weigh against availability: it's the user's confidentiality and integrity.

That's a larger moral responsibility, in my opinion. And consider that the fallback to prioritize availability in case of a non-attack cert error (e.g. revocation or expiration) is to ask the user to look at a certificate warning and make a personal trust decision about it. There are precious few users who can safely make that kind of a decision. And even if they "get it right" that time and click through and aren't attacked, you're training users to click through warnings, and helping them subject themselves to attacks in the future.

I would argue that that kind of "availability" is a very weak sort of availability. The government has enough problems with training people to click through certificate warnings (see: https://www.iad.gov) -- intentionally leaving that hole open seems unwise.

[pfg]

> Not on government systems they aren't (STIG id: v-44789). Also, if we're going all in on https we should go all in on https.

I found this description: "By setting this policy to true, the previous behavior is restored and online OCSP/CRL checks will be performed. If the policy is not set, or is set to false, then Chrome will not perform online revocation checks. [...]"

This seems to address the fact that Chrome does not perform OCSP queries at all, instead relying on its CRLSets. However, even back when Chrome did OCSP queries, it was soft-fail (as is every other browser). The "previous behavior" would thus be to query OCSP, but fail silently anyway.

> How is the server supposed to get a response to staple if the responder is unavailable?

OCSP responses from publicly-trusted CAs are typically valid for 10 days, and they're updated at least once every 4 days (IIRC). That'll leave 6 days for the responder to come back online in the worst case (or 6 days to tell everyone about "badidea" in case the CA is nuked from orbit, along with any other publicly-trusted CA the site might switch to). (Let's not forget it's soft-fail, so this is just a theoretical exercise).

> Bottom line: this is a decision which prioritizes confidentiality and integrity over availability for the entire .gov with (seemingly) no recourse.

I'll give you that. I just don't think the availability concerns are bad enough to outweigh the benefits, and they can be mitigated in just about any scenario.