
DNSCrypt – how expired certificates became a thing of the past - dedalus
https://00f.net/2019/05/04/fixing-expired-certificates/
======
Dylan16807
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.

~~~
vbezhenar
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.

~~~
cbsks
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.

~~~
vbezhenar
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.

------
oil25
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.

~~~
jedisct1
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.

~~~
oil25
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.

~~~
jedisct1
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](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.

------
geofft
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.

~~~
scrollaway
> _certificates need to expire while the original person deploying the system
> is still working on it._

This seems really arbitrary. Elaborate?

~~~
geofft
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.

