Subject: [dnsext] Presentation on DNSSEC that Google brought to my attention

From: Alan Clegg <[email-masked]>
Date: Thu, 27 Aug 2009 20:29:27 -0400

I have a google alert set for "DNSSEC" and was rather interested by the
document that it brought to my attention today.

Good points brought up (one at my expense, I must say) on a number of
things, but some minor errors (particularly page 64).

Thought folks might be interested.

    http://cr.yp.to/talks/2009.08.10/slides.pdf

AlanC

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 27 Aug 2009 17:43:59 -0700

> things, but some minor errors (particularly page 64).

Out of curiosity, what's the error?  E.g., if you run "dig +dnssec
www.dempsky.org @a0.org.afilias-nst.info", how does a validating
resolver reject forgeries?  The .org name servers aren't currently
signing the NS or A record sets, as far as I can tell.

---

From: Alan Clegg <[email-masked]>
Date: Thu, 27 Aug 2009 20:59:07 -0400

> signing the NS or A record sets, as far as I can tell.

Parental NS and glue records are never signed as they truly "exist" in
the child zone.

However, if you forge them, a correctly validating resolver will note
the DS record in the parent and expect the actual zone to include the
appropriate KSK.  From there you validate ZSK and related signatures.

You can't just "sidestep" by forging NS+A in parent.

AlanC

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 27 Aug 2009 18:13:42 -0700

> appropriate KSK.  From there you validate ZSK and related signatures.

So as a sniffing attacker, I can't trick you into accepting signed
bogus DS records (and so no bogus records in the child zone), but I
could forge a million responses, each with different bogus NS and A
records.  How does the client handle this?  Just give up?

> You can't just "sidestep" by forging NS+A in parent.

You can until registrars allow you to add DS records.  I notice
isc.org has DS records, but I just checked GoDaddy, and I couldn't
figure out how to add them for dempsky.org.  (Maybe I'd have to
transfer to another registrar?)

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 27 Aug 2009 18:54:32 -0700

> records.  How does the client handle this?  Just give up?

As a sniffing attacker, frak-targeting DNS, just do direct TCP packet  
injection on the data protocol and be happy.

---

From: Alan Clegg <[email-masked]>
Date: Thu, 27 Aug 2009 22:04:38 -0400

> transfer to another registrar?)

Correct.  DNSSEC is not fully deployed yet.  You won't find a registrar
that can accept DS records for .ORG yet.

AlanC

---

From: Matthew Dempsky <[email-masked]>
Date: Thu, 27 Aug 2009 19:22:01 -0700

> injection on the data protocol and be happy.

Sure, higher-level protocols need to be made secure and available too.
 Making DNS secure and available is a first step towards that.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Aug 2009 02:58:49 +0000

> Date: Thu, 27 Aug 2009 22:04:38 -0400
> From: Alan Clegg <[email-masked]>
> 

meanwhile, see <https://www.isc.org/solutions/dlv> for a workaround.

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 28 Aug 2009 20:57:50 +0900

> things, but some minor errors (particularly page 64).

That's quite interesting. Though not very accurate.

The truth is that, though the document says:

	1994.02 Eastlake-Kaufman,
	after months of discussions on
	dns-security mailing list:
	"DNSSEC" protocol specification.

Eastlake-Kaufman avoided the discussion in the mailing list only
to produce a quite defective protocol subtly but fatally not
compatible to the existing DNS specification in various ways,
including, but not limited to, MTU and referral issues.

So, I proposed, in 1994.08, a proper document
draft-ohta-simple-dns-00.txt reflecting the discussion.

And, though the document says:

	Continued DNSSEC efforts
	received millions of dollars
	of government grants:

The result, after wasting many years, is essentially identical to
draft-ohta-simple-dns-00.txt, which was admitted by the WG recently
(about one or two years ago), though there may still be some defects
remaining.

Luckily enough, the wasted millions of dollars is not of my
government.

Even more luckily, as PKIs, including DNSSEC, are not end to end
but weakly secure, that is, as secure as plain old DNS, it's a
blessing that my complete proposal was not deployed in time only
to make domain name registration unnecessarily complex and expensive.

						Masataka Ohta

---

From: João Damas <[email-masked]>
Date: Fri, 28 Aug 2009 15:14:38 +0200

> that can accept DS records for .ORG yet.

yet, there are some ways of getting DS records during this limited  
entry time. I can count 25 DS records in the .org zone right now,  
including bondis.org, sanog.org and others. Not yet mainstream, OK,  
but one more step in the phased introduction of DS records in .org
I am sure some registrars will allow DS records some time soon

Joao

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 11:27:42 -0400

