Subject: [dns-privacy] Agenda time.

From: Warren Kumari <[email-masked]>
Date: Thu, 9 Oct 2014 20:01:47 -0400

Hi there all,

So, DPRIVE should be meeting in Hawaii, either as a fully fledged
working group, or like a BoF that we are planning on running like a WG
session.

So, if you'd like some presentation time, please let us (Tim W or
myself) know so we can start organizing the agenda.

One agenda request -- is there anyone who is knowledgeable on DNSCurve
and can explain clearly and in baby words (suitable for the likes of
me) why this doesn't solve all our problems? Perhaps we can be the
worlds shortest WG :-)

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: John Heidemann <[email-masked]>
Date: Sat, 11 Oct 2014 16:25:09 -0700

On Thu, 09 Oct 2014 20:01:47 -0400, Warren Kumari wrote: 
>...

We talk about this issue, comparing DNSCurve and DNSCrypt [*] in a
section 3.2 of our tech report about T-DNS (one of the DNS-over-TLS
proposals).  (The tech report is at
http://www.isi.edu/~johnh/PAPERS/Zhu14b/ .)

My summary of what we wrote there:

My biggest concern is that dnscurve/dnscrypt are bespoke for DNS.

That's good and bad.  The good is that it is very focused and has no
"fat" for DNS.

But for a long-lived standard, I think one wants something that lets you
choose the crypto protocols, and change that choice with relative ease
in the future.  (Without taking a position on ECC here, I'm saying that
NO single protocol should be locked in.) [**]

Given the subtlety of crypto design and implementation issues, I also
think using an off-the-shelf design (like TLS) and with multiple, mature
implementations has a big advantage over rolling one's one. [***]

Finally, dnscurve requires that the key go in the hostname of the
server.  For some, that's a downside, ranging from unpleasant to perhaps
operationally impossible.

There are also a bunch of pragmatic questions: are there draft specs for
dnscrypt and dnscurve?  multiple implementations?  has IETF documented
ECC yet?  These can all be fixed with work, but it's not just
off-the-shelf.

But to me the core question is: is DNS really so special we
want have design our own, new, protocol?  Or can we follow what HTTP and
SMTP and POP and IMAP do?

   -John

[*] DNSCrypt is stub-to-recursive, and DNSCurve is
recursive-to-authoritative, they're similar but different.  I'll let an
expert in them describe how they compare.

[**] Yes choice of protocol raises complexity and risk of downgrade
attacks, but one must compare that against the cost of swapping out a
hard-coded choice.

[***] Clearly the the recent bugs in openssl and gnutls are serious, so
standard designs and common libraries is not a panacea.  I think the
vetting of a common design and the attention common libraries get remain
hugely valuable.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 11 Oct 2014 19:42:29 -0400

> On Oct 11, 2014, at 7:25 PM, John Heidemann <[email-masked]> wrote:
> 

I totally disagree

TLS is a very complex protocol and designed for a completely different application. 

I use TLS to secure the key exchange. But not client resolver messages. The TLS framing is designed for TCP and reuse really does not give any useful benefit. Framing is easy to get right.

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 12 Oct 2014 18:28:46 +0530

Hi Warren

> me) why this doesn't solve all our problems? Perhaps we can be the

This is a modified copy of what I sent to an internal list at my
.org. If anyone thinks any of the following is incorrect, please feel
free to correct me.

The DNSCurve draft is here:
http://tools.ietf.org/html/draft-dempsky-dnscurve-01

You may also want to go through the NaCl library that provides this
crypto box interface for programs to use. tweetnacl.{c,h} is a simpler
version of it that programmers can easily use.

Pros:

* It seems simple to add support in implementations (programmer), deploy
  and maintain (admin)
* Offers authenticated and secure DNS message transmission between
  caching resolver and auth server
* Can work over UDP and TCP. No "secure channel establishment". E.g.,
  between a caching resolver and a newly found auth server, you can have
  1 UDP datagram for query, 1 UDP datagram for response, no additional
  roundtrips. Having UDP support is a win for many reasons.
* No additional state maintenance on servers
* Client sends its public key (and nonce) as part of query and can
  change it regularly. I'm not sure if it qualifies as "forward
  security".
* I haven't seen anything that'd make it incompatible with existing
  DNS parts like DNSSEC, TSIG, UPDATE, [IA]XFR, etc.

