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

[Phillip Hallam-Baker <[e-mail]>]

On Fri, May 23, 2014 at 9:31 AM, W.C.A. Wijngaards <[e-mail]> 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-dnse-01
> 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?
> 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.

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 [e-mail]' 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.