Subject: How do we get the whole world to upgrade to DNSSEC capable resolvers?

From: Ben Laurie <[email-masked]>
Date: Wed, 23 Jul 2008 17:15:48 +0100

Oh, I think we just did that.

Next step?

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Wed, 23 Jul 2008 17:52:15 +0100

> Oh, I think we just did that.

Doh, we forgot to make the world upgrade to serve DNSSEC data.

> Next step?

See above.

Alex

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Jul 2008 10:25:23 -0700

> Oh, I think we just did that.

Actually, I suspect not, since I would guess this event has increased  
the number of dnscache sites out there.  And PowerDNS (also unaffected  
by the vulnerability as I understand it) doesn't support DNSSEC  
either, right?

Regards,
-drc

---

From: bert hubert <[email-masked]>
Date: Wed, 23 Jul 2008 20:32:27 +0200

> by the vulnerability as I understand it) doesn't support DNSSEC  

Correct - my reasoning can be found on
http://ds9a.nl/dnssec/index.html#id2467146

Some older stuff: http://ds9a.nl/secure-dns.html

DNS is part of the long chain from a named service to a physical server:

1) ARP to find the hardware serving the router/nameserver IP
2) DNS to find the server IP
3) BGP to find the link to the destination AS
4) (TCP/)IP to the actual server
5) Content

Everybody who really cares about information security handles it in the
application that deals with the content, and is close to the user. All the
steps underneath have traditionally been plaintext, and have only been
hardened enough to be secure enough that casual tampering is ruled out.

Because we use real crypto for our important content anyhow, crypto that
does authentication, this is not a problem.

1) ARPSEC has been proposed, but never went anywhere. Switches implement
port security measures.
2) DNS has been hardened using random source ports
3) BGP has suffered the MD5 scare, and has now been hardened using TTL-checks to keep out
strangers
4) TCP/IP has been hardened by making sure everybody uses unpredictable sequence numbers.

You can see where this is going.

DNSSEC would be the most complex protocol ever deployed on such a scale on
the internet [1], with far reaching administrative and computational
consequences for everybody, yet it would sit all the way down there in the
stack.

I wouldn't put any faith in secure DNS alone.

So - DNS needs only to be strong enough to not be easily subverted in the
process of transporting plaintext unauthenticated data. This puts an upper
bound on the overhead (financial, technical and administrative) that we
should commit to DNS security.

And I firmly believe some simple measures will bring DNS to the required
level of robustness against tampering, and that these simple measures will
fit in the the 'overhead budget' mentioned above. [2]

I also firmly believe DNSSEC will impose an order of magnitude more hassle
than the world is willing to bear.

	Bert

[1] The telephony world beats us hands down though. Think H.323 or SS7.
[2] EDNS PING extra entropy, with gradual fallback to TCP to be introduced
to give everybody the opportunity to deploy. Fallback to TCP in case of a
single question-response {id,source-port} mismatch might even be enough!

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jul 2008 12:07:13 -0700

> should commit to DNS security.

So how to I avoid a situation where, when I type "http://www.bankofexample.com/ 
" in the URL bar of my browser, I get a web page from a phisher who  
provides me with a perfectly valid-looking but completely un-secured  
web site that will phish my password?   Even if your bank ordinarily  
puts up a secure form, if a phisher can subvert your DNS, they can do  
this.

Lest you claim "that's no problem, because people know not to submit  
private data to non-secure forms," answer me this: how often do you, a  
security-savvy person, actually look to see if you are submitting to a  
URL that uses SSL?   Now, how often do you think your friend the  
perfectly intelligent non-computer-geek does it?   How often does your  
elderly great aunt who had a stroke last year check?

Maybe DNSSEC is the wrong answer to this question.   But there needs  
to be an answer.   And it can't be "that's the user's  
responsibility."   Good security does not depend on user education.

---

From: bert hubert <[email-masked]>
Date: Wed, 23 Jul 2008 21:16:36 +0200

On Wed, Jul 23, 2008 at 12:07:13PM -0700, Ted Lemon wrote:
> So how to I avoid a situation where, when I type 
> "http://www.bankofexample.com/ " in the URL bar of my browser, I get a web 
> page from a phisher who  provides me with a perfectly valid-looking but 
> completely un-secured  web site that will phish my password?   Even if your 
> bank ordinarily  puts up a secure form, if a phisher can subvert your DNS, 
> they can do  this.