* pros compared to DNSSEC related to authenticated data (apart from security):
 + There'd be no need to use DNSSEC when DNSCurve is used as
   it also authenticates data (keys are associated with the zone). For
   example, with such a system a stub might query a cache with AD=1 and
   DO=0 (RFC 6840) and receive what it can consider authentic data.
 + Though online, it _may_ arguably be faster than DNSSEC due to NSEC3
   hash computations and associated lookups for the latter. (Said in a
   very feeble voice ;) I haven't tested it.)
 + Zone enumeration situation is identical to DNSSEC-less DNS, whereas
   there are attacks on NSEC3
 + No complicated key rollover dance (compared to DNSSEC, where there's
   a high chance of mistakes if done manually)
 + No zone bloat
 + No frequent server-side rollovers required

Cons:

* How it "extends" DNS fields seems a bit messy to me, esp. the TXT
  case. Surely there are better ways to do it.
* DNSCurve hardwires the security method it uses to 1 box:
  Curve25519XSalsa20Poly1305 (vs. a protocol like TLS that offers
  everything under the sun). This is both a disadvantage (if it is
  broken) and an advantage (not easy to shoot yourself in the foot by
  picking weak methods). But this can be extended by adding fields that
  specify the method used.
* DNSCurve is under-specified, but this can be improved
* UDP amplification needs to be checked
* Not all firewalls may like it as they are bad at DNS UDP datagrams,
  esp. if raw streamlined format is sent to port 53 and also the query
  datagram sizes.

* cons compared to DNSSEC related to AD:
 + Keys have to live on the nameservers
 + The entity supplying the DNS data cannot use another untrusted
   party's nameserver to serve it, as they cannot give them a pre-signed
   zone.

Other bits:

* It's not clear from the draft what the contents of the crypto box are,
  whether it's the complete DNS message, UDP packet?! or something else.
  The crypto box has an overhead of 16 octets. So for message of size M
  octets, the crypto box takes 16 + M octets.
* The draft doesn't say clearly if the streamlined format is sent
  directly as UDP payload to port 53. In streamlined format, query
  overhead is 68 octets + sizeof (DNS message). Reply UDP payload is 48
  octets + sizeof (DNS message).
* Public keys are distributed in RDATA of NS records (embedded in the
  NSDNAME) in the parent zone, so there's similar hierarchical key
  distribution to DNSSEC. For ".", it'd need a trust anchor.
* To avoid roundtrips, a recursor can "guess" that nameservers support
  DNSCurve by looking at the "uz5" prefix-named key in the parent zone.
* Multiple nameservers can answer for a zone using the same zone key,
  but nonces should strictly be separated by some kind of numbering such
  as different low-order bits. It seems using separate keys (multiple
  keys per zone) should be possible.
* Traffic analysis has to be checked

I suppose the cons can be fixed by "committee". :)

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 12 Oct 2014 18:53:03 +0530

Hi John

> That's good and bad.  The good is that it is very focused and has no

By bespoke, I assume you mean tailor-made for DNS. That's the only
meaning in my dictionary that fits. :-)

DNS already uses a lot of tailor-made security parts for it like TSIG,
DNSSEC, etc.

> NO single protocol should be locked in.) [**]

+1. This could be a problem for DNSCurve that hardwires to
Curve25519XSalsa20Poly1305 in case there are security issues that would
make us need to abandon it.

On the other hand, having a choice of methods (that often include
insecure ones in protocols such as SSL) can give an implementor rope to
hang oneself. Most programmers who implement DNS are not cryptographers
and it's better that crypto is a proven-to-be-secure box. This is
something that NaCl (that DNSCurve uses) provides.

Here is a tweet Andy Wingo made today on how much rope TLS could hand
out because it's so configurable:
https://twitter.com/andywingo/status/521232609204912129

> implementations has a big advantage over rolling one's one. [***]

If TLS was suitable, then it could be considered compared to other
choices. However TLS is a protocol layered over TCP whereas much of DNS
traffic uses UDP.

> operationally impossible.

Can you elaborate how this is unpleasant or operationally impossible?

> ECC yet?  These can all be fixed with work, but it's not just

ECC is a general area of cryptography. I assume you mean to ask whether
the crypto used in DNSCurve (Curve25519XSalsa20Poly1305) is specified.
These are individually specified in various papers, but I don't think
any are documented at IETF. The NaCl implementation is off-the-shelf and
there is also a public domain tweetnacl.{c,h} implementation available
that programmers can use.

There are many formats that are used by network protocols that are not
specified such as bzip2. However, +1 towards documenting them.

> SMTP and POP and IMAP do?

All the protocols you've listed use TCP. The popular secure versions of
these protocols all use TLS. Much of DNS traffic is UDP.

		Mukund

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Oct 2014 14:34:45 +0100

