[dns-privacy] Overview of DNS privacy and encryption proposals

["W.C.A. Wijngaards" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi dns-privacy,

Tried to find the proposals I could, may have missed some.  First some
considerations for comparison.  Then text about key distribution.
Then proposals briefly characterised.

Crypto
encryption of the payload, this is the main goal.
opportunistic versus authentication of the server:
- - withstand active intrusion
- - withstand passive intrusion
- - authentication of the server
- - authentication of the client is also an option.
- - algorithm agility.
- - type of algorithm (RSA, EC, ..) in first proposal, descriptive.

Transport, Encoding
- - stub-cache, recursor-authority path is secured.
- - UDP, TCP, what transport needs and supports
- - TLS usage, X509 usage
- - in what sort of format is the DNS data engulfed
- - size of the packets

Speed
- - Efficiency of the crypto itself
- - Roundtrips for first query
- - stateless operation costs (mostly in time)
- - Roundtrips for 'established connection'
- - statefulness costs (mostly in resources)

Misc
- - Does it solve reflection.
- - Backwards compatible?  With downgrade? (nice for deployment, but
understandably bad against active intrusion).
- - How is it signalled?  I.e. how does the client know the technology
is used, and similar for the server (if signalling to the server is
needed).

Key distribution options
Mostly the different options can combine with many of these, thus this
issue can be looked at orthogonally from the others.
- - preconfigure keys (does not scale, perhaps ISPs, but even then),
  possibly enterprise scenarios.
- - webtrust PKI with x509
  - perhaps good for caches (you connect to random caches anyway, it
    needs to establish its identity somehow?)
- - code key values in names of nameservers.
  get key in referral is efficient
  name of nameserver is not signed by the parent server, thus downgrade.
- - DANE with DNSSEC (recursion are us), using DNSSEC root keys.
  - for authorities
  - the authority server may serve signed zones anyway, but
    problematically that zone's name is what we are trying to protect.
  - DANE with reverse lookup of server's IP address.  Must be a public
    IP address to have a chain of trust, thus for authorities.
    Issue that glue is not signed, and thus a fake downgrade can be
    accomplished with a fake IP address in glue (and then bogus DNSSEC
    information later, but the encryption and privacy downgrade is a
    success).
  - abuse new DS fake-hash-type for carrying the encryption keys, this
    is like dnscurve, but then with DS have algorithm agility and
    larger sizes.
    makes referrals larger.
- - get key via new DHCP option.
  - shared fate with the nameserver's contact information for caches
- - Opportunistic exchange
  - as part of TLS, dTLS, .. other mechanisms: just believe the key that
    was presented.  This is similar to other opportunistic key
    exchanges.
    Unauthenticated key can then be used for encryption, but the server
    or client does not know to whom.
  - downgrade.
- - Client authentication?  X509 and webtrust PKI?  Clients do not have
  DANE,
  can only assert themselves.  Clients could have username/password and
  somehow present that (i.e. password has nonce appended and hashed).
  Keeping the username safe requires an extra roundtrip, do it after the
  server has been authenticated to avoid exposing user identity to
  others.


Noncrypto proposals
qname minimisation: only send part of the query name to servers, not the
whole name.  Major revision of the lookup process.  No actual
encryption, but good for privacy (somewhat).  Towards authorities
only.  A similar idea towards the caches is onion and split-key-dns.

eastlake cookies: solution for reflection.  soft cache state (cache
can be purged, but pay roundtrip to reestablish it).

Crypto proposals
start-tls-for-dns: uses TLS, over TCP. Signalled with TO flag in EDNS.
downgrade, they suggest pinning TO in some way.
trust anchors for x509 certificates are unsettled (webtrust, dane, DHCP).
performance: +1(tcp) +2(tls) = +3 roundtrips for new connection.

dnsodtls: DTLS.  Deployment issues expected because of DTLS.  No UDP,
no TCP.
performance (+2? roundtrips like TLS?) for a new connection?
Signal, trustanchors?

dnscurve: authority side.  Wrapped in DNS, UDP and TCP. One crypto,
keys and signals in labels of nameserver names.
performance: +0 no roundtrip because key in nameserver name.

dnscrypt: cache side.  Wrapped in DNS, UDP and TCP. Also one crypto?
key and signal is preconfigured in the client (no distribution solution).
performance: +0 (preconfigured key)

dns-onion and split-key-dns: separate the lookup server (that
has the query) and the server that has the IP address of the client.
Very good for privacy, CDN-issues (anti edns-subnet).  What servers,
how encrypted, and signal?  Seems like this technology could be
'layered' with another crypto proposal as the carrier.
performance: since server-to-server communication in it, this will cause
extra delays, as well as the crypto carrier employed.

hallambaker-dnse: kerberos-like scheme with tickets and keys.
UDP? TCP? trustanchors? signalled by?
performance: ?

wijngaards-confidentialdns: opportunistic, soft state, UDP and TCP.
trustanchors none, believe first key.
performance: +1 roundtrip for a new connection


See
http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-04
http://tools.ietf.org/html/draft-hzhwm-start-tls-for-dns-00
http://tools.ietf.org/html/draft-jabley-dnsop-dns-onion-00
http://tools.ietf.org/html/draft-wijngaards-dnsop-confidentialdns-01
http://tools.ietf.org/html/draft-koch-perpass-dns-confidentiality-00
http://tools.ietf.org/html/draft-bortzmeyer-perpass-dns-privacy-01
http://tools.ietf.org/html/draft-bortzmeyer-dnsop-privacy-sol-00
http://tools.ietf.org/html/draft-hardaker-dnse-split-key-dns-00
http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls-00
http://tools.ietf.org/html/draft-bortzmeyer-dnsop-dns-privacy-02
http://tools.ietf.org/html/draft-hallambaker-dnse-01
http://tools.ietf.org/html/draft-hallambaker-privatedns-00
http://tools.ietf.org/html/draft-bortzmeyer-dns-qname-minimisation-02
http://dnscurve.org/
http://dnscrypt.org/
http://tools.ietf.org/html/draft-dempsky-dnscurve-01
http://tools.ietf.org/html/draft-osterweil-dane-ipsec-00
http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00

Best regards,
   Wouter

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTf02yAAoJEJ9vHC1+BF+NWpEQAJFIEaewln5vaEJo2w3aoDf3
vyvYhPOarDUWy1CDPwsIv9rz3fIuJarnuRRZ6P2M3rqVeNoDn876nZnwj+9w10R9
l4/PAgAYjS/haOtT60mJHa3TgV0TNf2YOr/WJ8EdMSff/aFbMzy4trsRhjZeerH2
KfIJOAzTq/XZRwJkNUdx9/l+aHDrYbHfCqY9wU1yeqKj+oZe+qiZ6aEg2G9kwfCA
y1/Pp7zzPhnfWgZCwONL2xt9udkeBQeRJlYIT1wMNk5pWTswZe72Mk/LH5bZwmRz
DPjtnUQcOvVedlNb5snM/kO6s4TJdmTUULUmUm0pgarNf02fNezyd7RgSQjaHzZC
goKmUiR2EqPOS8B99xUNe9LLxDccJ8MunszSqoNgYMY2hL4SlMq+xnY36kckAlSW
QjWiA6xxkHo4oFSCjInL02TJTcOYJWTkOHgUtBw6AspQi9EQRGO+zQK6w+EXGdXP
COeosvEVx/r5rafRCXYwr+PWVRyqz5ssqxKqp4Y2HP6zLQNNItsWzjCSHk2Zsu/a
G+JaGuBdUHTynVIET9ZWExO5UGvL6hIxMlZy5/nO3gnppo6HfvgH/h5NqO5F2+CZ
rulouktHyta5breHYpCC4ckDwlBB4/IhmD0vHnEeQovT76tgb7sw1rCZCt2ZJDm2
FjEPGE17oyK2tVQx+8Yd
=vP1m
-----END PGP SIGNATURE-----