No hat.

> records.  How does the client handle this?  Just give up?

By way of analogy, as a sniffing attacker you can't trick me into
accepting bogus keys for the other end of my attempted SSH connection,
but you can dump all kinds of fake bogus hanshake attempts on me.
Yes, I give up.  Your rhetorical question appears to be suggesting
that's a bad idea.  I think I disagree.

You're right to observe (as is Dr Bernstein) that there is very little
security added today for most zones under .org because .org is signed.
I'm not sure I have seen a protocol that instantly helps everyone
during the period it isn't finished being deployed, but perhaps you
(or Dr B.) knows of one.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 09:59:39 -0700

> but you can dump all kinds of fake bogus hanshake attempts on me.

That's because SSH (as commonly used) doesn't have security
guaranteeing availability yet.  Two possible solutions available today
are to use IPsec and TCP MD5 sigs.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 13:23:16 -0400

No hat.

> are to use IPsec and TCP MD5 sigs.

At which point you move the problem up the stack: when I am setting up
my IPsec connection …

The basic problem here is that an on-path sniffing attacker can
_always_ perform DoS.  I cannot believe that's news to anyone, or even
that anyone thinks it possible to completely prevent this without a
fairly radical rethinking of the meaning of "path".  Nothing wrong
with that, of course, but it will make rather difficult _ad hoc_
networking between end points previously unacquainted with each other.

I would be very happy to be shown wrong in my assumptions above.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Aug 2009 13:54:39 -0400 (EDT)

> document that it brought to my attention today.

Here are my comments to the slides. Feel free to use it anywhere. Not
sent to DJB himself because his email server requires some kind of
non-RFC opt-in spam reply, and I'm refusing to be his mechanical Turk
in combating his personal spam problem.

Slide 1-13 is simply FUD. Using the same analogy, we can see that there
are about 0 instances of "dnscurve", so it must be in a worse development
state. (dnscurve.org nameservers are not using a dnscurve NS record)
It also assumes that like with dnscurve, the entire path of trust must
be present. With DNSSEC there is no such need, and Dr.B cannot see how
well deployed DNSSEC is based on 1 DNSSEC key found somewhere. DNSSEC
simply does not need that universal deployment that dnscurve depends on.

Slide 14-24 is misrepresentation. DNSSEC is only enabled when you ask for
it. This is to ensure full backwards compatibility. That same backwards
compatibility was a design goal with dnssurve. Dr.B needs to make up his
mind whether that is a good thing or not. He can't have to cake and eat
it too.

Slide 25-34 is more FUD about amplification attacks. He locates DNSSEC
capable authoritative DNS servers and assumes he can query them as a
recursive nameserver, and then jumping to many conclusions. This is the
same as me writing a script that collects IP addresses from domains having
an MX record, and sending a 10 MB email spoofed From to twitter.com. I
have just caused a million-fold amplification attack.... Of course this is
not true, since email servers don't just accept any email for forwarding,
just as those DNSSEC capable servers don't just recurse for everyone.

Slides 35-51 are about information leakage with DNSSEC, either with
trivial NSEC or with easy NSEC3. However, in a non-DNSSEC zone, it is
as easy to send discovering queries for names and check for NXDOMAIN.
The fact is, DNSSEC with NSEC3 does not make things worse then non-DNSSEC.
Dr.B complete ignores this point by throwing in some irrelevant math.
And dnscurve in this case performs equally bad as non-dnssec. I can just
query. In fact, it is worse, because with dnscurve, i cannot use caches,
but have to query the NS records directly, so multiple people trying to
do this would hit a dnscurve setup much harder then a non-dnssec or dnssec
setup.

Slides 52-59 deal with stripping DNSSEC information and re-using
signatures using an vix.com example. It is very misleading. DNSSEC
protects against this case easily. One could use short signature times
during a move. One could do a KSK rollover at the time of IP change. One
could change the nsec3parms and use a new salt. But what it really comes
down to is that no one would give away that IP space before all records
with that IP in it would be expired from caches to begin with. Or else
you would be down for a number of hours/days depending on the TTL values.
In other words, it is an imaginary problem

Slides 60-61  talk about cryptanalysis.
1024 bit RSA signatures are used for about 30 days. That would cover
according to Dr.B an investment of $120M to crack in 30 days, so it would
need more to crack it and find the key still in use. If this was really
feasible, people can instantly upgrade their crypto algorithm (unlike
dnscurve I might add, which is still on 1 "trust djb" elliptic curve) or
key size and rollover. If attacks becomes feasible, DNSSEC is a much more
flexible candidate to move to a new crypto standard then dnscurve is.
Furthermore, Dr.B is on purpose mixing up the use of RSA in long term
encryption, versus its use in signatures. The RSA Inc and NIST recommendations
are most important for encryption, since you need to prepare for the future.
With DNSSEC signatures, you can change your key size safely in a few days.
What's the crypto migration path for dnscurve? It is "trust djb breaks
his own curve before anyone else does". There is no dnscurve specification,
so there is no crypto migration path whatsoever.