Just one point on one bit of this. TCPINC will be having
some of the same discussion as they consider the pros and
cons of the tcpcrypt proposal vs. some (D)TLS based ones.
While its quite possible that the cases are so different
that different conclusions ought be reached, I think its
clear that some of the analysis will be the same. So I hope
that DPRIVE and TCPINC chairs/participants try to save us
all a bit of time and energy by where possible factoring out
the generic parts of the argument from the DNS and TCP
specific parts. And maybe subscribing to both lists would
good for folks who care about the (D)TLS/generic-solution
vs. protocol-specific solution topic.

Cheers,
S.

On 12/10/14 14:23, Mukund Sivaraman wrote:
>> That's good and bad.  The good is that it is very focused and has
>> no "fat" for DNS.
> 
> DNS already uses a lot of tailor-made security parts for it like
> TSIG, DNSSEC, etc.
> 
>> But for a long-lived standard, I think one wants something that
>> lets you choose the crypto protocols, and change that choice with
>> relative ease in the future.  (Without taking a position on ECC
>> here, I'm saying that NO single protocol should be locked in.)
>> [**]
> 
> Curve25519XSalsa20Poly1305 in case there are security issues that
> would make us need to abandon it.
> 
> insecure ones in protocols such as SSL) can give an implementor
> rope to hang oneself. Most programmers who implement DNS are not
> cryptographers and it's better that crypto is a proven-to-be-secure
> box. This is something that NaCl (that DNSCurve uses) provides.
> 
> Here is a tweet Andy Wingo made today on how much rope TLS could
> hand out because it's so configurable: 
>> Given the subtlety of crypto design and implementation issues, I
>> also think using an off-the-shelf design (like TLS) and with
>> multiple, mature implementations has a big advantage over rolling
>> one's one. [***]
> 
> choices. However TLS is a protocol layered over TCP whereas much of
> DNS traffic uses UDP.
> 
>> Finally, dnscurve requires that the key go in the hostname of
>> the server.  For some, that's a downside, ranging from unpleasant
>> to perhaps operationally impossible.
> 
>> There are also a bunch of pragmatic questions: are there draft
>> specs for dnscrypt and dnscurve?  multiple implementations?  has
>> IETF documented ECC yet?  These can all be fixed with work, but
>> it's not just off-the-shelf.
> 
> ECC is a general area of cryptography. I assume you mean to ask
> whether the crypto used in DNSCurve (Curve25519XSalsa20Poly1305) is
> specified. These are individually specified in various papers, but
> I don't think any are documented at IETF. The NaCl implementation
> is off-the-shelf and there is also a public domain tweetnacl.{c,h}
> implementation available that programmers can use.
> 
> There are many formats that are used by network protocols that are
> not specified such as bzip2. However, +1 towards documenting them.
> 
>> But to me the core question is: is DNS really so special we want
>> have design our own, new, protocol?  Or can we follow what HTTP
>> and SMTP and POP and IMAP do?
> 
> All the protocols you've listed use TCP. The popular secure
> versions of these protocols all use TLS. Much of DNS traffic is
> UDP.
> 
> Mukund
> 
> 
> 
> _______________________________________________ dns-privacy mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 12 Oct 2014 11:34:52 -0400

> vs. protocol-specific solution topic.

I think we should also throw the TLS/2.0 discussion into the mix and
ask why IPSEC is a failure.

All these protocols have two major components. A key exchange and
formatting. Getting the key exchange right is hard, getting the
formatting right is fairly straightforward if you do it from scratch.
Trying to make sense of a formatting designed for a different
application makes it hard.

Key exchange is the hard part to get right and can be shared. I
originally designed SXS-Connect to allow me to establish keys for use
in Web Services. But it could be used for IPSEC, DNS-PRIVACY, TCPINC,
whatever.

That said, SXS-Connect is right now just relying on the TLS key
exchange. So I get reuse of TLS. But that limits the applications and
the security. And I am rather unhappy with relying on TLS which is a
transport layer security solution to protect application layer keys.
So I really want to drop in a DH or EDH on top.

DNSPrivacy does not actually need to do key exchange very often
because a client should change its DNS service no more frequently than
once a year (ESPECIALLY if it is a mobile device). And the client
really does have to authenticate the service. No really, taking your
DNS service from random servers is just so incredibly stupid I can't
believe I have to point that out. So just co-opting the TLS stack is
probably OK for that niche.

