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

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

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

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:
> 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.
> 
> _______________________________________________ dns-privacy mailing
> list [e-mail] 
> https://www.ietf.org/mailman/listinfo/dns-privacy
> 

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

iQIcBAEBAgAGBQJTgvtIAAoJEJ9vHC1+BF+NJ6AP/RpNlPyQ+B8ILwFpzkA9UeKB
WZ+u+tsulLsIJzhBTBXjUig3dWdeJ4IwGdduMnLBsrQIMpoKy9qV5D2yuZmyvBtW
Tnm23kw0iFcLEo1w/Er8aiD6IaAs/zNIlGNfUu8iO9a2Y0JJNNEvuPRw/6c6qa12
dQPgvI1abDlIu2YDNkFFREYP+nAy+nc0GOAl9XXgVDOB7huDWA2TFC2apRvAngjI
IJO1vESZCqyu4hlq+8XazMFSJidASZezeuvjmlGsyXFSWDiGfsrl/wod2P/Hills
RARpC09ulvTZRSna3ooUXKj0SHy1a4vDVsJOAXCQM2yZZJP6E3A9PrUmRcHcoIQe
wu+eeBap1uEk7nA4A3U8qxlZsiW7t+iO6ZW8sDoTnHHqN80XvuuyXfPaYNdrL70U
QXKByJqP3Uqr+dSGP92ON8G53z7lfA5IvmTH8XO/dCgFmm7R/wEbtytyJbn0ZskO
UfSekFAz4j+zuysn3S2y8NrFbf+w5iP6W7M/dh1nRHvMKCSjZbZeV+jjkIWcRgzU
OpQXZtkpCBisTaRTp5Ij8p5NM7vDpCNtoYsMWsWJIAQ7s/b+QGBsrk3Th4+fM8ru
pP88cI7edIWcoXghaJGDCfmBooyZ9zTn2fcGsSAw8JqekObDGyIbVunDBjIQsusk
Qoe+XSg9zAZs/tTvVtfg
=KvRY
-----END PGP SIGNATURE-----