Page 62-64 talk about forging non-signed glue data. It is basically a DOS
attack against the enduser by a MITM. whether you strip just the signatures
or the entire DNS data does not matter. The result is the same. The enduser
cannot get to where he wants to go. The failure is identical with dnscurve.
After all, if the enduser does not get the data, he does not know where to go.

Page 65 talks about NSEC3 hashes. Apparently it is a problem that the .org
nameservers store millions of these. Somehow that affects DJB.

The biggest difference between dnscurve and dnssec is that dnssec protects
the authenticity of the data through insecure intermediate caches, where
dnscurve has to abolish the dns cache to function. Shall we bring up the
total amount of extra DNS queries that are DDOS'ing the internet at large
when dnscurve is deployed? The amount of DNS traffic would multiply far more
then a thousandfold. DSL routers with mini DNS implementations would not
even be possible anymore, because they do not have the memory capacity for
dnscurve (nor often the spare cpu cycles for crypto). With DNSSEC, they
can just proxy the DNS requests from the ISP.

> things, but some minor errors (particularly page 64).

I don't see a single good point of criticism in the entire paper. In fact, I'm
shocked that a CS professor would write such a "paper". I'd sincerely hope
he holds his own students to a higher standard, or else a CS degree is not
going to me amounting to much anymore these days.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 28 Aug 2009 13:57:56 -0400 (EDT)

> are to use IPsec and TCP MD5 sigs.

You forget SSHP DNS records secured by DNSSEC.

;; ANSWER SECTION:
xelerance.com.		3592	IN	SSHFP	1 1 023B462A48078FEDE5328D9BD9E7F1896CEF75A7
xelerance.com.		3592	IN	SSHFP	2 1 176851637907BFFD41D7E161A06D8F2EE14EF35D
xelerance.com.		3592	IN	RRSIG	SSHFP 5 2 3600 20090913135451 20090827133952 16187 xelerance.com. XcjubRLPtO4hG5gTrwVNw/yxM7rgC+FaVKayveftt/vtYKyMwRrNS+RP enDXsKEgPvEo/HAppORfssIlrb5JZNfH4XGEDq27fDnju/ytCjbrTWIY SIIqItbfFkWm1Et5rWaO8n9nkzXpxXqQ/fbHC1HPGE9ewEHxyOfnkiiX 6nU=

Paul

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 11:00:26 -0700

> You forget SSHP DNS records secured by DNSSEC.

Do those stop forged TCP FIN packets from a sniffing attacker?  I
thought they only encode the SSH public key, so the user doesn't have
to be prompted by "does this key look right".

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 11:17:33 -0700

> At which point you move the problem up the stack: when I am setting up

I know there are mailing list participants with more IPsec experience,
so I'll let them comment as to what availability guarantees IKE has
when the client is able to securely discover the server's public key
(e.g., through secured DNS).

> _always_ perform DoS.

Are you assuming the attacker can force packets to not reach their
destination?  If so, then yes.  Such an attacker can perform a DoS.
But otherwise, DNSCurve at least is resistant to sniffing attacks that
still permit legitimate packets through.

---

From: Alan Clegg <[email-masked]>
Date: Fri, 28 Aug 2009 14:33:44 -0400

Paul Wouters wrote:

> I don't see a single good point of criticism in the entire paper. [..]

The things that I referred to as "good points" are issues that are
already known:  traffic amplification and disclosure of zone data by
those unaware of how NSEC works.  These are bad things that we are aware
of and that those deploying DNSSEC should also be aware of.  We can't
deny that both of those issues do exist.

I agree that all of this was presented as "OH NO, THE WORLD IS ENDING",
and as such is poorly received by this community, but the points are
valid... if we don't inform people of these issues and do our best to
educate everyone as to "how things should be done" (BCP-38 comes to mind
for the first, and "gee, isn't that why we implemented NSEC3" for the
second), they will find out the hard way and turn around and blame
DNSSEC and those that implement it.

If it were not for the attacking manner of the paper (the FUD angle),
and the fact that he didn't contact me before complaining about how my
zone was configured incorrectly (it was, btw, but only in the fact that
I had accidentally disabled zone transfers), then I would recommend this
as a "the more you know, the better off you are" type of presentation.

