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

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 23 May 2014 15:31:31 +0200

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 23 May 2014 10:40:20 -0400

On Fri, May 23, 2014 at 9:31 AM, W.C.A. Wijngaards <[email-masked]> wrote:

Thanks for doing this.

> hallambaker-dnse: kerberos-like scheme with tickets and keys.

Just to be clear, my DNSE paper is a requirements document that
addresses the space, it is not a proposal. Private-DNS is the
proposal.

> http://tools.ietf.org/html/draft-hallambaker-privatedns-00

With respect to the questions, at this stage I am focusing on the
approach. To make this into a full scheme we would obviously need to
drill down into details etc.

> UDP? TCP? trustanchors? signalled by?

UDP: Yes, this is supported using the UYFM framing. Each request has
to fit into one packet but responses can have up to 16 packets.

TCP: Yes, a JSON web service is supported for cases where UDP cannot
get through.

SXS-Connect also works over the UDP transport in theory but I have
never tried it. But the ticket provision is a one time operation, it
probably does not matter.

Performance: As fast or faster than traditional DNS with lower load on servers.

Yes, Private DNS is faster than the traditional DNS protocol because
instead of making separate A and AAAA record requests, these are
combined in one round trip. So the resolver is only handling one
request not two.

The application performance can be improved even more because it is
now practical to perform SRV and ESRV requests as well.

My standard query set is A, AAAA, SRV, ESRV, if the server signals
that it accepts geo-data I will send that as well. This information
allows the server to route my application straight to the best service
to deliver the content.

Asking the right query is no longer more expensive than asking the
simplest one. There is no latency penalty.

Servers are completely stateless. The ticket contains the encrypted session key.

trustanchors: Short answer: whatever you like.

Long answer, you do have to make choices to get the security controls you want.

There are no external trustanchors required in the Private-DNS
protocol, the client binds to the service using the SXS-Connect
protocol once and then continues for years or decades. But SXS-Connect
has options.

Which options to use depends on whether we are talking about the
client-resolver interaction or the resolver-authoritative

For resolver-authoritative the obvious approach would be to bind to a
trust anchor in the DNS itself by publishing a cert.

For the client-resolver, the questions are much more involved as the
resolver is a trusted service. It is possible to use SXS-Connect
without any trust anchors at all using the PIN distribution mechanism.
That would be the approach to use in an enterprise deployment.

In a consumer environment the simplest approach is to simply leverage
TLS for authentication. Right now I am also leveraging TLS for the
confidentiality of the key exchange but I plan to change that very
soon by adding in an extra DH layer into the kerberos-like key setup.

So in the consumer environment we only rely on the WebPKI trustanchors
for the one time setup and after that only rely on them for the
integrity of the exchange (i.e. an attack would have to be active).
Once the DH exchange is implemented it is arguably acceptable to use
Private-DNS in a 'secure after first contact' mode.

It is possible to do everything in DNS space but most of us would want
our DNS service to be backed by a stronger demonstration of
accountability than the provider obtained a DNS name.

I do have a proposal that would mean that a user would only need to
use the TLS scheme once for their first device after which they would
'connect' new devices using a separate protocol. But that is not
really designed for Private-DNS alone, it is designed to allow the
user to bind their device to all their services.

So the idea would be I buy a new iPad and when I turn it on I say
'configure this to account settings from [email-masked]' and
then I get a confirmation request on my phone that asks me if I really
want to. If I say yes then the new iPad gets my whole crypto
credentials set:

* My set of PGP/SMIME decryption private keys
* My Private DNS connection
* Generates and registers a signature key for confirmation service
* Generates and registers a signature key for signing mail

These are also configured for ongoing management. Which is essential
for the mail decryption keys as they currently change once a month.

Now I fully accept that not everyone is going to want to enter the
full world of PHB security. Which is why I have divided up my proposal
into small, manageable bit sized pieces. This is the confirmation
portion:

https://datatracker.ietf.org/doc/draft-hallambaker-sxs-confirm/

You don't have to do this bit to do Private-DNS but if you are also
looking for a second factor protocol as well as DNS privacy then why
wouldn't you want the two protocols to use a consistent approach to
syntax, bindings etc.?

signalled by?

For the resolver-authoritative, probably an EDNS tag. Its easy enough to do.

For the client-resolver, I don't think signaling is necessarily
desirable. Because the starting point for any DNS security is to get
away from the lunatic notion of taking the nearest DNS service and
repeatedly changing it. The user is going to choose their DNS provider
as part of their network config.

My preferred approach is that the user does not have to be aware that
they are configuring DNS at all and they just click to 'enter the
security provider for this device' and magic happens. Of course the
advanced user might want to have different security provider for
different services etc.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 26 May 2014 10:28:56 +0200