TCPINC on the other hand is going to need more agility in making
connections and unauthenticated connections are definitely in scope
and acceptable. So engineering a custom key exchange would make sense.
If you reuse TLS for key exchange then you might as well do TLS. But
the crunch here is that we should not do a custom key exchange for
TCPINC, we should design a module that can serve IPSEC/2.0, TLS/2.0
etc.

So what do I mean by a key exchange? From a model point of view it has
a choice of inputs but the output is always an identifier and a shared
set of cryptographic parameters being algorithm choice(s) and shared
key(s).

The input could be the public key of a server, a pair of public keys,
a symmetric key or nothing.

So what I am arguing here is, yes we should try to do reuse. But
please lets use something that is designed for reuse and not just take
the cowardly way out and pick something familiar even though it is 20
years old and so complicated only a half dozen people at most really
understand it.

---

From: "Mankin, Allison" <[email-masked]>
Date: Sun, 12 Oct 2014 23:04:33 +0000

Warren,

I would like to request a 5 minute slot to introduce the idea of a draft on methods of evaluating DNS privacy.

Thanks,

Allison

> On Oct 9, 2014, at 17:01, "Warren Kumari" <[email-masked]> wrote:
> 
> Hi there all,
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 12 Oct 2014 16:35:44 -0700

> I would like to request a 5 minute slot to introduce the idea of a draft on methods of evaluating DNS privacy.

5 minutes is not enough; it should be more.

--Paul Hoffman

---

From: John Heidemann <[email-masked]>
Date: Sun, 12 Oct 2014 21:53:49 -0700

>meaning in my dictionary that fits. :-)

Yes.

>https://twitter.com/andywingo/status/521232609204912129

Agreed.  That was in the [**] footnote of my prior mail.

To me, the necessity of future upgrade unfortunately outweighs the
complexity of configurability.  (And we must provide best practices to
not make mistakes in our choices.)

>choices. However TLS is a protocol layered over TCP whereas much of DNS

(and later you say)

>these protocols all use TLS. Much of DNS traffic is UDP.

Understood.  There have been discussions about the potential of TCP (and
TLS) for on dnsop recently, and by several people elsewhere over the years.

My views (with the help of my co-authors!) are written down in the tech
report I put in my prior post, at
<http://www.isi.edu/~johnh/PAPERS/Zhu14b.html>.  We try hard to examine
the performance concerns of TCP and TLS for DNS to both clients and
servers, and provide some performance comparisons to DNScurve and
DNScrypt, and look at deployment issues (appendix H).

(And if one really wants UDP, then DTLS is an alternative.  I don't
think that helps over TLS; the argument is written out in Appendix J of
the tech report.)

There are a LOT of issues around deployment and performance of DNS and
TCP and TLS, and a range of opinions on both (some very strong
opinions :-).  I encourage folks to not just discard TCP out of hand.

>Can you elaborate how this is unpleasant or operationally impossible?

I think it's better for someone who runs commercial DNS services to
comment on that.

>specified such as bzip2. However, +1 towards documenting them.

I'm sure that nacl is really clean code, but my guess is it's not quite
ready for IETF WG last call.

   -John

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 13 Oct 2014 02:29:35 -0400

> 5 minutes is not enough; it should be more.

I agree with Paul.  I think 15 minutes work make more sense, given 
questions, etc.

tim

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 13 Oct 2014 16:10:54 +0200

On Thu, Oct 09, 2014 at 08:01:47PM -0400,
 Warren Kumari <[email-masked]> wrote 
 a message of 29 lines which said:

> So, if you'd like some presentation time,

It think it is obvious but, yes, I would like to have some time (10'
speech + 25' discussion?) to talk about the problem description: what
are the threats, specially. (In all the discussions about DNS privacy
I've seen at IETF, most people focused on just one threat, forgetting
all the others.)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 13 Oct 2014 16:17:54 +0200

On Sun, Oct 12, 2014 at 06:28:46PM +0530,
 Mukund Sivaraman <[email-masked]> wrote 

> Cons:

Also:

* since nameservers names are much longer, you cannot have as many
NS records in a packet,
* the future (currently, it is non-existant) cryptographic agility
will be made harder by this choice, since every algorithm used by
DNScurve needs to have short keys (a label is limited in size).

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Oct 2014 08:15:30 -0700

> DNScurve needs to have short keys (a label is limited in size).

Ummm, aren't we forgetting what is for many the much larger cons:

* The nameserver has to do a Diffie-Hellman key agreement with every relying party, hugely increasing the CPU load.

* The private key must be online all the time.

* The private key must be shared by all the nameservers.

Remember: DNSSEC is sign-once-and-serve; DNScurve is server-does-crypto-for-every-query.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Oct 2014 11:20:35 -0400 (EDT)

> Remember: DNSSEC is sign-once-and-serve; DNScurve is server-does-crypto-for-every-query.

Any dns privacy protocol that wants PFS + encrypted communication would need to do that too?
Like if you picked TLS DHE.

Paul
ps. not an endorsement for dnscurve :)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Oct 2014 11:36:52 -0400