Ted - correct. So we must make sure it is very hard to subvert DNS, and in
short order too! Like within a year. Port randomization buys us some time,
but not a lot.

DNS security is important, and it must be hard to mess with the DNS. How
about: it takes people that can inspect packets and modify them in transit.

Because these people can do almost everything already - we can focus on
making sure DNS can't be hijacked by people unable to inspect and modify
packets.

I dare anybody to subvert the DNS+32 bits of additional entropy without
being able to inspect and modify packets. To emulate this, run DNS over TCP
today, and see if you can spoof it.

> responsibility."   Good security does not depend on user education.

We are in full agreement here. DNS should at least not make this problem
worse!

	Bert

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Jul 2008 14:14:10 -0700

Bert,

> today, and see if you can spoof it.

People have spoofed TCP streams remotely in the past, but that is  
somewhat irrelevant.

You are constraining the problem so the solution you prefer fits.  The  
reality is that the problem goes beyond your constraint, even today.   
For example, ISPs inspect and modify DNS packets in ways many end  
users find objectionable and there is no way for end users to  
programmatically detect this.

XID (et al) are simply more hacks that attempt to treat symptoms,  
trying to protect the transport.  The disease is lack of an ability to  
validate the data.  DNSSEC (for all its many warts and wobbly bits)  
does actually treat the disease.

Regards,
-drc

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jul 2008 08:39:02 +1000

> 2) DNS has been hardened using random source ports

	Which does not work well for large recursive servers due
	to port/descriptor exhaustion.

	Which also interacts badly with other ephemeral uses of UDP
	ports.  Spaying all the ports with late DNS/udp responses is
	not a good idea.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: bert hubert <[email-masked]>
Date: Thu, 24 Jul 2008 00:49:08 +0200

> 	to port/descriptor exhaustion.

Unsure what you refer to - this stuff has been in production for years now,
at high query levels (20-30kqps per IP address), without problems.

It takes some work, but high performance is never easy. It is a well solved
problem however (by now).

	Bert

---

From: [email-masked]
Date: Wed, 23 Jul 2008 23:51:36 +0000

> problem however (by now).

	high is a relative term, as in high-performance 286 computers
	with 128M of memory.

--bill

---

From: Mark Andrews <[email-masked]>
Date: Thu, 24 Jul 2008 12:05:34 +1000

> problem however (by now).

	Over how many concurrent ports without introducing queuing
	delays?

---

From: bert hubert <[email-masked]>
Date: Thu, 24 Jul 2008 08:07:44 +0200

> You are constraining the problem so the solution you prefer fits.  The  

No, it goes beyond that. I've constrained the problem to protecting DNS
against people that do not have the ability to intercept and modify your
packets.

This is not an arbitrary restriction. People that CAN modify your
packets in transit are a wholly different problem - they don't even need to
bother with DNS to mess with your traffic. They can do so directly. Not even
DNSSEC will stop them!

And this defines the natural bounding box for how secure DNS MUST be, and
with it a limit on the burden of securing it.

	Bert

---

From: bert hubert <[email-masked]>
Date: Thu, 24 Jul 2008 08:48:40 +0200

> 	Over how many concurrent ports without introducing queuing

This is rapidly moving outside of the scope of what most namedroppers
readers will find interesting, but PowerDNS uses 1 fresh socket per outgoing
query, by default up to 1024 simultaneous outstanding questions.

My dnsreplay experiments at such high speeds do not show an appreciable
queuing delay compared to lower query rates.

	Bert

---

From: Brian Dickson <[email-masked]>
Date: Thu, 24 Jul 2008 07:49:33 -0400

> bother with DNS to mess with your traffic. They can do so directly. Not even

I beg to differ.

The presumption you are making is, that (a) the people modifying the DNS 
are the same people hijacking
your traffic, and (b) that no benefit can be brought by use of DNSSEC in 
this scenario.

Allow me to provide a concrete example, typical of an IETF attendee who 
knows what they are doing.

Joe is attending an IETF. He stays in a hotel. He uses his laptop to 
access the internet via the hotel's network.

