~nickbp 3 years ago

This should be easier under the current structure (especially now that flatbuffers are finally gone) but this probably isn't that critical in terms of how many clients actually use or enforce this.

~nickbp added Low Priority 3 years ago

~nickbp added Security 3 years ago

~nickbp 2 years ago

Thinking it'd make sense to get this off the list, there's been similar support added for EDNS PADDING recently in the DoT/DoH clients and this isn't too different from that. There's server and client halves that would behave a bit differently:

Server:

• After testing some queries in dig, it looks like at least both UDP and TCP queries will include a client cookie, so we may as well implement server-side support for both of those.
• sha256 of concatenated clientip+clientcookie+secretdata, then truncate the hash from 32 bytes to 8 bytes (ref https://www.rfc-editor.org/rfc/rfc7873.html#appendix-B)
• The server randdata is tricky in HA situations. By default can generate a random secret on startup, then allow override with a secret provided via envvar. The same secret would be shared for both UDP and TCP endpoints.
• When generating the server secret, could give an informational message if starting in a docker container and no secret is provided via env (using a hint envvar added to our Dockerfile)

Client:

• I imagine it doesn't hurt to just include support in all of the clients (UDP/TCP/DoT/DoH), where each one would have its own cached client secret and server key pair
• sha256 of concatenated clientip+serverip/serverhost+randdata then truncate the hash from 32 bytes to 8 bytes (ref https://www.rfc-editor.org/rfc/rfc7873.html#appendix-A)
• The client randdata could be fully randomized and generated per client object

~nickbp 2 years ago

Can exercise via dig with the +cookie=value/+nocokie options, or maybe with +ednsopt=COOKIE[:value]