Bugzilla – Bug 1440
[dnscrypt] client nonce cache
Last modified: 2017-09-19 02:17:30 CEST
Created attachment 454 [details]
In order to avoid dnscrypt queries replay attack, we need to keep track of each individual client nonce. The client nonce is unique for each client pk/resolver sk (on resolver side).
<client-nonce> ::= a unique query identifier for a given
(<client-sk>, <resolver-pk>) tuple. The same query sent twice for the same
(<client-sk>, <resolver-pk>) tuple must use two distinct <client-nonce>
values. The length of <client-nonce> depends on the chosen encryption
The idea is to use a LRU to protect against a replay attack which will basically involve a lot of similar queries within a short time frame. In case of an attack, the LRU will keep the tuple in the cache.
The attached patch comes with 5 individual patches:
[PATCH 1/5] [dnscrypt] add dnscrypt nonce cache: Adds the actual nonce cache logic, data structure, inserting/comparing/deleting....
[PATCH 2/5] [dnscrypt] Add nonce cache size configuration options: Adds config options
[PATCH 3/5] [dnscrypt] Add nonce cache stats: Adds stats for the cache size.
[PATCH 4/5] [dnscrypt] add replay counter: cache hits to better understand how much replay is happening.
[PATCH 5/5] [dnscrypt[ update unbound-control man pages with dnscrypt: This adds the different stats generated by dnscrypt to unbound-control man page.
Instead of using client nonce/client pk/resolver sk as a key, we use client nonce/client pk/client magic. The client magic is unique for each certificate, we can have multiple certificate for a given server key pair (xsalsa20 and xchacha20), but in practice, a given client will use 1 encryption standard at any given time so we are better of storing client magic (8 bytes) vs resolver secret key (32 bytes).
I have attached the patch in 1 serie of patches in 1 file. I can submit it in multiple files (1 for each diff) if needed.
Thanks! I have committed the patch (for 1.6.7, 1.6.6 was in rc freeze and now out the door).
Best regards, Wouter