The hotel outsources their network stuff to a shady operator, who likes 
to hijack DNS packets so as to replace
ads with other ads.

All DNS traffic gets directed to a caching resolver that has been hacked 
for just such a purpose.
That hacked resolver is vulnerable to the Kaminsky attack, and is poisoned.

Joe has his own local recursive resolver running on his laptop, and 
wants to access his bank's web site.
He types in http://mybank.tld which should redirect him to 
https://special-thing.mybank.tld.

His resolver does its thing, but before it gets very far, the DNS 
queries it makes get intercepted, and bad
answers from the hacked box get sent back, instead sending him to 
https://phishing-site.tld.

DNSSEC makes this impossible.

Note that the ability to access packets in flight is irrelevant, so long 
as the proper DNS answers are served,
and redirects from non-https to https get done properly. Once the https 
is reached, TLS/SSL protects things,
but the key is reaching the right sight to start with.

Without the ability to handle non-https initiation URLs safely via DNS, 
it's all a house of cards.

Saying that not using https for everything, is blaming the victim.

So, in short, DNSSEC is the only answer that gets around this very real, 
very well known problem.

The idea of using other methods of hardening DNS resolvers is flawed, 
when not everyone operating
a resolver is necessarily strongly incented to harden their resolver 
(e.g. the hotel outsourcing folks).

> with it a limit on the burden of securing it.

I disagree that your choice is natural, and I disagree that it is 
sufficient.

Brian

---

From: [email-masked]
Date: Thu, 24 Jul 2008 14:31:05 +0000

> That hacked resolver is vulnerable to the Kaminsky attack, and is poisoned.

	so, hacked -twice- (at least)

> DNSSEC makes this impossible.

	hogwash.  he will get sent to https://phishing-site.tld.

	-IF- he validates and has the banks TA, then his browser -might-
	complain. 

	DNSSEC only gives one the ability to discern when the authenticity
	and integrity of the data has been compromised.  It provides zero 
	means to correct the problem.

> but the key is reaching the right sight to start with.

	er, right.  unless of course an earlier haq (additional data stuffing)
	has placed the SSL cert into young Joes browser. 

> So, in short, DNSSEC is the only answer that gets around this very real, 

	does not get around it, DNSSEC shines a light on an otherwise
	ambigious transaction.

> Brian

	that being said, i have been migrating all my DNS servers/services to
	be able to support DNSSEC.  I feel port randomization is a diversion
	but that might be a minority opinion. (yeah, i took the time to randomize
	ports)

--bill

---

From: Joe Abley <[email-masked]>
Date: Thu, 24 Jul 2008 10:51:03 -0400

On 24 Jul 2008, at 07:49, Brian Dickson wrote:

> answers from the hacked box get sent back, instead sending him to https://phishing-site.tld 
> .
>

Surely, DNSSEC making that impossible relies on the validator on Joe's  
laptop insisting that the TLD and MYBANK.TLD zones are signed, and  
that a trust anchor exists to verify the signatures.

If the validator on Joe's laptop has an empty cache, and no  
configuration which will make it insist particularly that those zones  
are signed, surely the middleware which is replying to queries could  
just return as if the root, TLD and MYBANK.TLD zones are unsigned. At  
that point there will be no signatures to verify, and it will be as if  
DNSSEC was never deployed.

[If the validator has cached security information from the results of  
previous queries, then it might be able to know that a lack of  
signatures received whilst in the hotel is a problem. But things  
expire from caches, laptops run out of power and get restarted,  
operating system patches require reboots, etc, so it doesn't seem  
reasonable to assume this will always be the case. "impossible" above  
is fairly absolute.]

I keep seeing people insist that query-intercepting middleware will be  
defeated with DNSSEC, but I can't see why. Perhaps I'm missing  
something.

Joe

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 25 Jul 2008 00:14:42 +0200

Joe Abley wrote:
> laptop insisting that the TLD and MYBANK.TLD zones are signed, and that
> a trust anchor exists to verify the signatures.
> 

how would you verify anything without a trust anchor?

I don't think anyone here implies that DNSSEC works when you do not
actually turn it on on the resolver you are using.

> defeated with DNSSEC, but I can't see why. Perhaps I'm missing something.
> 

It doesn't (in this scenario), but only because it actually does, and
Joe cannot resolve anything. Then he will probably turn it off.

