Bug 1440 - [dnscrypt] client nonce cache
[dnscrypt] client nonce cache
Product: unbound
Classification: Unclassified
Component: server
Other All
: P5 enhancement
Assigned To: unbound team
Depends on:
  Show dependency treegraph
Reported: 2017-09-12 07:42 CEST by Manu Bretelle
Modified: 2017-09-19 02:17 CEST (History)
2 users (show)

See Also:

nonce cache (31.74 KB, patch)
2017-09-12 07:42 CEST, Manu Bretelle
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Manu Bretelle 2017-09-12 07:42:27 CEST
Created attachment 454 [details]
nonce cache

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.
Comment 1 Wouter Wijngaards 2017-09-18 10:56:03 CEST
Hi Manu,

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
Comment 2 Manu Bretelle 2017-09-19 02:17:30 CEST
Thanks Wouter.