Hacker News Reader

Comment by tptacek | Hacker News Reader

What other mainstream browser are you counting on to ever support DANE?

I feel like this comment ignores the fact that right now all of them are effectively tied to Google, and that supporting DANE if Google doesn't is currently pointless, so obviously no one would until the status quo changes.

Ultimately the problem is that currently "security best practice" as it's commonly discussed, says what we're doing now is a good idea. It's not, and until we change the understanding on that, nobody's going to feel motivated to do better.

Password rotation used to be considered a gold standard strategy for security, until people realized not only did it make everything harder, it also encouraged people to choose less secure passwords and was largely self-defeating.

If I told you we could improve a 90-day password rotation policy by making it change every week, you'd rightly call me crazy, but for some inconceivable reason (monopoly, perverse incentives, appeal to an authority run by idiots, name your choice), people act like decreasing certificate lifetime is somehow going to make the web safer.

Decreasing certificate lifetime addresses a totally different problem than password rotation.

Why do you think so? A certificate is essentially a password that proves your identity and rotating it faster is to ensure it stops doing that if someone steals your password.

Short certificate lifetimes address the fact that TLS certificate revocation doesn't work. Password rotation --- which is no longer a NIST recommendation! --- addresses the concern that long-term secrets eventually leak. You can intuitively see how different the problem domains are from the fact that certificate lifetimes are far shorter than even the old NIST password rotation rules were, despite the fact that certificates are all stored securely relative to passwords.

But whether that's intuitive for you or not, the fact remains: short-lifetime automated certificate provisioning is a response to revocation.

I do see your position re: passwords tend to successfully be canceled and certificates tend to not. But I would certainly argue that the downsides of rotation on user behavior and technical security design are quite costly. They remove a lot of the opportunity for risk-based authentication (like TOFU) and require people set up fragile automations capable of generating keys that claim to be them. And every certificate warning that isn't due to a real security problem creates alert fatigue that makes certificate errors seen as spurious.

I think short certificate lifetimes will be viewed in the relatively short future as misguided as the old NIST recommendation on passwords.

We have short lifetimes because TLS revocation doesn't work. It's that simple.

To understand the distinction, imagine a password system where you can't change your password. You can make new ones, but the old ones still work. That's the problem TLS was facing.

Even granting that, it's still both an ineffective fix and it introduces significantly worse security risks than it tries to mitigate, on a system that at its core is fundamentally bad.

PKI is structurally broken at every level. The reason there are so many changes and additions and new features being slapped on it, is because it's a really dumb system and the people who control it are very motivated to keep it in place at the expense of everything else.

No, it doesn't.

Not quite that simple, no. It's a good reason, and while CRL and OCSP don't really work well - CRLite/OneCRL, CRLsets and valid all go some way to making revocation reasonably effective. Having an effective way to rotate all certificates, quickly, is a bigger reason. 1k -> 2k RSA took too long. SHA1 -> SHA2 took waaaaay too long. Changing anything about the webPKI takes too long unless everyone is on short lifetimes. The post-quantum bogeyman looms, too. Heartbleed and unforced CA errors become way less of a problem is everyone is forced to rotate monthly.

Fair enough (I knew someone was going to come in here and whack me on this). I'd only say that this makes the overall argument for short-lifetime certs even stronger. :)

…and I didn’t even have to play the SC-081 sponsor card either ;)

> Password rotation used to be considered a gold standard strategy for security, until people realized not only did it make everything harder, it also encouraged people to choose less secure passwords and was largely self-defeating.

Even if we ignore the fact that certificates are not a secret, and that expiry applies to certificates, not private keys, a major difference is that humans don’t mentally generate or manually type TLS keys or certificates. So the negative impact of rotation on user experience and behavior is entirely absent.

I was drastically oversimplifying by calling certificates a password. But the point actually does definitely stand: In the long-lived certificate days, you'd keep your CAs and such offline, and generally speaking, highly secured. Now you have to give your automations everywhere everything they need to constantly generate keys that claim to be your site. People are pushed to make drastically less secure choices about how they generate certificates because it needs to happen so often. A lot like adding a 1 on your last password. ;)

Also, short lifetime certificates help deprogram concern about certificate warnings (most nontechnical users know to ignore them, as a network admin, I've never seen a certificate warning that was actually due to a compromise... so I also ignore them all), which leads to hypothetically much less safe behavior than if certificate warnings only happened when rational.

Which is to say, if you believe a certificate that expired yesterday should result in a scare screen to users or worse with HSTS, interfering with the ability to access it all, you failed security 101.

Reply on news.ycombinator.com