Padding strategy for DNSCrypt

[msoxzw]

Initially, I found that the "dnscrypt-proxy" consistently sends 1252 bytes UDP packet to the IPv6 DNSCrypt server, e.g. adguard-dns-ipv6. The 1252 bytes, I guess, is based on an MTU of 1280, which is required by the IPv6 specification, minus 20 bytes for the IPv4 header and 8 bytes for the UDP header. However, the size of IPv6 header is 40 bytes, and hence, 1232 bytes UDP packet should be sent on the IPv6 network link.

Furthermore, I am curious about whether DNSCrypt is designed for traffic analysis resistance. The fixed-length or maximal-length padding that DNSCrypt seems to use are not recommended by RFC 8467.

[jedisct1]

As documented in the the relevant specification, response can be sent over UDP only if its size is less or equal to the question size. This prevents amplification attacks.

dnscrypt-proxy uses 512 bytes as a starting point for the question size, and will then gradually adjust this in order to avoid retries or having to use TCP. Padding size of individual queries is randomized, with a maximum overhead of 256 bytes and a block size of 64 bytes.

The padding of responses use a pseudorandom function to be deterministic for a given nonce. The same question asked multiple times by a genuine client may return responses whose size differs to mitigate correlation, but replay attacks won't allow statistical analysis.

[msoxzw]

@jedisct1 Thanks for your detailed explanation.
Moreover, I have confirmed that my IPv6 network can transmit 1444 bytes UDP packet to adguard-dns-ipv6 2a10:50c0::ad1:ff without IP fragmentation (1500 (Standard Ethernet MTU) - 8 (PPPoE header) - 40 (IPv6 header) - 8 (UDP header) = 1444), but still I do not figure out why dnscrypt-proxy chooses 1252 bytes rather than 1232 bytes or 1444 bytes. Would you mind enlightening me further?

[lifenjoiner]

DNSCrypt is not EDNS. It is a total encryption of the original query, a new layer, having its own padding strategy. The total length is changing to defeat statistical analysis.
The original query may have its own padding, if it is ENDS.

[msoxzw]

The original query that I send is just plain DNS query without EDNS.

[msoxzw]

I feel that I find the reason why dnscrypt-proxy consistently sends 1252 bytes UDP packet:

dnscrypt-proxy/ChangeLog

Lines 283 to 285 in dc2fff0

	- Responses sent to the local network are assumed to support at least
	1252 bytes packets, and use optional information from EDNS up to 4096
	bytes. This also reduces latency.

dnscrypt-proxy/dnscrypt-proxy/common.go

Line 37 in dc2fff0

MaxDNSUDPSafePacketSize = 1252

Accordingly, in my understanding, dnscrypt-proxy may not adjust packet size unless EDNS buffer size from server is larger than 1252 bytes. Unfortunately, since DNS Flag Day 2020, DNS servers and DNS software have increasingly adopt 1232 bytes EDNS buffer size, so dnscrypt-proxy does not further tune DNS packet size.

Additionally, according to the Cloudflare experiments, the default 1252 bytes UDP packet is probably not suitable for 1280 MTU IPv6 network, e.g. AS6830, AS20825, AS31334, and AS29562. Combined with DNS XL, DNS 2XL, and DNS Flag Day 2020 from APNIC labs, the dnscrypt-proxy, I suggest, could use Path MTU Discovery to determine optimal UDP packet size, just like many QUIC implementations, e.g. MsQuic, Neqo, ngtcp2, QUICHE, quic-go, Quinn, and etc.. Likewise, some techniques used in these QUIC implementations, I believe, could benefit both dnscrypt clients and servers.