tl;dr: It's not this simple, and we should not try to use this draft to
specify padding policy.
below are some pointers about why it's not so simple. If you want to
make a separate draft about padding policy, i'm happy to have that
discussion there, but please don't hold this mechanism draft up for the
sake of policy discussion.
On Tue 2015-11-24 18:15:44 -0500, Mark Andrews wrote:
> Padding is there to make responses indistigishable from each other.
Padding for the sake of defeating traffic analysis is also about making
queries indistinguishable from each other, and about making combinations
of queries and responses indistinguishable from each other.
> For UDP pad to the requested UDP message size.
Traffic analysis countermeasures are only useful when the content is
encrypted. so presumably when you say "For UDP pad..." you mean for
DNS-over-DTLS? and "For TCP pad..." means for DNS-over-TLS? TLS and
DTLS themselves have per-message overhead, which itself may vary
depending on the ciphersuites used.
> For TCP pad to the largest response size sent so far.
Is that the largest repsonse ever sent by the server so far? or ever
sent by the server in the current TCP connection? or ever sent to the
specific IP address?
> This gives you roughly less than or bigger than 512, 12xx, 14xx and
> 4096 depending upon whether the query is retried over TCP or not
> and the requested EDNS UDP size.
enumerating the bins and anonymity sets is useful, but this breakdown
seems like it's missing request/response pairings and other kinds of
info leakage. I'd love to have a discussion about optimizing padding
policy for the sake of DNS privacy with this sort of explicit bin
enumeration and some attempts to categorize things with actual data from
actual DNS request patterns.
But discussion around this draft is not the place for it.
--dkg
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
