Subject: [dnsext] Channel security in general

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Tue, 09 Mar 2010 12:55:54 +0100

Hi,

The discussion on DNSCurve seems to have stopped due to administrative
matters.  Hence this email.

In general, the use of cryptography to protect the channel between two
nameservers is a worthy topic.  This is different from DNSSEC's
protection from zone-publisher to zone-consumer.  DNSCurve therefore is
not a replacement for DNSSEC in my opinion.  Below some points that
summarize my understanding.

a) The protection then protects against spoofing.  We have port
randomisation for that today.  It may be good to have 'just in case'.
Securing this with more than the 16 port bits but n bits is useful
(similar to EDNS-PING).

b) I am sceptical of the initial key exchange.  Perhaps a
DNSSEC-protected initial key exchange (something that Barwood's key RRs
could accomplish).  Weaver's concerns about a downgrade.

c) I also worry that the packet format causes backwards compatibility
trouble.  Use of EDNS to carry data may be advisable.  More downgrade
concerns.

d) Whatever crypto is used, the key does not last 100 years.  Therefore
key rollover must be specified.

e) Algorithm agility must be possible.  Maybe just tack this onto d).

f) global-anycast setups.  Having a symmetric key is interesting, but
has its problems.  This must be handled.

g) the easier local-anycast 'load-balancer' setup.  Machines from
multiple vendors must be able to synchonise if symmetric keys are held.

h) the resource consumption of symmetric keys (if used or negotiated).
Can be a problem for certain classes of nameservers.  Because of this
and points f) and g) I would prefer a system that does not negotiate a
symmetric key (unless it makes one per-response).  There are some
cpu-resource worries here.

i) encryption.  Contentious as the query-response is public data.  To
protect privacy it provides some very small benefit.  The traffic
analysis argument.  But it forces someone to do such traffic analysis
which raises the cost of privacy invasion.  Since the cost of having the
packet encrypted is very small (once you have established keys and
compared to signing its hash), and it gives a similarly small benefit, I
think it is worth having.

j) SIG(0) alternatives.  Deployment of nameserver channels between
different types of nameservers (stub, resolver, cache, ...).

Considering the above points I conclude that this issue has no
particular urgency.

Best regards,
   Wouter

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 09 Mar 2010 23:23:28 +0900

W.C.A. Wijngaards wrote:

> nameservers is a worthy topic.

As I pointed out in main ietf mailing list, DNSCurve is, like DH,
subject to MitM attacks, which should be a reason why their is
not much discussion.

> Securing this with more than the 16 port bits but n bits is useful

As DNSCurve has 96 bit message ID, it's enough to have DNSCurve
without Curve, that is, without elliptic curve cryptography.

							Masataka Ohta

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Mar 2010 08:02:12 -0800

>matters.  Hence this email.

I thought it stopped due to insufficient support and a lot of opposition.

>nameservers is a worthy topic. 

Fully agree. But just because DNSCurve is a proposal for that doesn't mean it is the only or best way to achieve it.

>This is different from DNSSEC's

In the IETF, channel integrity normally has 96 bits of strength or more.

>could accomplish).  Weaver's concerns about a downgrade.

The idea that an elliptic curve key, or a hash of an RSA key, is contained in the name that is in the NS record is wonderful. It proves that the parent where you got the NS from believes that the key or hash is associated with the zone. Dan Bernstein (or whoever came up with it before him, if it was not original to him) gets big points for this. It is an excellent way to simplify key distribution.

>trouble.  Use of EDNS to carry data may be advisable.  More downgrade

Fully agree. However, there are many ways to use a public key to add channel integrity that might not change the packet format.

>key rollover must be specified.

"The NS record in the parent changed". Done.

>e) Algorithm agility must be possible.  Maybe just tack this onto d).

Fully agree.

>has its problems.  This must be handled.

Fully agree, and this will cause the most concern. It inherently means sharing the private key among all the supposedly-identical servers. I believe that is impossible for symmetric keys that are being generated on the fly.

>multiple vendors must be able to synchonise if symmetric keys are held.

Ditto.

>cpu-resource worries here.

Fully agree.

>think it is worth having.

And here we strongly diverge. It won't work in the current Internet with middleboxes, and without a way to do end-to-end signalling saying "I need to fall back to unencrypted at this point in the chain, is that OK", it is silly to even get started. Further, there are zones who for legal reasons will not be allowed to encrypt: how will they interact with the rest of the system?

>different types of nameservers (stub, resolver, cache, ...).

Yep. This could go that way.

>Considering the above points I conclude that this issue has no

Yes, but it is still interesting.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 9 Mar 2010 08:41:02 -0800

> "The NS record in the parent changed". Done.

Actually, that doesn't work:  

NS records are cached, often for a fairly long time (day+).

A key-rollover requires stating that "both the old AND the new key are valid", because the server needs to keep using the old key until it knows that its expired out of all clinet caches before switching to the new key, since DNS doesn't have a method of saying "this is a request for server X" (unlike HTTP).

So with DNSCurve's method of "key rollover", there is an outage of NS RRSET TTL as either cached or uncached resolvers will see the wrong key in the response.  

The "solution" would be to have two versions, and the DNSCurve resolver would have to decide to accept both versions.  Which is a hastle and ugly.

This is exactly why keys should be in their own RRType, not encoded in NS records, because resolvers need to be able to see both the old and the new in the RRSet and accept both during the rollover period.  Encoding in the NS name is frankly, not a good idea.

