[getdns-users] privacy work on getdns at the IETF 94 Hackathon
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Sun Nov 1 08:26:55 CET 2015
Hi GetDNS folks--
several of us did work on GetDNS at the IETF 94 hackathon. I focused on
DNS privacy. I've pushed a patch queue here:
https://github.com/getdnsapi/getdns/pull/118
This implements two new policies that can be set on the getdns_context
object:
client_subnet_private:
Background:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-client-subnet-04
defines a way for recursive resolvers to report their client's IP
addresses to the authoritative server. This is a privacy concern,
because clients might not want their IP addresses to be revealed to
the authoritative resolver.
If client_subnet_private is turned on while a getdns_context is in
stub mode, it will, ask its upstream resolver to not reveal
anything about the stub's IP address to the authoritative.
tls_query_padding_blocksize:
Background:
https://tools.ietf.org/html/draft-mayrhofer-edns0-padding-01
Doing DNS queries over TLS still leaks the size of the query itself.
This means, for example, that if i query for cats.example, it will
be 3 octets shorter than a query for kittens.example. This leaks
information that can be combined with other information to reveal
the actual queries sent.
I implemented a simple policy to have getdns pad all queries to a
multiple of a desired size (the TLS and TCP and IP and L1 overhead
is not included in this measurement).
As a demonstration, i used this to query 185.49.141.38 for both
"example.com" and "www.example.com".
The ethernet frame size for each query based on different transports
is shown in the table below:
Transport | example.com | www.example.com
--------------------------+--------------+-------------------
cleartext UDP | 82 octets | 86 octets
cleartext TCP | 108 octets | 112 octets
TLS over TCP | 137 octets | 141 octets
padded(512) TLS over TCP | 609 octets | 609 octets
This doesn't solve all the leakage, of course (e.g. the responses
aren't being padded). And it's not clear that this policy (pad to a
multiple of K octets ignoring TLS and TCP and IP and L1 overhead) is
the best padding policy. I welcome suggestions for better padding
policies.
Note: i randomly chose an arbitrary value for the option here out of
the Local and Experimental space. It'd be great if we could get
a normal option value assigned.
I'd be happy to hear any feedback about these changes.
--dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: <http://getdnsapi.net/pipermail/users/attachments/20151101/cc29a6e3/attachment.bin>
More information about the Users
mailing list