[getdns-users] privacy work on getdns at the IETF 94 Hackathon

[Daniel Kahn Gillmor]

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://lists.getdnsapi.net/pipermail/users/attachments/20151101/cc29a6e3/attachment.bin>