AlanC

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 11:46:16 -0700

On Fri, Aug 28, 2009 at 10:54 AM, Paul Wouters<[email-masked]> wrote:
> DNSSEC simply does not need that universal deployment that dnscurve depends on.

DNSCurve doesn't depend on universal deployment either.  You can setup
DNSCurve trust anchors just like you can setup DNSSEC trust anchors.

> recursive nameserver, and then jumping to many conclusions.

He's not querying them as recursive nameservers.  He's asking them for
large (authoritative) DNSSEC responses, and measuring how much query
traffic vs. how much response traffic he saw.

> The fact is, DNSSEC with NSEC3 does not make things worse then non-DNSSEC.

http://www.dnscurve.org/espionage2.html discusses this in more detail.

> In fact, it is worse, because with dnscurve, i cannot use caches,

Paul Vixie has stated he's not concerned about this for the root
servers at least.  To quote:

    bring it on.  we get way more queries from people who don't cache at all, or
    from people who firewall our answers even though they fail to firewall their
    own questions, then we would ever see from a change wherein every
host on the
    internet became its own caching recursive nameserver.  bring it
on.  (really.)

As for end zones, if you can't handle one DNS query per unique user,
how can you handle X HTTP/HTTPS or SMTP or whatever requests per
unique user?

> need more to crack it and find the key still in use.

I'll admit some DNSSEC ignorance here: I thought only DNSSEC
signatures are regenerated every 30 days.  Will the zone signing and
key signing keys be rolled every 30 days too?

> If this was really
> feasible, people can instantly upgrade their crypto algorithm

Really?  From the conversations here, everyone seems terrified at the
idea of upgrading crypto algorithms.

> (unlike
> dnscurve I might add, which is still on 1 "trust djb" elliptic curve)

The "trust DJB" elliptic curve follows all of the NIST recommendations
on public key cryptography.  Additionally, NSA has withdrawn
recommendations on using RSA.

By today's cryptanalysis, breaking a 255-bit elliptic curve is
comparable in effort to factoring a 3000-bit RSA key.

> If attacks becomes feasible, DNSSEC is a much more

DNSCurve is flexible to new crypto standards the same way DNSSEC is.
You add a way to encode a hypothetical DNSCurve2 public key, a client
can then search for either DNSCurve or DNSCurve2 public keys, and then
use whichever is available.

Bonus benefit: authoritative servers can track which formats clients
support, so they can drop DNSCurve support once everyone is using
DNSCurve2 instead.

My understanding is there's no way to tell how many DNSSEC clients
support RSA-SHA2, so authorities won't know when they can drop support
for RSA-SHA1.  Please correct me if this is wrong.

> There is no dnscurve specification,

There's a web site, there's an Internet-Draft, and there are several
interoperable implementations.  What more do you want?

> cannot get to where he wants to go. The failure is identical with dnscurve.

False.  DNSCurve authenticates the packet, so the cache rejects forged
responses and continues waiting for the legitimate response.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 14:57:16 -0400

No hat.

On Fri, Aug 28, 2009 at 11:17:33AM -0700, Matthew Dempsky wrote:
> destination?  If so, then yes.  

Uh, well, yeah, since you were talking about an on-path sniffing
attacker.  But supposing they can't force lost packets …

> still permit legitimate packets through.

…I don't understand this claim anyway.  Cryptographic signatures are
there so that A can tell whether the signed data B sent A is legit.
Your original point appeared to be that it was trivial for an in-path
attacker to substitute forged data, and therefore deny service under
DNSSEC because validators will detect it and not go to the proffered
address.  That's a DoS open to _any_ validation-of-source-data system,
and I cannot begin to fathom how DNSCurve or, indeed, any other system
purporting to assure the authenticity of data is not susceptible to
this attack.  If you or Dr B. have invented some way to prevent that
style of attack, I would be _very very_ grateful for you to explain
how it solves the fundamental problem, because it sounds to me very
close to magic.  I'd be happy -- really happy -- to be wrong about
that, but anytime I hear someone claim, "No DoS here," I am tempted to
set up an experiment.  So far, I've been beaten to the punch every
time by people already exploiting the hole in question.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 12:10:45 -0700

On Fri, Aug 28, 2009 at 11:57 AM, Andrew Sullivan<[email-masked]> wrote:
> …I don't understand this claim anyway.

Suppose a sniffing attacker that can inject malicious packets but
cannot stop legitimate packets from reaching their destination.

Using just DNSSEC: I send a query for www.ietf.org to the .org name
servers.  The sniffing attacker sees this query, and sends me a
response with a valid DS record, but with bogus NS+A records.  The
client accepts this delegation, and then sends www.ietf.org queries to
some other IP address where they're lost.  The user can't reach
www.ietf.org.