> Remember: DNSSEC is sign-once-and-serve; DNScurve is server-does-crypto-for-every-query.

And the biggest problem:

There isn't an advocate for the protocol to push it through a WG
process. DJB has not played that role to date. I don't think he plans
to do so in future.

I am not sure if its fair to have a presentation thats a pile on criticizing it.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Oct 2014 08:38:28 -0700

> Any dns privacy protocol that wants PFS + encrypted communication would need to do that too?

Yes, which is why this WG charter is focused only on the stub-to-recursive link. The private key for a recursive resolver that talks to the .com authoritative server has very different value than the private key for the .com zone.

> ps. not an endorsement for dnscurve :)

Good to hear. :-)

--Paul Hoffman

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Oct 2014 12:04:07 -0400

> Yes, which is why this WG charter is focused only on the stub-to-recursive link. The private key for a recursive resolver that talks to the .com authoritative server has very different value than t…

I think we can maybe clarify the charter a little here.

Protecting the integrity of the messages between the stub and the
resolver should be a requirement for any spec.

But authenticity of the authoritative zone data is a completely
separate problem. For that purpose we want to be able to do offline
signing.

So rather than ruling authentication out of scope, I would prefer if
we ruled only authentication of authoritative zone data out of scope.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Oct 2014 12:17:53 -0400 (EDT)

Yes.

> separate problem. For that purpose we want to be able to do offline

This is completely out of scope. We have DNSSEC for that.

Perhaps you meant encryption to the authoritative server? That's a
harder problem because as with dnscurve, that's a DDOS problem.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Oct 2014 12:26:19 -0400

> This is completely out of scope. We have DNSSEC for that.

Which is why it would be appropriate for the charter to exclude it.

I want the charter definition to be precise and put out of scope only
what DNSSEC actually does rather than 'authentication' in general
which it does not.

---

From: John Kristoff <[email-masked]>
Date: Mon, 13 Oct 2014 11:40:06 -0500

On Mon, 13 Oct 2014 11:36:52 -0400

> process. DJB has not played that role to date. I don't think he plans

What did Dan say when you asked him about it?

David Ulevitch expressed interest in his team helping develop a
standard based on the work they've done with their dnscrypt
implementation.  See here:

  <http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00193.html>

John

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 13 Oct 2014 13:49:28 -0400

> What did Dan say when you asked him about it?

Its what he didn't do - post to this list.

>   <http://www.ietf.org/mail-archive/web/dns-privacy/current/msg00193.html>

And that is how I would expect to see DNSCurve appear in IETF process.
It is a good piece of work but not final. I am not happy about
presenting work just to shoot it down.

What we want to do here is to produce a specification that essentially
fits into the same niche as DNSCurve but follows an IETF architectural
style rather than being hyperoptimized to one set of parameters.

DNSCurve was originally proposed to do a rather different job and it
is actually better at that job than DNSSEC in my opinion.

I would expect that anyone taking up DNSCurve and proposing it in this
forum would do what I did and use it as a starting point and make
modifications.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 13 Oct 2014 14:22:48 -0400 (EDT)

> is actually better at that job than DNSSEC in my opinion.

I agree that DNSSEC sucks at the job it is not supposed to do :)

> forum would do what I did and use it as a starting point and make

You want different spokes to jam in the dns caches? Or a different spoke
to stab into the authoritative DNS servers' CPU? Or a different spoke to
stab into the DNS proxies and deep packet firewall inspectors and DNS
transparent proxies?

There are very good reasons dnscurve was not picked up by the IETF. And
it really doesn't make sense to pick up dnscurve for only the transport
hop encryption part, because:

1) it is hacked into the DNS using NS record overloading with severe
    limitations
2) it spews non-DNS traffic over port 53
3) it hardcodes crypto parameters to the One True Curve
4) it was designed to run on authoritative servers, not dns caches

Really, dnscurve was about killing the dns caching resolver. Why on
earth would anyone propose to use it to secure those same entities the
protocol insists on killing?

dnscurve has no place in an IETF dnspriv discussion other than to serve
as an example on how to not secure resolver-stub communication.

I'm not set for any of the proposed solutions yet, but:

- I like the idea of using (D)TLS (but on port 443, possibly with ALPN,
   and not using any kind of "starttls hack" to put non-DNS traffic on
   port 53)