Jelte

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jul 2008 13:03:05 -0400

> how would you verify anything without a trust anchor?

Surely that's a mechanical detail.

> actually turn it on on the resolver you are using.

The implication I was replying to seemed to state fairly clearly that  
DNSSEC would make it impossible for middleboxes to meddle with DNS  
queries and replies and provide answers that were not those that would  
be received from the authority-only servers concerned.

I think that's wrong. I think that once someone is in the position of  
being able to meddle with the query/response stream, all bets are off  
and DNSSEC is no cure.

What is required to circumvent such sabotage is not the ability to  
verify the integrity of the data in-band, but either the ability to  
signal that signatures should be present out-of-band, or a means of  
verifying transport integrity to a resolver which is trusted, or  
something. DNSSEC on its own isn't enough.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jul 2008 13:57:05 -0400

On 25 Jul 2008, at 13:37, Brian Dickson wrote:

> This would enable in-band resolvers to validate both the data, and  
> the presence or absence of zone signatures, on delegation chains,  
> and prevent downgrade attacks even by man-in-the-middle interference.

If the transport can't be trusted then the presence or absence of such  
markers surely can't be trusted either. Hence "out-of-band" in my  
previous note.

But I have not done very much thinking about this. I am mainly  
suggesting things as a way of learning. :-)

Joe

---

From: Brian Dickson <[email-masked]>
Date: Fri, 25 Jul 2008 13:37:19 -0400

> something. DNSSEC on its own isn't enough.

Would this be something analogous to the NSEC3 thing which gives the 
ability to "authenticate" NXDOMAIN responses by giving information about 
adjacent actual domains, modulo hashing to prevent zone enumeration?

I.e. something which would return authoritative "no DS record present" 
in a similar sense, with extra information to allow the receiver to 
trust the response (about no DS being present, that is)?

This would enable in-band resolvers to validate both the data, and the 
presence or absence of zone signatures, on delegation chains, and 
prevent downgrade attacks even by man-in-the-middle interference.

Well, not so much prevent, as much as make it obvious that it is 
happening, and to allow the resolver to reject suspect data when the 
signature has been stripped...

Brian

---

From: David Conrad <[email-masked]>
Date: Fri, 25 Jul 2008 12:24:09 -0700

Joe,

On Jul 25, 2008, at 10:03 AM, Joe Abley wrote:
> I think that's wrong. I think that once someone is in the position  
> of being able to meddle with the query/response stream, all bets are  
> off and DNSSEC is no cure.

The whole point of DNSSEC is to allow for the validation of responses  
by a validator to ensure they haven't been mucked with in transit.   
The most that an attacker, anywhere in a properly configured DNSSEC- 
protected query/response path, can do is denial of service.

Once the response leaves the validator on its way to the application,  
either via the response to an unprotected stub resolver call over the  
network or via a intra-machine IPC, it can, of course be mucked with.   
This is why I believe that if people want to be safe, they need to run  
a validating caching server on their local machine (if the intra- 
machine IPC can be compromised, you've got bigger problems).

But maybe I'm lacking context here...

Regards,
-drc

---

From: bert hubert <[email-masked]>
Date: Fri, 25 Jul 2008 21:31:01 +0200

> being able to meddle with the query/response stream, all bets are off  

Wow - sure? I may be no friend of DNSSEC but I always assumed DNSSEC would
be 'perfect' in this way.

If this is true, it only strenghtens the case that the hassle of DNSSEC
exceeds its merits by at least an order of magnitude.

	Bert

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jul 2008 15:36:15 -0400

> exceeds its merits by at least an order of magnitude.

I am feeling very ignorant right now, so let nobody take what follows  
as the voice of authority.

Imagine a world in the future in which the root zone is signed, and  
some TLD zones are signed, and some other zones are signed.

It seems to me that a bare validator, freshly started, with no cache  
and no special configuration, knows nothing about what zones in the  
world are secured and which are not.

If such a validator asks a question of a root server, or a TLD server,  
or some other server, and gets back an insecure referral, it seems to  
me the validator has no real way of knowing whether the insecure  
answers are from middleboxes, or direct from real infrastructure that  
happens not to have deployed DNSSEC.

Hand-configuring your validator to tell it "ORG is signed, root is  
signed, don't believe anybody who tells you otherwise" would  
presumably fix that. But replicating such dynamic information by way  
of static configuration in millions of independently-managed resolvers  
doesn't seem very scaleable.

Perhaps it's sufficient just to tell your validator "the root is  
signed, don't believe answers which suggest otherwise". But that  
requires a signed root, and in the mean time DNSSEC isn't providing  
any protection from middleboxes.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Jul 2008 18:10:02 -0400

[no hat]

On Fri, Jul 25, 2008 at 03:36:15PM -0400, Joe Abley wrote:

> It seems to me that a bare validator, freshly started, with no cache and no 
> special configuration, knows nothing about what zones in the world are 
> secured and which are not.

I thought, in any case, that the hypothetical case you were talking
about was a laptop in a hotel room.  Sure, there are people on this
list who know how to set up and configure a full validating resolver
for these purposes.  But the stub resolver is still dependent on
what's upstream, and that's what's going to be on a laptop, I think.
So if the compromise is on the network between the stub and the
validator, you're hosed.  (I thought this was the point someone
up-thread was making.  No?)

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/