Using DNSCurve: I send a query for www.ietf.org to the .org name
servers.  The sniffing attacker sees the packet, but any forged
responses will be discarded because they don't contain a valid MAC.
The client continues waiting until it receives a valid response packet
or times out.  Once receiving the valid ietf.org delegation, I can
then contact the ietf.org servers.

Does that help?  If not, I'll try to clarify further.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 28 Aug 2009 15:45:54 -0400

On Fri, Aug 28, 2009 at 12:10:45PM -0700, Matthew Dempsky wrote:

> response with a valid DS record, but with bogus NS+A records.

How does the "valid DS record" get signed by the attacker?  Actually,
this is a subtle point and is missed by many, but RFC 4034 says
clearly, "The DS RR appears only on the upper (parental) side of a
delegation, and is authoritative data in the parent zone."  In other
words, it is parent-sourced data, and therefore subject to
authentication under the parent's key.  If you can't do it, then the
result is treated accordingly.

> or times out.

In other words, if packet-fiddling is detected then either (1)
non-fiddled responses win or (2) user can't get to target.  At least,
that's how I read this.  Correct me if I'm missing something.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 13:50:21 -0700

On Fri, Aug 28, 2009 at 12:45 PM, Andrew Sullivan<[email-masked]> wrote:
> How does the "valid DS record" get signed by the attacker?

By valid, I meant legitimate; i.e., copied from a legitimate response
packet.  An attacker can easily get this from sending a query to the
authoritative server and extracting the DS record from the response.

Because the NS and A records point to bogus IPs, it doesn't matter
that the client got a legitimate DS key.  The goal of this attack is
to merely disrupt availability of the target domain name; it doesn't
attempt to forge records for the target domain name at all.

> that's how I read this.  Correct me if I'm missing something.

I believe that's a correct interpretation.  The point is that
packet-fiddling is detectible, so fiddled-packets are simply ignored.

---

From: Matthew Dempsky <[email-masked]>
Date: Fri, 28 Aug 2009 14:20:04 -0700

> recommendations on using RSA.

Apologies, Paul Hoffman pointed out to me off list that these
statements are inaccurate.

It's actually the IEEE that gave recommendations (in P1363) on how to
select secure elliptic curves, and it's these recommendations that the
standard NIST curves followed in selected the P-256, etc. curves.
Curve25519 also follows the recommendations of P1363, but it is not a
standard NIST curve.

NSA's Suite B standard withdraws their former recommendation for RSA
in favor of two of the NIST curves, but it does not recommend
Curve25519 either.

The intended take away from this is that Curve25519 follows the same
recommendations that were used in selecting the elliptic curves that
NSA recommends, but I never meant to imply NIST or NSA actually
specifically recommend Curve25519.  Just that if anyone is comfortable
with still using RSA, they should be comfortable with Curve25519.

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Mon, 31 Aug 2009 09:49:40 +0200

> packet-fiddling is detectible, so fiddled-packets are simply ignored.

So, couldn't the NS record with the public key in it be spoofed?
The query is sniffed that would result in the NS record getting
returned.  And a fake reply is injected.

With fake NS (with fake keys and fake A records): so that
the victim goes there; receives valid dnscurve stuff, but bad data.

Or the real NS but with fake A records: the victim goes there
but won't receive any valid data: DoS.

Fake NS and A records can be blindly spoofed too.

Best regards,
   Wouter

---

From: Matthew Dempsky <[email-masked]>
Date: Mon, 31 Aug 2009 00:55:50 -0700

> returned.  And a fake reply is injected.

Assuming the query to the parent name server uses standard DNS, then
yes.  However, that's no different from DNSSEC and its DS records.

The same way caches can be configured with DNSSEC trust anchors, they
can be configured with DNSCurve trust anchors.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Aug 2009 14:15:31 -0400

> can be configured with DNSCurve trust anchors.

I'm feeling even more dense than usual, but this sounds to me like
you're now saying DNSSEC and DNSCurve have the same property here: if
an on-path attack happens, it can result in a DoS, because you detect
the attack and reject the data as illegitimate.

I don't see why this is supposed to be a big deal: it was the _goal_,
in fact, to detect bad data and refuse it.  Of course that results in
a possible DoS from an on-path attacker.  I have never heard of a
data-alteration-detection mechanism that can't result in denial of
service, in the event there is detected an alteration.  The principle
is generally that it is better to be turned off than to go to the
wrong destination.  Again, however, I'd be happy to be corrected.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.