Especially since this requires BOTH resolver and authority changes, so there is no issue in deploying a new RRType for such data.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Mar 2010 09:01:37 -0800

>Actually, that doesn't work: 

Actually, I believe that does if you remember that the protocol has not yet been specified, and that we can learn from decades of security protocol experience in the rest of the IETF.

>NS records are cached, often for a fairly long time (day+).

Sure

>A key-rollover requires stating that "both the old AND the new key are valid", because the server needs to keep using the old key until it knows that its expired out of all clinet caches before swit…

That's not true if your protocol has that the querier tell the responder which key it expects the responder to use (the first two octets is sufficient for differentiating all the keys that the responder might be using).

>So with DNSCurve's method of "key rollover", there is an outage of NS RRSET TTL as either cached or uncached resolvers will see the wrong key in the response. 

There is only an "outage" if the protocol is lazy; there is no need for that.

>The "solution" would be to have two versions, and the DNSCurve resolver would have to decide to accept both versions.  Which is a hastle and ugly.

Why?

>This is exactly why keys should be in their own RRType, not encoded in NS records, because resolvers need to be able to see both the old and the new in the RRSet and accept both during the rollover…

We disagree here.

>Especially since this requires BOTH resolver and authority changes, so there is no issue in deploying a new RRType for such data.

Doing so breaks a fundamental security property of Dan's design, namely that when you ask a parent zone for how to reach a child zone, you get the key information from the parent zone. As long as you trust the information from the parent zone, you do not then need to do a leap-of-faith in getting the child zone's key. This eliminates an attack vector, namely an attacker who is on-path between you and the child but not between you and the parent.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Tue, 09 Mar 2010 17:22:51 +0000

> Date: Tue, 09 Mar 2010 12:55:54 +0100
> From: "W.C.A. Wijngaards" <[email-masked]>
> ...

"may be" and "just in case" are a weak argument supporting new compexity
in the standards, and are a better argument for the weaker variability
of dns-0x20 which asks only for a tightening of the response specification
to be "must copy QNAME bitwise".

because if what we really want is strong crypto between nameservers...

> could accomplish).  Weaver's concerns about a downgrade.

...then we would do as you say here, DNSSEC-protect the initial key
exchange, and then use SIG(0) for the transactions between nameservers.

> think it is worth having.

if what we want is transaction privacy then we need it in DNSSEC also, and
once having it there, we still would not need a new transport (DNSCurve).

> Considering the above points I conclude that this issue has no

agreed.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Mar 2010 10:17:29 -0800

> NS records are cached, often for a fairly long time (day+).

This is a problem for changing name server names and/or IP addresses
too.  If you want to change either of these, you have to support both
for a few days.  It doesn't seem unreasonable to me to do the same
with DNSCurve keys.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 9 Mar 2010 13:48:08 -0500 (EST)

> nameservers is a worthy topic.

"protect" is ambiguous in this use. Protect the authenticity or the privacy
or both?

> summarize my understanding.

One point not addressed by you were stub resolvers. Especially in the
absence of verifiable data in your forwarders, it becomes even more
important to do run a "validating" resolver on the stub. This would pretty
much mandate dnscurve on the end users system, and it would require
a complete new trust anchor distribution method in the absense of a
dnscurved root and a dnscurved lookaside method.

It is easy to criticize the encumbering parts of DNSSEC with an
alternative, if you don't address any of the actual problems. Especially
with dnscurve where you don't only have the last mile problem - you have
many last miles problems.

What it comes down to is that dnscurve only gives a very limited version
of query privacy at a very high cost in terms CPU usage, bandwidth usage,
protocol hackery and breakage, algorithm and cipher agility, bootstrap
problem, and topped with a litigation sauce.

If this had been proposed by John Doe instead of Bernstein, it would have
died a lonely and quiet death.

But thanks to Wouter for the factual summary.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 09 Mar 2010 20:03:49 +0000

> Date: Tue, 9 Mar 2010 13:48:08 -0500 (EST)
> From: Paul Wouters <[email-masked]>
> 

i dunno.  but i do hope IETF will undertake an examination of bernstein's
curve as a possible algo for DNSSEC.  the signatures would be smaller and
it would take a lot less CPU time to generate or validate them.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 9 Mar 2010 13:21:39 -0800

> multiple vendors must be able to synchonise if symmetric keys are held.

Note that neither of these are a concern for DNSCurve, because there's
no state on the authoritative side that needs to be carried between
separate requests.  As an optimization, however, authoritative servers
could share their Curve25519 shared secret caches.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 9 Mar 2010 14:16:14 -0800

>it would take a lot less CPU time to generate or validate them.

Curve25519 signatures are no smaller than P256 signature. It probably takes somewhat less time to generate and validate them.

The IETF doesn't usually do original research on new cryptographic algorithms like Curve25519; we rely on the rest of the cryptographic community to do so. There is very little research published on Curve25519, mostly by Dan Bernstein himself. P256 has been review to a much greater degree. This doesn't mean that there is anything wrong with Curve25519, just that choosing it over P256 would be somewhat odd in the current IETF process.

--Paul Hoffman, Director
--VPN Consortium

---

From: Doug Barton <[email-masked]>
Date: Tue, 09 Mar 2010 14:22:00 -0800

On 3/9/2010 3:55 AM, W.C.A. Wijngaards wrote:
> matters.

In my mind it's a non-starter, and others have already put forth 
persuasive arguments as to why.

Doug

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/