---

From: Jelte Jansen <[email-masked]>
Date: Sat, 26 Jul 2008 01:07:52 +0200

> up-thread was making.  No?)

Exactly, if you cannot trust your resolver, or the so-called last mile,
you need to do your own verification, and for that you need to configure
your trust anchors, be it a set for a signed root, DLV, or plain manually.

Without any 'start of trust' configuration, DNSSEC wouldn't help if
you're in a hotel room. Luckily, without any configuration, DNSSEC won't
help you at home either. But with it, you should be able to use any
middlebox you *know* is in bad hands, and you'll still be able to know
whether or not the data you get is correct.

This is why people are pushing for a signed root, and this is why people
are pushing for automated trust anchor rollover (rfc5011).

Jelte

---

From: "Roy Arends" <[email-masked]>
Date: Sat, 26 Jul 2008 01:14:08 +0200

When a validator has a trust anchor configured for root, it _expects_ 
signatures for root. 

No signatures -> no validation -> data marked bogus -> client/stub gets 
servfail (*).

When a validator has a trust anchor configured for root, it expects 
signatures for root and _everything_ below until it hits a proof of 
absence of DS. This proof is given by NSEC/NSEC3 records and its 
signatures.

If something mucks in the middle, is either removing a sig or does fondles 
the data even one single teeny bit, ->

failed validation -> data marked bogus -> client/stub gets a servfail (*).

DNSSEC is perfect that way, in Berts terms.

Roy Arends
Nominet UK

(*) The client/stub has the option to query the validating resolver with 
the CD bit set, in which case the resolver may return bad/bogus data.

---

From: Joe Abley <[email-masked]>
Date: Fri, 25 Jul 2008 19:47:39 -0400

> your trust anchors, be it a set for a signed root, DLV, or plain  

Got it.

Joe

---

From: [email-masked]
Date: Sat, 26 Jul 2008 11:22:26 +0000

> protected query/response path, can do is denial of service.

	so, it does not matter where the data comes from, as long
	as the "wrapper" is intact.

> machine IPC can be compromised, you've got bigger problems).

	you are not alone in this belief.

> But maybe I'm lacking context here...

	this is no doubt true for many of us.

--bill

---

From: [email-masked]
Date: Sat, 26 Jul 2008 11:29:30 +0000

> world are secured and which are not.

	such a construct -might- be built, but of little or no use.
	this is analogous to a "bare" resolver with no cache or special
	configuration ... knowing nothing about where to send queries.
	without "belt/suspenders", the resolver is kind of useless.

> any protection from middleboxes.

	again, this is almost exactly the problem of maintaining 
	the root.cache file.  some folks maintain their copies by
	hand, some download from random sites (l.o.f).   

	the trick here is key maintainance/distribution.  its not
	a protocol issue.

--bill

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 26 Jul 2008 15:41:11 +0100

On Sat, Jul 26, 2008 at 01:14:08AM +0200,
 Roy Arends <[email-masked]> wrote 

> When a validator has a trust anchor configured for root, it _expects_ 

Which means there is no way back? If we sign ".fr", and people start
to configure the trust anchor for ".fr" in their validating resolvers,
we can no longer revert to the original, non-signed, system, should
problems occur?

