In late December 2016 an issue was raised on github that dnscrypt-proxy may raise the following warning:
The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.
Although it’s fine for the service to work and many other dnscrypt providers have long expiry too, the warning is a valid concern. I decided to change this behavior in DNSCrypt Poland.
We used to have a key valid for 5 years; starting today we now use keys rotating every 24 hours.
In a hypothetical case where the secret key was compromised by an adversary it would be possible to decrypt previously captured traffic. Now, the forward secrecy is better as the keys change frequently.
I suspect no issues, but as usual, please give me a shout on twitter or drop me a line if you encounter any issues.
Long Story
When DNSCrypt Poland was first established in 2013 it had a 1-year certificate. Close to the first expiry I recognized a problem of performing a smooth cutover to a new certificate. I contributed SO_REUSEPORT to dnscrypt-wrapper and libevent which allows to run many instances of dnscrypt-wrapper: one with the old and one with the new certificate.
Being lazy busy though, the next certificate I generated was a 5-year one. For it to work I contributed another patch and that allowed me to sleep tight for 3 years now.
Having changed the scheme to rotate every 24 hours, I can sleep ever better now :)
Technical Detail
Before:
- dnscrypt-wrapper instance is using manually generated keys and certificate
After:
- A new key is generated every 12 hours
- dnscrypt-wrapper picks up new keys and handles requests encrypted with old and new keys
- old keys are deleted
This means at any moment in time we have 2 keys generated within last 12 hours; after 24 hours there is a completely new set of keys. This allows to have key overlap for clients to continue working without glitches during the time they will retry if they are unable to fetch the certificate.