Adguardhome: Change keys rotation period to 24 hours

[sergeevabc]

dnscrypt-proxy[1804]: Chosen certificate #147307**** is valid from [2016-09-05] to [2017-09-05]
dnscrypt-proxy[1804]: The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.

Please, make keys rotation happen every 12 or 24 hours, not every year like it is now.

[vozersky]

definitely makes sense

[sergeevabc]

Dear @ameshkov, issue seems quite simple to implement (how1, how2), what’s your ETA?

[ameshkov]

@sergeevabc the task itself is not hard, but it's not that simple when you have 12 different servers.

[ameshkov]

I'll give you an ETA once we sit and discuss the next dev iteration with the team, sorry for the delay.

[xdel]

I think that we would roll out 24hr key rotation this day or tomorrow, The certificate validity period will be still larger than 1d though.

[nkartyshov]

done

[sergeevabc]

dnscrypt-proxy[1658]: Chosen certificate #150489**** is valid from [2017-09-08] to [2017-09-15]
dnscrypt-proxy[1658]: The key rotation period for this server may exceed the recommended value. This is bad for forward secrecy.

Done? Point was to align DNSCrypt server configuration with the officially recommended values, i.e. to make forward secrecy truly work as expected. So far you reduced certificate’s validity period from 1 year to 1 week, which means a user will not get a fresh certificate sooner until reconnects manually. Why trade this for that when things stay bad from security point? You could just tell us to drop connection every 24 hours via cron job in the first place or to look for some security-wise provider.

[xdel]

The validity period stays by one week. Key rotation is working daily, replacing old server certificate and allowing clients to stay within established session for one hour using earlier certificate to avoid forced re-connections, as this is not certainly well handled by standard client. Sorry to say that, but these recommendations are somewhat BS, we don't expect all upstream answers being verified through DNSSEC or alternate mechanism which ensures PFS in place. For what we've got there, DNSCrypt works exactly under the case what it supposed to cover - prevent last-mile request monitoring and alteration. While it could be agreeable that a year span could somewhat impact the secrecy, talking about theoretical available computing power on the planet, the difference between one day and one week is negligible and there is much more side channels to leak or alter, unfortunately. Please steer this discussion through things which are less tangent to a real security matters :)

[ameshkov]

Guys, I might've missed something, but am I right that the only thing you have an argument over is the cert validity period? 1 week or 1 day?

[sergeevabc]

Dear @jedisct1, the very developer of DNSCrypt, could you be so kind to explain why you recommend using short time period of certificate validity (1 day or less)? @xdel believes it is “somewhat bullshit”.

[xdel]

Please refer to known complexity values for xsalsa20 and xchacha instead of asking others about the point you are referring to, this is immature. By the way, at least first is quite susceptible to PRNG quality, so the reference to a VPS-based service just above could compare just matching key predictability for different validity period (we are using Vultr too for this service and they certainly do not pass host entropy-collection device). There`s simple not enough DNS queries in the world for all validity periods being discussed to weaken client-server transmission in a case we are discussing. Again, please steer the discussion in the way which could be more fruitful as we spent already two replies discussing single define of a single hash function with supposedly known complexity level.

[ameshkov]

@xdel please, keep the discussion respectful, your arguments might be valid, but the manner is unacceptable.

[jedisct1]

family.ns1.adguard.com -> TTL = 720 days
default.ns1.adguard.com -> TTL = 720 days

Hardly fixed.

[ameshkov]

Guys, I am sorry that I didn't report back.

We've tried to rotate it daily for some time but ran into some really weird issues on mobile devices. Every time the key was rotated, dnscrypt-proxy stopped working until it's restarted. Nothing helpful in the log. At the same time, there were no issues on desktop :(

So we decided to disable rotation for now and return it back when we test it thoroughly with dnscrypt-proxy v2.

[ameshkov]

Oh, one more thing. This was a client-side issue as we've reproduced it with multiple resolvers, not just with AG DNS.