Hi,

Looking at this list of features and solutions again, it strikes me
that dnscurve is actually a very, very good solution.  It encapsulates
fairly simply, has zero time-lag, and provides fairly good security on
the key by piggy-backing it on the name of the nameserver.  Algorithm
agility by abusing DS records (and perhaps flags in the name? to
signal) could potentially be added to it.  Towards caches is solved
with dnscrypt, with the key distribution the hard problem towards
caches.  So that would tick a lot of the requirements with a simple
protocol.

To some extent, discussing the solution space in this way is also a
way to look at how people have fulfilled different requirements in
neat 'package' combinations.  I worry that we are moving towards more
complication in the crypto and key handling, where the main thrust of
our goal is an increase in privacy, which needs no complication but
'better than nothing'.  Something that solves the main goal but can be
extended, later, would have my preference.

The complication in the split-key and onion proposals, is the
complication that increases privacy, and that should be my preference
for adding more features.

Phillip, Thanks for filling in the missing details; sorry about the
wrong draft quote.

Best regards,
   Wouter

On 05/23/2014 04:40 PM, Phillip Hallam-Baker wrote:
> approach. To make this into a full scheme we would obviously need
> to drill down into details etc.
> 
> 
>> UDP? TCP? trustanchors? signalled by? performance: ?
> 
> UDP: Yes, this is supported using the UYFM framing. Each request
> has to fit into one packet but responses can have up to 16
> packets.
> 
> TCP: Yes, a JSON web service is supported for cases where UDP
> cannot get through.
> 
> never tried it. But the ticket provision is a one time operation,
> it probably does not matter.
> 
> 
> Yes, Private DNS is faster than the traditional DNS protocol
> because instead of making separate A and AAAA record requests,
> these are combined in one round trip. So the resolver is only
> handling one request not two.
> 
> The application performance can be improved even more because it
> is now practical to perform SRV and ESRV requests as well.
> 
> that it accepts geo-data I will send that as well. This
> information allows the server to route my application straight to
> the best service to deliver the content.
> 
> protocol once and then continues for years or decades. But
> SXS-Connect has options.
> 
> For resolver-authoritative the obvious approach would be to bind to
> a trust anchor in the DNS itself by publishing a cert.
> 
> 
> For the client-resolver, the questions are much more involved as
> the resolver is a trusted service. It is possible to use
> SXS-Connect without any trust anchors at all using the PIN
> distribution mechanism. That would be the approach to use in an
> enterprise deployment.
> 
> In a consumer environment the simplest approach is to simply
> leverage TLS for authentication. Right now I am also leveraging TLS
> for the confidentiality of the key exchange but I plan to change
> that very soon by adding in an extra DH layer into the
> kerberos-like key setup.
> 
> So in the consumer environment we only rely on the WebPKI
> trustanchors for the one time setup and after that only rely on
> them for the integrity of the exchange (i.e. an attack would have
> to be active). Once the DH exchange is implemented it is arguably
> acceptable to use Private-DNS in a 'secure after first contact'
> mode.
> 
> It is possible to do everything in DNS space but most of us would
> want our DNS service to be backed by a stronger demonstration of 
> I do have a proposal that would mean that a user would only need
> to use the TLS scheme once for their first device after which they
> would 'connect' new devices using a separate protocol. But that is
> not really designed for Private-DNS alone, it is designed to allow
> the user to bind their device to all their services.
> 
> 'configure this to account settings from [email-masked]'
> and then I get a confirmation request on my phone that asks me if I
> really want to. If I say yes then the new iPad gets my whole
> crypto credentials set:
> 
> * My set of PGP/SMIME decryption private keys * My Private DNS
> connection * Generates and registers a signature key for
> confirmation service * Generates and registers a signature key for
> signing mail
> 
> These are also configured for ongoing management. Which is
> essential for the mail decryption keys as they currently change
> once a month.
> 
> full world of PHB security. Which is why I have divided up my
> proposal into small, manageable bit sized pieces. This is the
> confirmation portion:
> 
> You don't have to do this bit to do Private-DNS but if you are
> also looking for a second factor protocol as well as DNS privacy
> then why wouldn't you want the two protocols to use a consistent
> approach to syntax, bindings etc.?
> 
> 
> 
> signalled by?
> 
> desirable. Because the starting point for any DNS security is to
> get away from the lunatic notion of taking the nearest DNS service
> and repeatedly changing it. The user is going to choose their DNS
> provider as part of their network config.
> 
> My preferred approach is that the user does not have to be aware
> that they are configuring DNS at all and they just click to 'enter
> the security provider for this device' and magic happens. Of course
> the advanced user might want to have different security provider
> for different services etc.
> 
> _______________________________________________ dns-privacy mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dns-privacy
>