DNSCrypt – how expired certificates became a thing of the past | Hacker News Reader

DNSCrypt – how expired certificates became a thing of the past

00f.net

97 pointsdedalus13 comments

So this solves a problem with intermediate certificates expiring, but the scope is pretty narrow.

There are two types of key here, a "provider public key" and a "resolver public key". The provider key signs the resolver key which signs the requests. This is a system to keep the resolver key from having problems. If you're a website, this is basically irrelevant, because you do the equivalent of having the provider key sign requests. You have no intermediate to worry about at all.

But what if you're Mozilla, and you do have a problem with intermediates expiring?

Well if you put this directly into place everything would get much worse. Extensions would expire after a few hours.

You would have to change your validation logic, to accept signatures that were made while the intermediate was valid, even though the intermediate has expired. (You could set a 12 month limit to make this no less secure than the old system.)

But... if you did this validation change, that would have prevented the extension problem in the first place, all by itself!

This system of short-lived intermediates is nice, but it's way more important in its original home. For extension signing it would almost only be a convenience.

IMO there should be a system for soft-expire. For example browser should issue alerts when website uses a certificate that is about to expire soon (less than 10% of its life, for example). Of course it's expected that website owner replaces certificate before that happens, but even in that case site still works with a slightly degraded UI, so visitors could reach site owner and tell him that something wrong. Similar system could be used with Firefox extension system as well. Probably any user would prefer one alert rather than having all his extensions disabled.

yes, opt-out warn user ahead of time of certificate expiration.

This! Certificate expiry is mostly an UX problem. While expiration is needed, the first step should be a warning, not cancellation of service. Imagine if your car simply didn't start when you crossed the service interval, instead of just annoying you with a warning.

I don't mind so much that Mozilla let their cert expire, but I'm pretty angry that I couldn't just click somewhere to dismiss the warning. Of course, I'm talking just about expired certificates, revoked ones are a different story.

What is my grandmother going to do with that information? She doesn’t know what a certificate is, only that her bank is giving her some warning. Users don’t need this warning, developers do.

She might call her bank and ask. Now bank will know that something is not quite right. There’s no way to distinguish developer from user. But yeah if user opened developer console in his life, you might treat him differently. That’s one possible approach I guess.

I've used DNSCrypt for some time and think it's great software, however I disagree with the author's position it makes certificate expiration a thing of the past. Setting a short expiry and automation for renewal is optional - and I strongly believe optional security is irrelevant. If certificates have a good reason to expire after 24 hours, or sooner, the software should guarantee it AND provide the automation tooling required to update it. Relying on the user to be informed and act accordingly is not a valid strategy.

The specification says that resolvers MUST rotate the short-term key pair every 24 hours at most. This is not optional.

Automation tooling to update the certificates is provided. The Docker image that a lot of people use to run servers does this automatically. Keys are rotated every 8 hour.

The client software issues warnings, but tolerates certificates having a time-to-live longer than 24 hours. Not all DNS operators have shifted to short-lived certificates yet, so being tolerant is a reasonable thing to do.

I don't use Docker; I run dnscrypt-wrapper on my own server and clients connect to it using your dnscrypt-proxy software. Please pardon my ignorance, but how would you propose automating key rotation in this circumstance (assuming the key is "sdns://...")? Right now it's an involved process of interactively logging in weekly to generate the keys and copy-paste the value into the dnscrypt-proxy.toml configuration file - for each client! I'm probably missing something obvious. Thank you for your work and reply.

The DNS stamp (the sdns: address that clients use) doesn't have to change. That wouldn't be very practical :)

See the documentation of dnscrypt-wrapper: https://github.com/cofyc/dnscrypt-wrapper

Two kind of keys are involved: a long-term key ("provider key", used for signatures), and ephemeral keys (used for encryption, and signed by the long-term key).

Clients only need the public long-term key, which is included in the DNS stamp.

What you are rotating is just the ephemeral key pair (`--gen-crypt-keypair`).

This is similar to what happens to TLS certificates: you can update the certificate for a domain name as frequently as needed. But you don't need to install a new version of the operating system every time somebody adds or changes a certificate for their website.

dnscrypt-wrapper can serve multiple certificates simultaneously, so you can serve the next certificate even if the current one hasn't expired yet.

The real rule, it seems to me, is that certificates need to expire while the original person deploying the system is still working on it. So that's a measure in terms of the speed of businesses, not any fundamental constant. A year is far too long: people transfer, reorgs happen, etc. Let's Encrypt's three months is a bit too long, I think; it's exactly one quarter, and things tend to change at the quarterly level. You could deploy something and be gone from the project by the time it expires. But anywhere from hours to weeks should be fine.

> certificates need to expire while the original person deploying the system is still working on it.

This seems really arbitrary. Elaborate?

First, it's a lot more robust for the system to be initially designed to support certificate renewal than to figure it out later, usually because "later" means "after it expires." That might either be going through the exercise of renewing certificates by hand or setting up automation. If the system is already in maintenance mode / "legacy", and you don't have a process for renewing certificates, you're at higher danger of missing it.

Also, the person designing the system is evaluated on it working. If it breaks while it's on their watch, it counts against them; if it breaks while on someone else's watch, standard performance review practices are generally unreliable at making it count against them even if it really ought to. Therefore, if you assume standard performance review practices (which is the right way to model incentives for present-day developers/deployers working for for-profit companies, and because of the massive influence of for-profit companies, not a wrong way to model social incentives for everyone else), you want to incentivize them to make renewal part of the system, again either via automation or documentation.

Reply on news.ycombinator.com