- I like the idea of using regular format DNS payloads over port 53
   but nervous about more problematic bad DNS software

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 14 Oct 2014 15:30:25 +0530

Hi Paul

> as an example on how to not secure resolver-stub communication.

I came into this late, and I didn't know before that this discussion was
only about resolver-stub security. In any case, in reply to the above,
to me it appears that there are prior opinions against DNSCurve (and
maybe there are good reasons for it).

Will you explain why stub-resolver communication cannot be secured with
the concepts in DNSCurve? The NS record would not apply, but I don't see
anything in the packet formats itself that would make it useless. Any
other scheme would also require key distribution of either a shared key
or a public key between resolver and stub. Are there additional
requirements apart from transport security?

Even though DNSCurve in its current form has issues, I don't think it's
right to dismiss it from discussion and not take ideas from it. The
central idea in DNSCurve is that the DNS message goes into a safe box
and the receiver uses the associated crypto params in the packet to open
the box and use the DNS message in it. There is no prior handshake
required, and you can have 1 datagram query -> 1 datagram reply. Reading
the NaCl code, it seems one can use the same single public-key operation
for future messages with the _beforenm() and _afternm() functions for
performance, albeit at the expense of maintaining state.

It may use DJB's crypto and fixed key sizes in the 2 packet types in the
draft, but each packet has the type identifier in the header. Nothing
stops adding additional types with different algorithms, keysizes and
nonces, keeping the concept of the dns-message-in-a-box.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 14 Oct 2014 15:43:29 +0530

Hi Warren

>    DO=0 (RFC 6840) and receive what it can consider authentic data.

In reply to my own mail, I take this back.

My colleague pointed out that some applications now do end-to-end
validation (not simply trust the AD bit, but check signatures). In this
case, DNSSEC would absolutely be necessary to use cached answers.

It would also be necessary when there's no direct route to a remote
authoritative server to get data authenticated as part of transport.

>   party's nameserver to serve it, as they cannot give them a pre-signed

And this too, such as for root and various secondary DNS hosting
services.

		Mukund

---

From: Paul Wouters <[email-masked]>
Date: Tue, 14 Oct 2014 10:04:14 -0400 (EDT)

On Tue, 14 Oct 2014, Mukund Sivaraman wrote:

> anything in the packet formats itself that would make it useless.

dnscurve is based on talking to the crypto keys from the NS records on
authoritative servers. You cannot have intermediaries unless you fully
trust those to relay data unmodified. Dan made some wild and provenly
incorrect claims about "dns cache being obsolete anyway" and has made
no attempt with his protocols to allow secure (encrypted and
authenticated) communication between a resolver and a stub.

> Any

Of course, the fundamental problem with dns privacy between the resolver
and the stub is that there is no prior trust relationship. Even crypto
keys wouldn't help you trust the resolver, it could only help you talk
to the untrusted resolver privately at best.

> right to dismiss it from discussion and not take ideas from it.

I understand your wish for dnscurve to be useful, but it is
unfortunately not more than that. dnscurve authenticates and encrypts
traffic from stub to auth servers. It's core to its design. If you
take that away, you are left with "some specific ECC curve encryption".
There is simply nothing left to "take from" dnscurve.

It's like saying the use of green camouflage clothing provides security
and privacy agaist distant enemies in the woods, so we should try to
use it as well for close combat on the blue water.

> The
> the box and use the DNS message in it.

We normally call that idea "encryption". And all the mentioned proposals
for dns privacy already include encryption in one way or the other.

> There is no prior handshake
> required

No prior handshake depends on 1) having a trusted relationship with its
parent using dnscurve or a hardcoded key and 2) not using intermediary
dns servers. Unfortuantely, the main use case for dns privacy here IS
the cse where we depend on an intermediary player.

>, and you can have 1 datagram query -> 1 datagram reply.

Every solution can do that, once you have setup the crypto handshake.
Your "1 query and 1 reply" depends on you already knowing the
NS-embedded key of the parent of the query you are doing now. It's a very
artificial scenario.

> nonces, keeping the concept of the dns-message-in-a-box.

So let's use dnscurve without the NS embedded key hack, without
curve25519, and without set in stone crypto parameters. What you have
left is a statement "let's encrypt DNS packets". That has absolutely
nothing left to do with dnscurve.

doing crypto is not the hard problem. Setting up a secure channel to the
resolver is the hard problem. I think it might be unfixable unless you
only use the DHCP supplied nameserver only to reach a third party
trusted resolver elsewhere on the internet.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Oct 2014 10:26:40 -0400