Am I correct? AFAIK, DNSSEC has no way to express policies (in a
RFC5016-like way) such as "should be signed".

---

From: Brian Dickson <[email-masked]>
Date: Sat, 26 Jul 2008 12:21:47 -0400

> RFC5016-like way) such as "should be signed".

You are correct.

However, if the root was signed, there would be no need for having 
separate trust anchors configured
for a signed .fr.

And, this would mean that turning on or off the status of "is .fr 
signed?" could be handed from the root
zone, allowing *relative* ease in backing out the signing of any TLD. No 
configuration changes would
be needed by the operators of validating resolvers.

(IMHO, in addition to signing the root zone, there need to be changes to 
the speed with which changes
of a technical nature can be made, once the technical administration of 
a TLD has been authoritatively
and contractually delegated to an entity. Those include changes to A and 
AAAA glue records, and
addition/removal of DNSSEC signatures (and thus the 
"signed"/"not-signed" status).)

Brian

---

From: [email-masked]
Date: Sat, 26 Jul 2008 16:59:34 +0000

> separate trust anchors configured

	presuming facts not in evidence.
	how are you to -know- that the root has the "right" DS for .FR?
	most operational keystores will have at least four keys and likely 
	operational practice will be, roughly 3 per relevant org; the current,
	the immediate past, and the next future key.

	as a grad student, I will likely have keys from (at least) these places:

	my school, the parent org (.EDU), the root, the LIR, the RIR.

	that looks like 15 keys... :)

---

From: Matthijs Mekking <[email-masked]>
Date: Sat, 26 Jul 2008 23:22:52 +0200

> we can no longer revert to the original, non-signed, system, should

If you use a mechanism like described in rfc5011, there is a way back.
Section 5 says:

"A trust point that has all of its trust anchors revoked is considered
 deleted and is treated as if the trust point was never configured."

So you have to revoke your KSKs and give resolvers some time to update
their trust anchors.

- - Matthijs

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Jul 2008 02:52:53 +0100

> 	how are you to -know- that the root has the "right" DS for .FR?

Because if the root didn't, then it would imply the NSes or glue could  
also be wrong.  Same process will be used to vet requests to alter all  
of these.

Regards,
-drc

---

From: [email-masked]
Date: Mon, 28 Jul 2008 03:31:07 +0000

> also be wrong.  Same process will be used to vet requests to alter all  

	sure.  the point that i tried to make was/is, that DS verification
	is critical ...  regardless of where in the heirarchy one finds oneself.

	end of the day, it depends on the validators configured TAs.

--bill

---

From: Jesper G. Høy <[email-masked]>
Date: Tue, 29 Jul 2008 16:18:09 +0200

I second Bert's view on DNSSEC, and it is for much the same reasons that we
do not have DNSSEC in Simple DNS Plus either.

There may be other good reasons to push DNSSEC, but it really is overkill
for the Kaminsky bug IMHO.

The core problem with the Kaminsky bug, and other cache poisoning scenarios,
is the short 16 bit transaction ID.
So why not simply expand this ID to a secure length?
And not just ~16 bits (random ports) or 2+ bits (x020) - but really secure
length like 128 bits.

This seems a lot easier than getting DNSSEC in place, signing the root,
getting EVERYBODY to sign their zones, repeat for rollover, etc., etc.

Some will probably argue that this doesn't help against on-the-wire-attacks.
But if the bad buy is one-the-wire, then he can replace any data at will
anyway. DNSSEC is no help here.
Of course we already have SSL to solve that problem.

So why not keep DNS simple?

Am I oversimplifying matters?

Sincerely,
Jesper

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of bert hubert
> Sent: Wednesday, July 23, 2008 8:32 PM
> To: David Conrad
> Cc: Ben Laurie; DNSEXT WG
> Subject: Re: How do we get the whole world to upgrade to DNSSEC capable
> resolvers?
>

---

From: Alex Bligh <[email-masked]>
Date: Tue, 29 Jul 2008 15:49:43 +0100

--On 29 July 2008 16:18:09 +0200 "Jesper G. Høy" <[email-masked]> wrote:

> Some will probably argue that this doesn't help against
> on-the-wire-attacks. But if the bad buy is one-the-wire, then he can
> replace any data at will anyway. DNSSEC is no help here.