On Tue, Oct 14, 2014 at 10:04 AM, Paul Wouters <[email-masked]> wrote:

I think Paul is being a little hard on DNSCurve here. At the time it
was proposed DNSSEC had been stalled for years and looked close to
being abandoned. Looking at an alternative architecture was
legitimate.

But that isn't the problem we are being chartered to solve.

There has always been an argument as to whether transport layer or
message layer security is 'right'. And the fact is that they both give
different properties and achieve different things. To achieve
encryption and stub-recursive authentication the appropriate approach
is to look at the transport layer. To achieve authoritative-recursive
or authoritative-stub authentication then the appropriate approach is
to look at the message layer.

In the past message layer and transport layer were seen as
alternatives. In the next-gen crypto we see both as being required.

> nothing left to do with dnscurve.

True, and that is what happens when we look at a 'stripped down'
version of TLS.

I think it is worth looking really hard at DNSCurve because it shows
the limits to trying to maintain compatibility with the legacy DNS
protocol on port 53. DJB makes a really good effort but he ends up
having to bend the protocol left right and center to get things to
fit.

> trusted resolver elsewhere on the internet.

Which is (almost) my approach.

What I do is that I use the DHCP supplied nameserver to establish the
initial connection to the service. The connection includes the crypto
parameters and service parameters to use. Including the IP addresses
and ports numbers for the hosts.

The only time that the client would ever rely on DHCP DNS in future is
for corner cases where the Web Service transport is being used as
fallback or the host IP address was changed at some point and the
client did not get the update notice. But even here the long term
binding is to a set of cryptographic keys, not IP parameters.

The only practical constraint on the port number is that you almost
certainly don't want port 53 or any other well known port that gets
interfered with by middleboxen. Since the port number is never used
for discovery, there is no need to assign a well known port.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Oct 2014 10:25:14 +0200

On Tue, Oct 14, 2014 at 10:04:14AM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 80 lines which said:

> unfortunately not more than that. dnscurve authenticates and
> encrypts traffic from stub to auth servers. It's core to its
> design. If you take that away, you are left with "some specific ECC
> curve encryption".

I disagree here. The work to "port" DNScurve to the stub-to-resolver
link has already been done. It is called DNScrypt
<http://dnscrypt.org/>. It is actually deployed
<http://www.opendns.com/about/innovations/dnscrypt/>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 20 Oct 2014 10:32:27 +0200

On Tue, Oct 14, 2014 at 10:04:14AM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 80 lines which said:

> And all the mentioned proposals for dns privacy already include
> encryption in one way or the other.

I clearly disagree. At least two other documented (in Internet-Drafts)
proposals do not use encryption at all:

* QNAME minimisation
* Local (on the end user's machine) resolvers with cache

Both minimise data sent upstream, the first leg of data privacy (the
second being encryption: you need two legs to walk).

See RFC 6973, section 6.1

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Oct 2014 07:02:01 -0700

> On Oct 20, 2014, at 1:25 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

And, after many attempts by people here, it is still undocumented. The is a bit of a protocol description, but it is fairly incomprehensible, other than "we're using great crypto!".

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Oct 2014 10:08:18 -0400 (EDT)

> See RFC 6973, section 6.1

You take me comment a bit out of context. After reducing the use of
dnscurve to "some form of encryption", I meant to say we have various
other proposals for that already without the problems of dnscurve.

I did not mean to refer that all dnspriv work had to be about
encryption.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Oct 2014 10:15:32 -0400 (EDT)

> <http://www.opendns.com/about/innovations/dnscrypt/>

This is just a simple VPN setup limited to DNS traffic. It does do any
kind of internet keying exchange or anything. It's yet another
Curve25519 container looking for a problem.

The IETF has plenty of tunneling/encryption protocols. Creating a new
one with the limitations of dnscurve serves no good purpose to anyone.

If opendns really wanted their crypto to be much more useful, they would
ensure VPN profiles using IKE/IPsec that work on stock mobile phones, not
custom crypto solutions.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Oct 2014 13:11:15 -0400

On Mon, Oct 20, 2014 at 10:02 AM, Paul Hoffman <[email-masked]>
wrote:

> And, after many attempts by people here, it is still undocumented. The is
> a bit of a protocol description, but it is fairly incomprehensible, other
> than "we're using great crypto!".
>

+1

The task here isn't to produce a great protocol. It is to document a great
protocol in such a fashion that others can produce interoperable
implementations with minimal effort and confusion.

And by great we mean that it is efficient and secure, but also it should
follow a design pattern that is compatible with the IETF approach.

Designing a crypto protocol is not the difficult part, documentation and
deployment are.

By compatible with IETF approach I don't necessarily mean 'follow existing
practice' but any new approach should have clear advantages over existing.
So in TRANS, the spec is built into PKIX and uses ASN.1 where this is
appropriate. But noting that TLS is built on a different encoding and
schema language which is better (in the same way that stopping hitting
yourself on the head with a hammer is better than continuing), TRANS uses
the TLS approach rather than ASN.1.

I don't see using DNSCurve as it is to be an option. At minimum we would
need thorough documentation. But I think we would also want to align
DNSCurve with the rest of the IETF infrastructure. In particular consider
using existing DNSSEC or TLS or PEM code points to describe algorithms.

Once you get into documenting a protocol, the need for a schema language
becomes clear. In the 18 years its been public I have never once heard
anyone say that the TLS schema or encoding was problematic in any way. It
certainly makes the spec a lot easier to follow.

People can of course argue that the logical conclusion of being IETF
compatible would be to 'simply' use DTLS. But that is only the easiest
approach if you are already committed to having a TLS library. Which is
fine for a desktop but a really bad commitment for an embedded device. My
proposal does cheat by reusing TLS right now and that is a completely
defensible long term strategy for desktops, mobile devices etc. I do not
think that is a defensible long term choice for DNS which needs to be a
very simple protocol that can be implemented in a few thousand lines.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 21 Oct 2014 11:18:41 +0200

On Mon, Oct 20, 2014 at 07:02:01AM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 23 lines which said:

> And, after many attempts by people here, it is still
> undocumented. The is a bit of a protocol description, but it is
> fairly incomprehensible,

I did not say it was documented, just that it was deployed.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Oct 2014 07:42:11 -0700

> On Oct 21, 2014, at 2:18 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Without documentation, we have no proof of that. When I look at the supposed documentation for the supposed port, I see something that is not a port of DNSCurve at all, just something that uses the same encryption algorithm. This is important because DNSCurve is not just an encryption algorithm, it is also a key exchange mechanism, and its proof of security relies on both parts.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Oct 2014 10:27:03 -0700

On Mon, Oct 20, 2014 at 10:11 AM, Phillip Hallam-Baker
<[email-masked]> wrote:
> appropriate. But noting that TLS is built on a different encoding and schema
> language which is better (in the same way that stopping hitting yourself on
> the head with a hammer is better than continuing), TRANS uses the TLS
> approach rather than ASN.1.
>
> need thorough documentation.

Ok, so how about we say that it isn't a solution that we are currently
considering, but if folk fully document dnscurve / dnscrypt in a
draft, and bring it to the IETF / DPRIVE we will might consider it
(and, obviously if it becomes a WG item, change it to meet the our
requirements...)

This has been (IMO) a really interesting / useful conversation (and
I've been suitably hit with the cluebat^w^w^w^w educated), but let's
also have a look at Stephane's "DNS privacy considerations" -
https://datatracker.ietf.org/doc/draft-bortzmeyer-dnsop-dns-privacy/

This technically in a Call for Adoption till Friday, but it is fairly
clear that it will be adopted. So, let's start beating on the doc --
AFAICS, it looks about baked (I have an edit buffer with some tiny
nits), and complete. Anyone have any substantive issues or changes
that they'd like made?

W

> But I think we would also want to align
> approach if you are already committed to having a TLS library. Which is fine
> for a desktop but a really bad commitment for an embedded device. My
> think that is a defensible long term choice for DNS which needs to be a very
> simple protocol that can be implemented in a few thousand lines.
>

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Oct 2014 17:41:05 -0400

Hi all,

Here is the current (draft) agenda.

We had hoped that there would be more time for general discussion, etc
but we got sufficient calls for time that we have basically no slack;
as it is we've had to squeeze some folk's time.
If you are listed below, and don't need your full time slot, please
let us know, so we can redistribute it....

DPRIVE - TUESDAY, November 11, 2014 - 1300-1500 Afternoon Session I - Coral 5120

Administrivia
Warren and Tim
10 minutes

draft-bortzmeyer-dnsop-dns-privacy
Stephane Bortzmeyer
25 minutes

Idea: a draft on methods of evaluating DNS privacy
Allison Mankin
10 minutes

PRIVATE-DNS
Phillip Hallam-Baker
20 minutes

TLS for DNS: Initiation and Performance Considerations
Allison Mankin
25 minutes

draft-hoffman-dprive-dns-tls-{alpn,https,newport}
Paul Hoffman
25 minutes