DNSSEC does indeed guard against on-the-wire attacks. What sort of attack
are you thinking of that it cannot guard against?

Alex

---

From: Jesper G. Høy <[email-masked]>
Date: Tue, 29 Jul 2008 17:05:09 +0200

If DNSSEC tell you (signed and secure) that my website is at 1.2.3.4 - the bad guy on the wire can still intercept and replace all the traffic from your browser to 1.2.3.4 and feed his own stuff back to your browser appearing to come from 1.2.3.4.

Having the correct IP address of my web-server is no guarantee that you are actually talking to the right server - when the bad guy is on-the-wire that is.

Jesper

> From: Alex Bligh [mailto:[email-masked]]
> Sent: Tuesday, July 29, 2008 4:50 PM
> To: Jesper G. Høy; [email-masked]
> Cc: Alex Bligh
> Subject: RE: How do we get the whole world to upgrade to DNSSEC capable
> resolvers?
> 
> 
>

---

From: Alex Bligh <[email-masked]>
Date: Tue, 29 Jul 2008 16:22:38 +0100

--On 29 July 2008 17:05:09 +0200 "Jesper G. Høy" <[email-masked]> wrote:

> If DNSSEC tell you (signed and secure) that my website is at 1.2.3.4 -
> the bad guy on the wire can still intercept and replace all the traffic
> from your browser to 1.2.3.4 and feed his own stuff back to your browser
> appearing to come from 1.2.3.4.
>
> Having the correct IP address of my web-server is no guarantee that you
> are actually talking to the right server - when the bad guy is
> on-the-wire that is.

Sure, but then that's true of any use of trusted information in an
insecure manner. DNS doesn't just carry IP addresses, and there's nothing
to prevent one from putting other information (e.g. public keys) in the
DNS. You mentioned "that's what SSL is for"; it would be equally possible
to secure http (or smtp or whatever) using public keys retrieved over
DNSSEC to avoid the attack you mention over. Without DNSSEC you need
some other mechanism of ensuring the public key is correct; whilst
SSL certificates have got good traction for HTTP, they haven't for
(e.g.) SMTP.

This is a useful discussion if only because it shows there are two meanings
of "on the wire attacks" (i.e. attacks to DNS, and attacks based on an
intercept of the results of the lookups).

Alex

---

From: Jesper G. Høy <[email-masked]>
Date: Tue, 29 Jul 2008 18:18:41 +0200

I agree - and I am not arguing against DNSSEC as a whole.
As I started out saying - "There may be other good reasons to push DNSSEC" - distributing public keys certainly may be one of those.

However, this was in regards to the Kaminsky bug, which is all about carrying IP addresses (A/AAAA RRSets in response Additional section).
So to clarify: DNSSEC doesn't make much difference when the bad guy is on-the-wire - for IP address records.

Without having thought this through, I think resolvers could probably ignore anything else (non A/AAAA RRSets) in the response Additional section - limiting the Kaminsky bug to such records. But that's a different thread...

Carrying IP addresses is still by far the biggest use of DNS.
And I am just not convinced that it is a good idea to apply DNSSEC's complexity to this most fundamental part of our Internet.
I believe a simpler solution stands a much better chance of actually being implemented and used, and therefore is more secure overall.
Especially if such a solution does not require any end-user action other than patching.

Sincerely,
Jesper

> Sent: Tuesday, July 29, 2008 5:23 PM

---

From: Jelte Jansen <[email-masked]>
Date: Tue, 29 Jul 2008 18:44:30 +0200

> So to clarify: DNSSEC doesn't make much difference when the bad guy is on-the-wire - for IP address records.

Any protocol that uses A/AAAA addresses could be in danger if it doesn't
 have its own protection (and indeed still would be with DNSSEC, if an
attacker has full wire access). But, this includes DNS itself. Someone
nasty could, for instance, not change a www or smtp A record, but an
actual NS A record, thereby becoming authoritative for an entire zone,
and all its data.

> Without having thought this through, I think resolvers could probably ignore anything else (non A/AAAA RRSets) in the response Additional section - limiting the Kaminsky bug to such records. But th…

They should already :) (as well as ignore out-of-bailiwick etc)

Jelte