Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)

From: Dean Anderson <[email-masked]>
Date: Fri, 8 Aug 2008 21:03:53 -0400 (EDT)

FYI: It would be nice if someone could repost this the namedroppers.  
This might inform some of the discussion going on there. Both DJB and I
have problems posting to namedroppers for basically the same
reasons---opposing the BIND cartel. However, getting this information
distributed seems to be important enough to be widely distributed.

Make sure you read the UIC announcement included at the end.

I'm greatly enjoying the Olympics; have fun!

		--Dean

---------- Forwarded message ----------
Date: 8 Aug 2008 03:42:28 -0000
From: D. J. Bernstein <[email-masked]>
To: [email-masked]
Subject: Re: Kaminsky on djbdns bugs

Kyle Wheeler writes:
> That makes it easier for an attacker to guess the right number, but
> only somewhat (your chances per-guess go from one in four billion to,
> say, thirty in four billion). This criticism of djbdns seems
> somewhat... well, specious.

http://cr.yp.to/djbdns/forgery.html has, for several years, stated the
results of exactly this attack:

   The dnscache program uses a cryptographic generator for the ID and
   query port to make them extremely difficult to predict. However,

   * an attacker who makes a few billion random guesses is likely to
     succeed at least once;
   * tens of millions of guesses are adequate with a colliding attack;

etc. The same page also states bilateral and unilateral workarounds that
would raise the number of guesses to "practically impossible"; but then
focuses on the real problem, namely that "attackers with access to the
network would still be able to forge DNS responses."

I suppose I should be happy to see public awareness almost catching up
to the nastiest DNS attacks I considered in 1999. However, people are
deluding themselves if they think they're protected by the current
series of patches. UIC is issuing a press release today on this topic;
see below.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

DNS still vulnerable, Bernstein says

CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so,
beware: recent Internet patches don't stop determined attackers.

Network administrators have been rushing to deploy DNS source-port
randomization patches in response to an attack announced by security
researcher Dan Kaminsky last month. But the inventor of source-port
randomization said today that new security solutions are needed to
protect the Internet infrastructure.

"Anyone who knows what he's doing can easily steal your email and insert
fake web pages into your browser, even after you've patched," said
cryptographer Daniel J. Bernstein, a professor in the Center for
Research and Instruction in Technologies for Electronic Security (RITES)
at the University of Illinois at Chicago.

Bernstein's DJBDNS software introduced source-port randomization in
1999 and is now estimated to have tens of millions of users. Bernstein
released the DJBDNS copyright at the end of last year.

Kaminsky said at the Black Hat conference yesterday that 120,000,000
Internet users were now protected by patches using Bernstein's
randomization idea. But Bernstein criticized this idea, saying that it
was "at best a speed bump for blind attackers" and "an extremely poor
substitute for proper cryptographic protection."

DNSSEC, a cryptographic version of DNS, has been in development since
1993 but is still not operational. Bernstein said that DNSSEC offers "a
surprisingly low level of security" while causing severe problems for
DNS reliability and performance.

"We need to stop wasting time on breakable patches," Bernstein said. He
called for development of DNSSEC alternatives that quickly and securely
reject every forged DNS packet.

Press contact: Daniel J. Bernstein <[email-masked]>

-30-

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Sat, 9 Aug 2008 16:33:55 -0400 (EDT)

> 1993 but is still not operational.

It seems that Mr. Bernstein also suffers from the "America is the not the
world" syndrome.

> Bernstein said that DNSSEC offers "a surprisingly low level of security"
> while causing severe problems for DNS reliability and performance.

Let's not argue about the subjective "suprisingly". But what is this
"low level of security"? Is a fully trusted path 'low level'? If so,
what is 'high level'?

> reject every forged DNS packet.

This statement even goes so far as to suggest DNSSEC is a "breakable patch"
In general, for all those people who claim DNSSEC is not the solution, I
have a few questions

1) What is more broken with DNSSEC then on DNS?
2) If DNSSEC is flawed, where is a better alternative?

Without answering those questions, you can't really reject DNSSEC over
the alternative of keeping to run DNS as we have so far.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sat, 9 Aug 2008 16:33:55 -0400 (EDT)

Paul

---

From: Andras Salamon <[email-masked]>
Date: Sun, 10 Aug 2008 14:51:37 +0200

> 2) If DNSSEC is flawed, where is a better alternative?

An alternative was proposed by Masataka Ohta around 1995.  It did not
progress, but maybe it is time to trawl the archives and revisit it?
    http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01512.html
    http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01516.html
    http://www.ops.ietf.org/lists/namedroppers/namedroppers.2006/msg01520.html
On the other hand, the comment from Masataka Ohta was:
    the real problem of DNSSEC is that it is merely weakly secure
so suggesting that a fundamental rethink is necessary.

-- Andras Salamon                   [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andras Salamon <[email-masked]>
Date: Sun, 10 Aug 2008 14:51:37 +0200

---

From: Ted Lemon <[email-masked]>
Date: Sun, 10 Aug 2008 07:55:37 -0700

> progress, but maybe it is time to trawl the archives and revisit it?

Paul's comment (the first of the three articles you quoted) implies  
that secure NXDOMAIN is not a feature of Ohta-san's proposal.   That  
seems like a bit of a problem, because fake domains are definitely a  
useful phishing tool.

>    the real problem of DNSSEC is that it is merely weakly secure

What Ohta-san is saying here (and I hope he will forgive me and  
explain if I get it wrong) is that DNSSEC's security depends on the  
people managing the name servers in the hierarchy down to the zone  
whose security I am validating.   So if one of those people is  
untrustworthy, the contents of a zone can be faked.

This is true.   However, it's also the way security works.   In order  
to have more security than this, I would need to have trust anchors  
for every zone I really cared about - this would enable me to avoid  
placing trust in the hierarchy.   In some situations this might be a  
very good idea.   In practice, though, in many (most) situations it  
would be too much work.   In any case, if you want to do this, it can  
be done with DNSSEC today.

Remember who you are trusting: the people who operate the root zone,  
and the people who operate the TLDs.   So in order for you to get a  
forged result, at least the TLD for the zone you're looking up would  
have to be compromised.   And it would have to be compromised by  
someone with access to the key.   Possible, certainly, but expensive.

What DNSSEC gets you in this case is two things: one, it increases the  
cost of forging DNS info *substantially*.   This is a good thing -  
nothing is ever perfectly secure; what you want is for a thing to be  
sufficiently secure that what you gain from breaking the security is  
less than what you spent breaking it.

The other thing it gives you is a responsible party to sue in the  
event that something goes wrong.   This is probably why the TLDs are  
reluctant to sign their zones.   But it's how business is done.

It's definitely a good idea to make sure that the security of the zone  
has as little value as possible.   So it can solve the problem we're  
all hot about right now.   But it can't replace SSL certs.   If the  
DNS replaced SSL certs, cracking zone operators would be worth a *lot*  
of money, much more than simply being able to forge an A record.   We  
don't want that, and that's why putting that kind of key in the DNS is  
a bad idea (IMHO).

> so suggesting that a fundamental rethink is necessary.

One thing to keep in mind when you talk about fundamental rethinks is  
that despite the fact that there is nobody who would say that DNSSEC  
is pretty, DNSSEC is what we have after a very long effort to produce  
a solution to this very problem.

Now, it could be that all the people involved are stupid, or that  
politics derailed the process and that's why we have the solution we  
have and not some other imagined solution that we don't have that  
would have better properties, or be easier to operate, or safer, or  
whatever.

But in all likelihood the reason we are where we are has more to do  
with the fact that securing the DNS is a hard problem.   So when you  
talk about a fundamental rethink, what you are proposing is that we  
start from scratch and try to come up with something that took a  
decade to come up with in the first place.   We've learned a lot in  
the process of coming up with DNSSEC, so it probably wouldn't take a  
decade to do this rethink.   But it would still take a very long  
time.   And we have no guarantee that the output of the process would  
be preferable to what we have now.   And many reasons to think it  
would not.

A bird in the hand is worth two in the bush.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 10 Aug 2008 07:55:37 -0700

---

From: Tony Finch <[email-masked]>
Date: Sun, 10 Aug 2008 21:59:40 +0100

On Sun, 10 Aug 2008, Ted Lemon wrote:
>
> Paul's comment (the first of the three articles you quoted) implies that
> secure NXDOMAIN is not a feature of Ohta-san's proposal.   That seems like a
> bit of a problem, because fake domains are definitely a useful phishing tool.

As far as I can tell from the draft linked below, it does support secure
NXDOMAIN and could be made to do so without allowing zone enumeration.
http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: EASTERLY OR NORTHEASTERLY 5 TO 7, OCCASIONALLY GALE
8 AT FIRST. ROUGH OR VERY ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tony Finch <[email-masked]>
Date: Sun, 10 Aug 2008 21:59:40 +0100

Tony.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 10 Aug 2008 22:06:13 +0100

> http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt

ZL is effectively NSEC, so suffers from the same problem. A ZL3 would be 
required. With all its attendant problems.

Cheers,

Ben.

-- 
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
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ben Laurie <[email-masked]>
Date: Sun, 10 Aug 2008 22:06:13 +0100

Cheers,

Ben.

---

From: Tony Finch <[email-masked]>
Date: Sun, 10 Aug 2008 23:15:30 +0100

> required. With all its attendant problems.

The <first> and <last> domains that bracket the list don't have to exist
in the zone: you can just return an empty ZL record that brackets the
QNAME as a proof of nonexistence. However you'd have to generate and sigFrom [email-masked]  Sun Aug 10 15:15:32 2008
Date: Sun, 10 Aug 2008 23:15:30 +0100
From: Tony Finch <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> required. With all its attendant problems.

The <first> and <last> domains that bracket the list don't have to exist
in the zone: you can just return an empty ZL record that brackets the
QNAME as a proof of nonexistence. However you'd have to generate and sign
n
the record on the fly so it's not really practical, and you're right that
something better is required.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA: SOUTHWESTERLY BACKING SOUTHERLY 5 OR 6,
OCCASIONALLY 7 IN FASTNET. ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

the record on the fly so it's not really practical, and you're right that
something better is required.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOLE LUNDY FASTNET IRISH SEA: SOUTHWESTERLY BACKING SOUTHERLY 5 OR 6,
OCCASIONALLY 7 IN FASTNET. ROUGH. RAIN OR SHOWERS. MODERATE OR GOOD,
OCCASIONALLY POOR.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ben Laurie <[email-masked]>
Date: Mon, 11 Aug 2008 07:41:24 +0100

> something better is required.

Yeah, yeah - we went through all this with NSEC/NSEC3.

"There is no limit to what a man can do or how far he can go if he
doesn't mind who From [email-masked]  Sun Aug 10 23:41:22 2008
Date: Mon, 11 Aug 2008 07:41:24 +0100
From: Ben Laurie <[email-masked]>
To: Tony Finch <[email-masked]>
Cc: IETF DNSOP WG <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> something better is required.

Yeah, yeah - we went through all this with NSEC/NSEC3.

"There is no limit to what a man can do or how far he can go if he
doesn't mind whgets the credit." - Robert Woodruff
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

o gets the credit." - Robert Woodruff
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Aug 2008 12:45:52 +0000

the fact that masataka's proposal seemed qualitatively better to me eleven
years ago is moot.  the reason dnssec isn't deployed yet has nothing to do
with any such qualitative differences.  we are where we are, and what we've
got to do now is deploy what we've got now.  the dnssec spec at present may
be ugly but it is practicable, and there's a large body of expertise and 
running code and commercial products and interoperability testing behind it.

while i didn't enjoy watching masataka's proposal railroaded into the ditch
and while it would have taken less time to get masataka's dnssec proposal
deployable than it has taken to get to what we've got now, the silver lining
for me was that i learned how to railroad my own proposals through IETF using
the techniques i learned.  RFC 2136, RFC 2671, and RFC 2845 all exist only
because of the dirty tricks i learned by watching masataka's mistreatment.
(had i known at the outset how IETF worked, i would have worked to prevent
that mistreatment, but i was a n00b.)
-- 
Paul Vixie

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Aug 2008 12:45:52 +0000

---

From: Dean Anderson <[email-masked]>
Date: Mon, 11 Aug 2008 15:21:59 -0400 (EDT)

> It seems that Mr. Bernstein also suffers from the "America is the not the

??? 

> "low level of security"? Is a fully trusted path 'low level'? If so,

I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help.

> 1) What is more broken with DNSSEC then on DNS?

The question really should be 'What is LESS broken with DNSSEC than with
DNS?' Equally broken is bad, too.  'More broken' is clearly a disaster.  
'Not broken' is the goal.

> 2) If DNSSEC is flawed, where is a better alternative?

I think there are indeed better alternatives.  Bernstein calls for
development of alternatives.  But to find alternatives, IETF has to stop
silencing the people who can figure out solutions, merely because those
people oppose the BIND cartel. The BIND cartel gave us the flawed
solutions;  It did this by silencing the oppoFrom [email-masked]  Mon Aug 11 12:22:09 2008
Date: Mon, 11 Aug 2008 15:21:59 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: [email-masked], "D. J. Bernstein" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> It seems that Mr. Bernstein also suffers from the "America is the not the

??? 

> "low level of security"? Is a fully trusted path 'low level'? If so,

I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help.

> 1) What is more broken with DNSSEC then on DNS?

The question really should be 'What is LESS broken with DNSSEC than with
DNS?' Equally broken is bad, too.  'More broken' is clearly a disaster.  
'Not broken' is the goal.

> 2) If DNSSEC is flawed, where is a better alternative?

I think there are indeed better alternatives.  Bernstein calls for
development of alternatives.  But to find alternatives, IETF has to stop
silencing the people who can figure out solutions, merely because those
people oppose the BIND cartel. The BIND cartel gave us the flawed
solutions;  It did this by silencing the opsition to create a false
consensus on their ideas.  The cartel continues to exercise control of
(at least)  IETF DNSEXT and continues to silence its critics, even
though its credibility at solving these problems should have been
exhausted a long time ago. Silencing the cartel's critics was improper.

> the alternative of keeping to run DNS as we have so far.

Sure you can reject DNSSEC. One broken solution doesn't justify
deployment of another broken solution.  Time and again we've seen this
same pattern:  Someone essentially yells "Emergency! Lets rush out this
(non) solution! No time to think things through!". In almost every case,
there is usually no emergency, and the 'solution' is frequently worse
than the problem.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

position to create a false
consensus on their ideas.  The cartel continues to exercise control of
(at least)  IETF DNSEXT and continues to silence its critics, even
though its credibility at solving these problems should have been
exhausted a long time ago. Silencing the cartel's critics was improper.

> the alternative of keeping to run DNS as we have so far.

Sure you can reject DNSSEC. One broken solution doesn't justify
deployment of another broken solution.  Time and again we've seen this
same pattern:  Someone essentially yells "Emergency! Lets rush out this
(non) solution! No time to think things through!". In almost every case,
there is usually no emergency, and the 'solution' is frequently worse
than the problem.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Aug 2008 16:42:06 -0400 (EDT)

>> It seems that Mr. Bernstein also suffers from the "America is the not the

DNSSEC has been deployed on large scale by some TLD's and RIR's already.
It is very much operational.

> I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help.

I did not really see anything there that shows a weakness or 'low level'
of security. What I see there are a few funny suggestions about changing
the concept of a URL to match an outdated DNS infrastructure, and some
mechanism to 'cause less packets' based on key/fingerprint size that is
both based only on near term key sizes and cpu speeds, and disregards DNS
caching by resolvers. Using TXT records to hack around something as
fundamental as DNS security seems a very outdated concept. How long do
we hack around a system before before making a protocol change? Sure,
not every day, as EDNS0 proves, but surely using TXT records and source
port numbers for the next 25 years sounds like overshooting it at the
other end of the spectrum.

> DNS?'

This shows more an unwillingness to discuss then anything else. DNSSEC
offers secure transport over plaintext channels of DNS data. Perhaps not
in a method you prefer, but that was not part of questions 1). So at
most here, you can answer "more cpu" and "more bandwidth" and "more error
prone by administrators". The first two are a direct consquence of any
solution that adds cryptography to a previous solution not using cryptography.
The error proneness is (and this is a subjective opinion of mine) something
we have to deal with, and DNSSEC seems to be a reasonable approach to this,
even if we're lacking a little in proper tools to make it easier.

> Equally broken is bad, too.  'More broken' is clearly a disaster.

I'm not talking about English Lit. classes here. Stay on target please.

> development of alternatives.

So there are better alternatives, but even Mr. Bernstein wants to develop
alternatives, suggesting to me that tehre are currently no alternatives.
Which again leads to you requiring more proof of 1) before shooting down
DNSSEC. If there is nothing better, and DNSSEC does not make it worse (and
some complexity in return for fixing the recent Kaminsky class bugs seems
pretty acceptable to me), then it is you who needs to do the work of
developing these 'better alternatives' that you so desire. "Consensus
and Running Code"?

> But to find alternatives, IETF has to stop
> people oppose the BIND cartel.

I'm skipping the conspiracy theory discussion bit. I see many clever people
who dare to stand up and show mistakes and propose alternatives.

> The BIND cartel gave us the flawed solutions;

However, after I asked you to show these flaws, I was not answered. See
above.

> Sure you can reject DNSSEC. One broken solution doesn't justify

See above. I still don't see any argument where DNSSEC is worse then
DNS without it. I also still see no alternative that is reasonable (and
changing URL symmentics and moving the DNS problem to be a browser
problem is not a solution).

> (non) solution! No time to think things through!".

You are the first person I've ever heard say that DNSSEC was "rushed". The
other 99.99999% of people complained it took us more then 10 years.

> In almost every case,

Show is the problems. Brasil, Sweden and RIPE's reverse tree did not vanish
from the net when they implemented things. Resolvers of bug ISP's in Sweden
did not cause the Swedish endusers to lose connectivity to the internet.

Where are these problems you are speaking of?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 11 Aug 2008 16:42:06 -0400 (EDT)

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 10:34:57 +0900

>>1) What is more broken with DNSSEC then on DNS?

DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives
users false sense of security.

> 'Not broken' is the goal.

I was enlightened on two things through designing and improving simple
secure DNS, which is a PKI-based cryptographically secure DNS consistent
with PODS. They are:

	1) precise authority model of referral and glue A, which is why
	I know how to fix cache contamination through glue A

	2) Meaninglessness of DNSSEC, or PKI in general, with no better
	security than PODS

Just like the Internet is a network of ISPs and end users, a PKI is a
network of CAs and end users. If you can blindly believe in that CAs
and end users are secure, you can blindly believe in that ISPs and end
users are secure, both of which are, of course, wrong. However, with PKI
the former is silently assumed and PKI is claimed to be cryptographically
secure, which is the fallacy of PKI.

For example, even if you make your signature generation mechanism not
accessible online through the Internet, the mechanism must be, to keep
the PKI work, accessible through the network of CAs and end users,
which means the mechanism is effectively online, where "effectively"
means attacking is equally easy.

That is, WGFrom [email-masked]  Mon Aug 11 18:35:49 2008
Date: Tue, 12 Aug 2008 10:34:57 +0900
From: Masataka Ohta <[email-masked]>
To: Dean Anderson <[email-masked]>
Cc: [email-masked], "D. J. Bernstein" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

>>1) What is more broken with DNSSEC then on DNS?

DNSSEC is, socially, more dangerous than PODS, because DNSSEC gives
users false sense of security.

> 'Not broken' is the goal.

I was enlightened on two things through designing and improving simple
secure DNS, which is a PKI-based cryptographically secure DNS consistent
with PODS. They are:

	1) precise authority model of referral and glue A, which is why
	I know how to fix cache contamination through glue A

	2) Meaninglessness of DNSSEC, or PKI in general, with no better
	security than PODS

Just like the Internet is a network of ISPs and end users, a PKI is a
network of CAs and end users. If you can blindly believe in that CAs
and end users are secure, you can blindly believe in that ISPs and end
users are secure, both of which are, of course, wrong. However, with PKI
the former is silently assumed and PKI is claimed to be cryptographically
secure, which is the fallacy of PKI.

For example, even if you make your signature generation mechanism not
accessible online through the Internet, the mechanism must be, to keep
the PKI work, accessible through the network of CAs and end users,
which means the mechanism is effectively online, where "effectively"
means attacking is equally easy.

That is,  discussion on securing NXDOMAIN has been totally
meaningless.

For another example, just as a packet with 16 bit ID and 32 bit source
address should not be blindly believed, a person with an ID badge with
16 digit ID and issuer's name of your parent CA should not be
blindly believed, though both of them are blindly believed so often.

To break DNSSEC, a phishing site pretending as your parent CA and
requesting you enter your private key is often enough.

> I think there are indeed better alternatives.

As I already posted, try to improve implementations to use TCP with
random sequence number and random port, which is not more
difficult than to improve caching behavior of implementations.

							Masataka Ohta

WG discussion on securing NXDOMAIN has been totally
meaningless.

For another example, just as a packet with 16 bit ID and 32 bit source
address should not be blindly believed, a person with an ID badge with
16 digit ID and issuer's name of your parent CA should not be
blindly believed, though both of them are blindly believed so often.

To break DNSSEC, a phishing site pretending as your parent CA and
requesting you enter your private key is often enough.

> I think there are indeed better alternatives.

As I already posted, try to improve implementations to use TCP with
random sequence number and random port, which is not more
difficult than to improve caching behavior of implementations.

							Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 12:11:53 +1000

> means attacking is equally easy.

	You already have to trust your parents to publish your
	delegating NS RRset.  If they don't then you are in trouble.
	DNSSEC does not change that pre-existing trust relatiFrom [email-masked]  Mon Aug 11 19:12:00 2008
To: Masataka Ohta <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 12:11:53 +1000
Cc: [email-masked]
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> means attacking is equally easy.

	You already have to trust your parents to publish your
	delegating NS RRset.  If they don't then you are in trouble.
	DNSSEC does not change that pre-existing trust relationonship
	which is required for DNS to work.

	Unless you control all aspects of the communication you end
	up having to trust someone.  The question is who do you
	trust and is that appropriate for the thing that is being
	secured.

	The DNSSEC trust model is in parallel to the trust model
	of the thing it is securing (DNS).

> That is, WG discussion on securing NXDOMAIN has been totally
> meaningless.

	That really depends on which persons you are attempting to
	prevent tampering from.

> requesting you enter your private key is often enough.

	Which like most things to do with security is a matter of
	education.
 
> difficult than to improve caching behavior of implementations.

	TCP only addresses one of the issues.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

ship
	which is required for DNS to work.

	Unless you control all aspects of the communication you end
	up having to trust someone.  The question is who do you
	trust and is that appropriate for the thing that is being
	secured.

	The DNSSEC trust model is in parallel to the trust model
	of the thing it is securing (DNS).

> That is, WG discussion on securing NXDOMAIN has been totally
> meaningless.

	That really depends on which persons you are attempting to
	prevent tampering from.

> requesting you enter your private key is often enough.

	Which like most things to do with security is a matter of
	education.
 
> difficult than to improve caching behavior of implementations.

	TCP only addresses one of the issues.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 12:17:27 +1000

> 	Which like most things to do with security is a matter of

	To which I should have added.  With DNSSEC you *never* need
	to disclose you private key.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 12:17:27 +1000

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 12:00:09 +0900

> 	delegating NS RRset.

So, technically, DNSSEC is no worse but no better than PODS.

> 	That really depends on which persons you are attempting to

Social implementations of DNSSEC may be (or, considering its complexity,
will always be) vulnerable to tampering from any person.

> 	Which like most things to do with security is a matter of

Quick upgrading of programs with open security holes is another, but
a lot easier, matter of education.

So, if we are discussing security in the real world, let's never
assume that people are automagically educated to treat all the
complex aspects of DNSSEC operations properly.

> 	TCP only addresses one of the issues.

Let's accept the reality that DNS operation is human and can not be
very secure.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 12:00:09 +0900

Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Aug 2008 20:17:23 -0700

> users false sense of security.

The average user has a false sense of security completely independent  
of what the underlying protocol is.   So what matters is not what  
sense of security the user has, but what actual security the user  
has.   We can't control what the user thinks or does.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Aug 2008 20:17:23 -0700

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 12:36:44 +0900

> So what matters is not what  sense of security the user has, but
> what actual security the user  has.

The false sense of security makes people unconditionary accept DNS
result. Worse, they think not only attackers but also victims are
responsible for damages.

> We can't control what the user thinks or does.

How can you explain the evidence that many people here think DNSSEC
more secure than PODS merely because it is called DNSSEC?

Are they less-than-average users?

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 12:36:44 +0900

Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 13:50:29 +1000

> So, technically, DNSSEC is no worse but no better than PODS.

No.

Can my ISP interfere without being detetected?  	PODS Yes.  DNSSEC No.
Can my neighbor spoof a reply without being detetected?	PODS Yes.  DNSSEC No.
Can someone spoof a referral the have the answers from
the servers in the spoofed referral be believed?	PODS Yes.  DNSSEC No.

Can someone socially engineer a change in a TLD?	PODS Yes.  DNSSEC Yes.
 
> a lot easier, matter of education.

Upgrading programs is also a matter of education.  For that matter
running a DNS server is a matter of education.

The current DNSSEC is a very similar adminstration model to the
current DNS adminstration model.  There is minimal education involved.

> complex aspects of DNSSEC operations properly.

DNSSEC administration is not complex.  DNS glue management is more
complex than DNSSECFrom [email-masked]  Mon Aug 11 20:50:33 2008
To: Masataka Ohta <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Tue, 12 Aug 2008 13:50:29 +1000
Cc: [email-masked]
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> So, technically, DNSSEC is no worse but no better than PODS.

No.

Can my ISP interfere without being detetected?  	PODS Yes.  DNSSEC No.
Can my neighbor spoof a reply without being detetected?	PODS Yes.  DNSSEC No.
Can someone spoof a referral the have the answers from
the servers in the spoofed referral be believed?	PODS Yes.  DNSSEC No.

Can someone socially engineer a change in a TLD?	PODS Yes.  DNSSEC Yes.
 
> a lot easier, matter of education.

Upgrading programs is also a matter of education.  For that matter
running a DNS server is a matter of education.

The current DNSSEC is a very similar adminstration model to the
current DNS adminstration model.  There is minimal education involved.

> complex aspects of DNSSEC operations properly.

DNSSEC administration is not complex.  DNS glue management is more
complex than DNSS administration.  It's just that DNSSEC is new
that people believe that it is complex.

> Let's accept the reality that DNS operation is human and can not be

The DNS can be secured from a number of current threats.  It can
never be secured from all threats.  That doesn't mean we should not
secure it from the threats that we can secure it from.

TCP, port randomisation, 0x20, EDNS PING etc. all leave gapping holes
in the security model which are being exploited today.

EC administration.  It's just that DNSSEC is new
that people believe that it is complex.

> Let's accept the reality that DNS operation is human and can not be

The DNS can be secured from a number of current threats.  It can
never be secured from all threats.  That doesn't mean we should not
secure it from the threats that we can secure it from.

TCP, port randomisation, 0x20, EDNS PING etc. all leave gapping holes
in the security model which are being exploited today.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Aug 2008 21:07:46 -0700

> Are they less-than-average users?

No, Ohta-san.   It _is_ more secure.   Security is relative, not  
absolute.   You could reasonably question whether the delta in  
security is worth the price we'd pay, but calling people names isn't  
part of that process.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 11 Aug 2008 21:07:46 -0700

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 15:00:17 +0900

Ted Lemon wrote:

> absolute.

Are you really talking about relative security?

If you are talking about security relative to the amount of
operational effort (that is, money!!!), PODS is definitly
more secure than DNSSEC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Aug 2008 15:00:17 +0900

Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Aug 2008 09:01:29 -0400

[no hat]

> will always be) vulnerable to tampering from any person.

This seems like a strong claim.  Are you really just claiming that,
because humans are involved and because it depends on proving trust
relationships; and because we know that humans make a lot of errors;
therefore, DNSSEC is only as strong as the operational practices of
the weakest point in the chain of trust?

A
-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Aug 2008 09:01:29 -0400

[no hat]

A

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Aug 2008 09:06:53 -0700

> operational effort (that is, money!!!), PODS is definitly

I think if you were to try to explain this by presenting real-world  
statistical data to support your argument, your argument might become  
convincing.   When you say it like this, though, it sounds like  
baseless speculation.   And that certainly matches my personal  
experience in working with DNSSEC - the difference in effort seems to  
me to be orders of magnitude less than what you are suggesting.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Aug 2008 09:06:53 -0700

---

From: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 14:40:28 -0400 (EDT)

On Mon, 11 Aug 2008, Paul Wouters wrote:

[Paul Wouters is a frequent NANOG poster.]

> It is very much operational.

Not very much--99 domains out of 70 million in .com.

Your argument would be stronger if you identified which TLD's and which 
RIR's.

> > I think http://cr.yp.to/talks/2004.04.28/slides.pdf might help.

I think the recent message from Dr. Bernstein that I posted answers this
far more clearly than I could.

> How long do we hack around a system before before making a protocol
> change? Sure, not every day, as EDNS0 proves, but surely using TXT
> records and source port numbers for the next 25 years sounds like
> overshooting it at the other end of the spectrum.

This is a very good point. We had an opportunity to replace the protocol
entirely in IPv6. That opportunity was squandered.  Perhaps more
questions should be asked about this squandered opportunity in the right
forums, or maybe on a different subject line in this forum.

> This shows more an unwillingness to discuss then anything else. 

This is a completely irrational claim.

> DNSSEC offers secure transport over plaintext channels of DNS data.
> Perhaps not in a method you prefer, but that was not part of questions
> 1). So at most here, you can answer "more cpu" and "more bandwidth"
> and "more error prone by administrators". The first two are a direct
> consquence of any solution that adds cryptography to a previous
> solution not using cryptography. The error proneness is (and this is a
> subjective opinion of mine) something we have to deal with, and DNSSEC
> seems to be a reasonable approach to this, even if we're lacking a
> little in proper tools to make it easier.
> 

I don't know what English Lit. has to do with anything. Clearly these
degrees of brokeness of DNSSEC are relevant to a debate about DNSSEC
problems.

> alternatives, suggesting to me that tehre are currently no alternatives.

Nice circular logic there.

> developing these 'better alternatives' that you so desire. "Consensus

The logic "if nothing better, therefore DNSSEC does not make it worse"  
is a fallacy.  There can indeed be no alternative (and thus nothing
better), while DNSSEC still makes things worse.

> > But to find alternatives, IETF has to stop silencing the people who
> > can figure out solutions, merely because those people oppose the
> > BIND cartel.
> 

You just said there were no alternatives.

Dismissing the definite overt acts of misconduct as "conspiracy theory"  
is merely a tricky attempt to avoid the facts. There is nothing
hypothetical about the facts of the misconduct in silencing persons who
opposed the BIND cartel. There is nothing hypothetical about the
government documents that show the common control in the BIND cartel

> However, after I asked you to show these flaws, I was not answered. See

You were answered about flaws; I referred you to documents describing
the flaws. The recent message from Dr. Bernstein more clearly answers
the 'flaws issue'.

> other 99.99999% of people complained it took us more then 10 years.

DNSSEC was a series of mistakes over a 15 year period.

The current rushing is the "DNS is insecure! Adopt DNSSEC NOW!!!"  
drumbeat.  "Take our patches without thinking or questioning our
wisdom!!!"  This drumbeat is no different from the 2003 "There is SPAM!  
Adopt SPF NOW!!!"  In that case, SPF proponents proposed suspending the
IETF rules to adopt the protocol quickly. (SPF turned out to make things
worse via new DOS attacks, and didn't stop spam).  Or take the 1999 cry
"There is SPAM!  REQUIRE Reverse DNS NOW!!!"  This group is still
working on the in-addr required document.  There are more examples of
people creating a sense of "urgency" to do things that turned out to be
bad ideas, or at best, ineffective ideas.

> > In almost every case, there is usually no emergency, and the
> > 'solution' is frequently worse than the problem.
> 

Oh---So if the reverse trees didn't vanish, everything must be
alright... Sigh.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 14:40:28 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 14:50:16 -0400 (EDT)

> in the security model which are being exploited today.

I don't know of any TCP exploits today. Though TCP is not secure against
anyone in the path of the packets, its pretty invulnerable to spoofing
attacks conducted if the attacker can't see the packets.  TCP is
vulnerable to other kinds of DOS attacks such as synflood or connection
reset.  Synfloods are handled by existing mitigation techniques.  The
shorter the transaction, the harder it is to effect connection reset,
but connection caching improves efficiency. TCP is pretty robust in most
situations.

TCP:  Get truth or nothing, unless liar in the path
UDP:  Get something, even a lie from anywhere
DNSSEC: Everybody might get nothing, but the TLD and root operators are 
  entrenched. No alternate roots.

Pick your poison (pun intended ;-)

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 14:50:16 -0400 (EDT)

--Dean

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Aug 2008 12:32:29 -0700

> Not very much--99 domains out of 70 million in .com.

As has been pointed out, .COM is not signed.  The fact that there are  
99 zones signed in .COM is actually a bit surprising and points out  
one of the larger flaws with DNSSEC -- the assumption of a  
hierarchical top-down trust model in a world where the likeliest  
deployment model is bottom-up.  For the signing of any of those  
99 .COM zones to be useful, caching server operators have to manually  
configure/update the trust anchors for each of those zones.  That  
obviously won't scale.  And VeriSign hasn't exactly been chomping at  
the bit to sign .COM, quite the opposite as I understand it.

> Your argument would be stronger if you identified which TLD's and  
> which RIR's.

Last I checked:

.SE, .BG, .PR, and .BR have been signed.
RIPE-NCC signs the in-addr.arpa zones they are responsible for.

I have been told there are several more top-level domains that have  
indicated they will be signing their zones before the end of the  
year.  The IAB has asked IANA to sign .ARPA and its child zones and  
that process is underway, see https://ns.iana.org/dnssec/status.html  
(unfortunately, that effort has been a bit blocked for non-technical  
reasons).  Others have indicated they are considering and/or  
attempting to do so, but are constrained for various reasons.  Plans  
may have changed with the From [email-masked]  Tue Aug 12 12:32:48 2008
From: David Conrad <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Tue, 12 Aug 2008 12:32:29 -0700
Cc: [email-masked], "D. J. Bernstein" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> Not very much--99 domains out of 70 million in .com.

As has been pointed out, .COM is not signed.  The fact that there are  
99 zones signed in .COM is actually a bit surprising and points out  
one of the larger flaws with DNSSEC -- the assumption of a  
hierarchical top-down trust model in a world where the likeliest  
deployment model is bottom-up.  For the signing of any of those  
99 .COM zones to be useful, caching server operators have to manually  
configure/update the trust anchors for each of those zones.  That  
obviously won't scale.  And VeriSign hasn't exactly been chomping at  
the bit to sign .COM, quite the opposite as I understand it.

> Your argument would be stronger if you identified which TLD's and  
> which RIR's.

Last I checked:

.SE, .BG, .PR, and .BR have been signed.
RIPE-NCC signs the in-addr.arpa zones they are responsible for.

I have been told there are several more top-level domains that have  
indicated they will be signing their zones before the end of the  
year.  The IAB has asked IANA to sign .ARPA and its child zones and  
that process is underway, see https://ns.iana.org/dnssec/status.html  
(unfortunately, that effort has been a bit blocked for non-technical  
reasons).  Others have indicated they are considering and/or  
attempting to do so, but are constrained for various reasons.  Plans  
may have changed with the rerecent vulnerability announcements, but it  
would be inappropriate for me to pretend to speak for those TLD  
operators.

Regards,
-drc

cent vulnerability announcements, but it  
would be inappropriate for me to pretend to speak for those TLD  
operators.

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Aug 2008 15:22:02 -0400 (EDT)

> [Paul Wouters is a frequent NANOG poster.]

a handful of postings in years is frequent?

> Not very much--99 domains out of 70 million in .com.

"America is not the world"

> Your argument would be stronger if you identified which TLD's and which

http://www.xelerance.com/dnssec/ shows deployments per TPD, other people have
created lists of domains within other unsecure TLD's. These are regularly posted
to various lists, including dnssec-deployment, so loook there.

On top of that, perhaps check out: http://ccnso.icann.org/surveys/dnssec-survey-report-2007.pdf
For example it shows that of 61 TLD's, 7% deployed DNSSEC in production, 5% has a testbed
running, and of the remaining TLD's that don't have an implementation going, 33% is going
to deploy within the 1 year, and an additonal 38% is going to deploy in 3 years. It's really
time to put the "dnssec is not deployed" myth to bed.

> forums, or maybe on a different subject line in this forum.

While historically intruiging, it has no relevance to DNSSEC.

> This is a completely irrational claim.

You "answer" my question by inverting it, using a cows vs animals inversion.

> Nice circular logic there.

Note for the record that I just explained YOUR circular logic. Thank you for
confirming the flawed reasoning. I totally agree with you on that point.

> better), while DNSSEC still makes things worse.

Worse then current DNS deployments? That's pretty hard to do. Didn't you
see or read Dan's presentation?

> You just said there were no alternatives.

People *proposed* alternatives. They were just not accepted as valid alternatives
that were better then DNSSEC.

> is merely a tricky attempt to avoid the facts.

Seeing how you responded to my emails, I am beginning to see their point.

> the flaws. The recent message from Dr. Bernstein more clearly answers

I responded to those.

> The current rushing is the "DNS is insecure! Adopt DNSSEC NOW!!!"

No, the current solution was "Let's not force everyone into DNSSEC now,
since that would be unsafe, so let's hack our way around a hack we did not
like in the past, but which seems to only short-term stopgap. Let's co-ordinate
a masive cross vendor source-port randomization patch".

> Oh---So if the reverse trees didn't vanish, everything must be

Let me help your english parsing:

" Show is the problems. [Brasil], [Sweden] and [RIPE's reverse tree] did not
vanish". I expected someone like you to know there are no CCTLD reverse trees.

Anyway, this discussion is not leading to anything constructive, so I am ending
my participation to it. Feel free to have the last word.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Aug 2008 15:22:02 -0400 (EDT)

I responded to those.

Paul

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Aug 2008 18:37:21 -0400

On 12 Aug 2008, at 14:50, Dean Anderson wrote:

> I don't know of any TCP exploits today.

Imagine being able to intercept arbitrary flows of packets between  
targeted remote ASes in such a way that the remote ASes could not  
easily tell that anything was going on. Imagine that traceroutes from  
the perspective of the remote ASes continue to look normal, or at  
least similar to normal.

   http://eng.5ninesdata.com/~tkapela/iphd-2.ppt

How much protection does the use of TCP buy you in that scenario?

Joe

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Aug 2008 18:37:21 -0400

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Aug 2008 20:04:08 +0900

> This seems like a strong claim.

Not at all.

Instead, that PKI, including DNSSEC, were cryptographically secure
is a unfounded strong claim never supported by real-world statistical
data.

Maybe, Ted could provide some virtual-world data realistic enough to
deny the real-world statistical data such as:

djb> Last week's surveys by the DNSSEC developers ("SecSpider") have found a
djb> grand total of 99 signed dot-com names out of the 70 million dot-com
djb> names on the Internet.

> relationships; and because we know that humans make a lot of errors;

It's interesting that you just mention erros and ignore social
implementation details nor intentional attacks.

Without them, plain text password of ftp, for example, is perfectly
secure.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 13 Aug 2008 20:04:08 +0900

Not at all.

							Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Aug 2008 08:36:38 -0400

> implementation details nor intentional attacks.

There are two elements to what you are claiming there:

1.  Social implementation details.  This was in fact what I was trying
to clarify.  It seemed to me you were suggesting that the social
implementation details are weak in some way (weaker than the existing
trust relationship with the parent for the parent side of the NS
record at the zone cut).  I thought that perhaps you were noting that
there is possibly somewhat more maintenance involved in DNSSEC
operations, and therefore more opportunities for human error, &c.  I
can't tell from your answer whether this is in fact what you meant or
not.

2.  Intentional attacks.  This appears to be a claim that DNSSEC is
inherently vulnerable to particular attacks.  If there are such
attacks that are not already mentioned in the specification, it'd be
nice to hear what they are now, before we have wider deployment.  Do
you have such details?

Best,

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 Aug 2008 08:36:38 -0400

Best,

A

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 09:50:27 -0700

On Aug 13, 2008, at 4:04 AM, Masataka Ohta wrote:
> djb> names on the Internet

Ohta-san, you made the claim that managing DNSSEC is so much more work  
than maintaining regular DNSSEC that the cost of doing so outweighed  
the benefit of doing so - the added security.   You provided no  
statistics to back up that claim, and that claim is contrary to my own  
personal experience with setting up DNSSEC.

The statistic you present above is probably true, and certainly  
matches my personal experience.   However, it says nothing about how  
much work is involved in setting up and maintaining DNS zones.  From [email-masked]  Wed Aug 13 09:51:12 2008
From: Ted Lemon <[email-masked]>
To: Masataka Ohta <[email-masked]>
Date: Wed, 13 Aug 2008 09:50:27 -0700
Cc: "[email-masked]" <[email-masked]>, Andrew Sullivan <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

On Aug 13, 2008, at 4:04 AM, Masataka Ohta wrote:
> djb> names on the Internet

Ohta-san, you made the claim that managing DNSSEC is so much more work  
than maintaining regular DNSSEC that the cost of doing so outweighed  
the benefit of doing so - the added security.   You provided no  
statistics to back up that claim, and that claim is contrary to my own  
personal experience with setting up DNSSEC.

The statistic you present above is probably true, and certainly  
matches my personal experience.   However, it says nothing about how  
much work is involved in setting up and maintaining DNS zones.    
Rather, what it says is that .COM is not signed.   There's no security  
benefit to signing your zone if the trust anchor on which your zone  
depends is not signed.   So this statistic is not part of the cost/ 
benefit analysis we were talking about - it's a non-sequitur.

It's certainly true that in order for .COM zones to get any meaningful  
security out of DNSSEC, either .COM has to be signed, or we have to  
use some other trust anchor mechanism, like DLV or DLVPTR, so if you  
wanted to use this statistic to justify deploying some alternative  
trust anchor system, that would make sense.

BTW, one exercise that I'd like to suggest for participants in this  
discussion is that, despite the fact that .COM is not signed, you sign  
your .COM zones if you haven't already.   I'm in the process of doing  
that myself.   Given that only 90 are signed so far, I suspect that a  
lot of DNS geeks just haven't bothered yet because .COM isn't signed.

  
Rather, what it says is that .COM is not signed.   There's no security  
benefit to signing your zone if the trust anchor on which your zone  
depends is not signed.   So this statistic is not part of the cost/ 
benefit analysis we were talking about - it's a non-sequitur.

It's certainly true that in order for .COM zones to get any meaningful  
security out of DNSSEC, either .COM has to be signed, or we have to  
use some other trust anchor mechanism, like DLV or DLVPTR, so if you  
wanted to use this statistic to justify deploying some alternative  
trust anchor system, that would make sense.

BTW, one exercise that I'd like to suggest for participants in this  
discussion is that, despite the fact that .COM is not signed, you sign  
your .COM zones if you haven't already.   I'm in the process of doing  
that myself.   Given that only 90 are signed so far, I suspect that a  
lot of DNS geeks just haven't bothered yet because .COM isn't signed.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 09:53:04 -0700

On Aug 13, 2008, at 9:50 AM, Ted Lemon wrote:
> than maintaining regular DNSSEC

Er, "regular DNS," not "regular DNSSEC."

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 09:53:04 -0700

---

From: Ralf Weber <[email-masked]>
Date: Wed, 13 Aug 2008 19:21:44 +0200

Moin!

>> djb> names on the Internet
As others pointed out if you would look somewhere else (e.g .se, .br,  
in-addr.arpa) the statistics may be different. And not in any  
statistics is the usage of DNSSEC in private networks, which IMHO is  
bigger than the public usage so far (hopefully this will change ;-).

>> Ohta-san, you made the claim that managing DNSSEC is so much more  
>> work than maintaining regular DNSSEC that the cost of doing so  
>> outweighed the benefit of doing so - the added security.   You  
>> provided no statistics to back up that claim, and that claim is  
>> contrary to my own personal experience with setting up DNSSEC.
Hmm, assuming that we both did use the same name server software my  
experiences are different. Compared to regular DNS setting up and more  
importantly maintaining DNSSEC is much more work than normal DNS stuff  
(zone resigning, key rollover) . I am not saying that the cost  
generally  outweighs the benefit, but with the current tools it is  
hard to justify DNSSEC usage, at least for the majority of ISPs out  
there. But I do hope that the tools get better and thus the cost of  
deploying DNSSEC decreases and we will all happily use it and can  
justify it's usage.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 Frankfurt
Germany
DDI: +49 (0)69 56606 2780 Internal OneDial: 8 491 2780
Fax: +49 (0)69 56606 6280
Email: [email-masked]
http://www.colt.net/

Data | Voice | Managed Services

*****************************************
COLT Telecom GmbH, Herriotstraße 4, 60528 Frankfurt/Main, Deutschland *
Tel +49 (0)69 56606 0 * Fax +49 (0)69 56606 2222 *
Geschäftsführer: Albertus Marinus Oosterom (Vors.), Rita Thies *
Amtsgericht Frankfurt/Main HRB 53898 * USt.-IdNr. DE 220 772 475

---

From: Ralf Weber <[email-masked]>
Date: Wed, 13 Aug 2008 19:21:44 +0200

Moin!

So long
-Ralf
---
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 11:06:26 -0700

On Aug 13, 2008, at 10:21 AM, Ralf Weber wrote:
> (zone resigning, key rollover) .

You're probably doing too much work.   Why are you doing key  
rollover?   Why so often?  Why not just use a longer key?   Are you  
trying for more security than you actually need?   Are you that  
careful with your SSL certs?   And why aren't you signing your zone  
with a cron job?

For me, the hardest problem about setting up a secure zone was simply  
finding concise documentation on how to do it.   I just set up a  
secure zone in .se, and the total work time from deciding to do it to  
having it done was about an hour, incluFrom [email-masked]  Wed Aug 13 11:06:30 2008
From: Ted Lemon <[email-masked]>
To: Ralf Weber <[email-masked]>
Date: Wed, 13 Aug 2008 11:06:26 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

On Aug 13, 2008, at 10:21 AM, Ralf Weber wrote:
> (zone resigning, key rollover) .

You're probably doing too much work.   Why are you doing key  
rollover?   Why so often?  Why not just use a longer key?   Are you  
trying for more security than you actually need?   Are you that  
careful with your SSL certs?   And why aren't you signing your zone  
with a cron job?

For me, the hardest problem about setting up a secure zone was simply  
finding concise documentation on how to do it.   I just set up a  
secure zone in .se, and the total work time from deciding to do it to  
having it done was about an hour, includiding:

  - tracking down and reading Olaf's rather verbose but quite helpful
    document on setting it up (http://www.nlnetlabs.nl/dnssec_howto/)
  - debugging two problems with my zone that weren't DNSSEC-related,
    but that the DNSSEC signer wouldn't allow
  - finding a registrar who was happy to communicate with me in English,
    since I don't speak Swedish (thanks, Patrik!)
  - registering a new domain, not just setting up DNSSEC.

Maybe I did it wrong, but it seemed pretty easy to me.   I think the  
problem is just that people don't know how to do it, and overthink the  
problem.

Oh, I just now signed two more of my top-level zones.   13 minutes to  
do two of them, and this was doing it manually, with no shell scripts  
to automate it.   Of course, they're in .COM and .ORG, so there's no  
trust anchor yet, but hopefully there will be some day.

ng:

  - tracking down and reading Olaf's rather verbose but quite helpful
    document on setting it up (http://www.nlnetlabs.nl/dnssec_howto/)
  - debugging two problems with my zone that weren't DNSSEC-related,
    but that the DNSSEC signer wouldn't allow
  - finding a registrar who was happy to communicate with me in English,
    since I don't speak Swedish (thanks, Patrik!)
  - registering a new domain, not just setting up DNSSEC.

Maybe I did it wrong, but it seemed pretty easy to me.   I think the  
problem is just that people don't know how to do it, and overthink the  
problem.

Oh, I just now signed two more of my top-level zones.   13 minutes to  
do two of them, and this was doing it manually, with no shell scripts  
to automate it.   Of course, they're in .COM and .ORG, so there's no  
trust anchor yet, but hopefully there will be some day.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Aug 2008 11:15:22 -0700

>>>>> On Wed, 13 Aug 2008 19:21:44 +0200, Ralf Weber <[email-masked]> said:

RW> Hmm, assuming that we both did use the same name server software my
RW> experiences are different. Compared to regular DNS setting up and more
RW> importantly maintaining DNSSEC is much more work than normal DNS stuff
RW> (zone resigning, key rollover) . I am not saying that the cost
RW> generally  outweighs the benefit, but with the current tools it is
RW> hard to justify DNSSEC usage, at least for the majority of ISPs out
RW> there. But I do hope that the tools get better and thus the cost of
RW> deploying DNSSEC decreases and we will all happily use it and can
RW> justify it's usage.

I suspect there are many different tools out there and some are easier
than others.  Here's a screen dump of stuff that works easily for me:

  # yum install dnssec-tools

  # head example.com
  $TTL 3600
  ; File written on Thu Dec 23 14:13:02 2004
  ; dnssec_signzone version 9.3.0
  example.com.    600     IN SOA  test.example.com. admin.example.com. (
                                          2004121002 ; serial
                                          7200       ; refresh (2 hours)
                                          3600       ; retry (1 hour)
                                          604800     ; expire (1 week)
                                          600        ; minimum (10 minutes)
                                          )

  # zonesigner -genkeys example.com

          if zonesigner appears hung, strike keys until the program completes
          (see the "Entropy" section in the man page for details)

  zone signed successfully

  example.com:
          KSK (cur) 36712  -b 2048  08/13/08      (example.com-signset-3)
          ZSK (cur) 01857  -b 1024  08/13/08      (example.com-signset-1)
          ZSK (pub) 53523  -b 1024  08/13/08      (example.com-signset-2)

  zone will expire in 4 weeks, 2 days, 0 seconds
  DO NOT delete the keys until this time has passed.

  # cp example.com.signed /etc/named/

  # rndc reload

Oh wait...  i need another record and need to resign...

  # echo "test.example.com. 1D IN A 127.0.0.1" >> example.com

  # zonesigner example.com
          if zonesigner appears hung, strike keys until the program completes
          (see the "Entropy" section in the man page for details)            

  zone signed successfully

  example.com:
          KSK (cur) 36712  -b 2048  08/13/08      (example.com-signset-3)
          ZSK (cur) 01857  -b 1024  08/13/08      (example.com-signset-1)
          ZSK (pub) 53523  -b 1024  08/13/08      (example.com-signset-2)

  zone will expire in 4 weeks, 2 days, 0 seconds
  DO NOT delete the keys until this time has passed.

  # cp example.com.signed /etc/named/

  # rndc reload

Not too hard really.  The only thing you need to add to your current
step for distributing a zone is one new line (the zonesigner line).  The
hardest thing you need to do, IMHO, is make sure you redistribute a new
zone before the current set of stuff expires.  IE, publish it once a
month (using the default setup shown above).  And if that's the hardest
thing for me to do then I don't consider that hard.
-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 13 Aug 2008 11:15:22 -0700

# head example.com
  $TTL 3600

  zone signed successfully

  example.com:

  # rndc reload

  # zonesigner example.com

  zone signed successfully

  example.com:

  # rndc reload

---

From: Ralf Weber <[email-masked]>
Date: Wed, 13 Aug 2008 21:19:07 +0200

Moin!

On Aug 13, 2008, at 20:06 , Ted Lemon wrote:

> You're probably doing too much work.   Why are you doing key rollover?
Well you have to change keys with cryptography from time if you want  
to be save. RFC2541 says once a year, RFC4641 doesn't give any advise,  
but e.g RIPE which referring to this is doing a rollover every 6 months.

>   Why so often?  Why not just use a longer key?   Are you trying for  
> more security than you actually need?
I don't think so. My idea was to do a KSK rollover every 24 months  
with key len >= 2048 and a ZSK rollover every three months with key  
length between 1024 and 2048. But this is work compared to thousands  
of zones we have with SOA serials that are older than two years (We  
have have a lot of zones with SOA Serial <2000 ;-). In DNS world I  
never have to touch them again in DNSSEC world I do have to touch the  
zones regularly.

>   Are you that careful with your SSL certs?
Yup get renewed every two years.

>   And why aren't you signing your zone with a cron job?
Well that's just zone signing and still it is a pain especially if you  
have a server that also does Dynamic updates, as you have to extract  
the raw zone data and put it back in singed. It is doable but IMHO it  
is more a hack than real solution.

As said before the tools out there do not have the automation required  
to make it easy for an operator to deploy DNSSEC widely. But I do have  
faith in you and other people that are building tools and software  
that they will get better.

So long
-Ralf
---
Ralf Weber

---

From: Ralf Weber <[email-masked]>
Date: Wed, 13 Aug 2008 21:19:07 +0200

Moin!

So long
-Ralf
---
Ralf Weber

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 12:48:25 -0700

> but e.g RIPE which referring to this is doing a rollover every 6  

A 2048-bit key will take a really long time to crack.   You need to do  
key rollover often enough that the chances of it being cracked during  
the rollover period are effectively zero.   Two years is a pretty  
conservative period.

If your zone key or KSK is actually compromised, then rollover won't  
help you very much, because it takes too long.   You need to revoke  
the key immediately.   Which is not hard.

> I don't think so. My idea was to do a KFrom [email-masked]  Wed Aug 13 12:48:36 2008
Date: Wed, 13 Aug 2008 12:48:25 -0700

> but e.g RIPE which referring to this is doing a rollover every 6  

A 2048-bit key will take a really long time to crack.   You need to do  
key rollover often enough that the chances of it being cracked during  
the rollover period are effectively zero.   Two years is a pretty  
conservative period.

If your zone key or KSK is actually compromised, then rollover won't  
help you very much, because it takes too long.   You need to revoke  
the key immediately.   Which is not hard.

> I don't think so. My idea was to do a KSKSK rollover every 24 months

Fair enough.   I have zones like that too.

> Yup get renewed every two years.

Okay, so this is a key that's arguably more important than your KSK,  
because it's used to protect authentication information and, depending  
on how you do business, financial information belonging to your  
customers.   If it's safe to roll this key every two years, it's safe  
to roll your KSK no more often, and I would argue that the same is  
true for your zone key.

> that they will get better.

I can't argue with that!   :')

I will point out though that the financial incentive to secure a zone  
varies according to what is done with that zone.   My home domain,  
fugue.com, really doesn't need to be signed, because I only ever use  
it for things where I have adequate application-layer security, and  
nobody's going to punch their credit card info into a faked fugue.com  
domain.   I signed it today anyway just to make a point.

In practice, I think the majority of domains are like mine.   So the  
cost of signing the zones that really need to be signed, in practice,  
is a lot less than the cost of signing every zone in the DNS.

 rollover every 24 months
> never have to touch them again in DNSSEC world I do have to touch the

Fair enough.   I have zones like that too.

> Yup get renewed every two years.

Okay, so this is a key that's arguably more important than your KSK,  
because it's used to protect authentication information and, depending  
on how you do business, financial information belonging to your  
customers.   If it's safe to roll this key every two years, it's safe  
to roll your KSK no more often, and I would argue that the same is  
true for your zone key.

> that they will get better.

I can't argue with that!   :')

I will point out though that the financial incentive to secure a zone  
varies according to what is done with that zone.   My home domain,  
fugue.com, really doesn't need to be signed, because I only ever use  
it for things where I have adequate application-layer security, and  
nobody's going to punch their credit card info into a faked fugue.com  
domain.   I signed it today anyway just to make a point.

In practice, I think the majority of domains are like mine.   So the  
cost of signing the zones that really need to be signed, in practice,  
is a lot less than the cost of signing every zone in the DNS.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 Aug 2008 14:28:30 +0900

Ted Lemon wrote:

> statistics to back up that claim,

I presented the real-world statistical data to support my claim
that DNSSEC requires to much work. That is, it is hardly deployed
because it requires to much work.

In addition, I have talked with several real-world security experts,
unrelated to DNSSEC, on PKI deployment and confirmed that they don't
deploy DNSSEC because, in practice, PKI is not socially very secure.

PKI is deployed by governments and some large organizations such as
credit card companies, which has not enough intelligence (compared to
enough budget to waste) to evaluate real benefit of PKI. But, that's
all.

> and that claim is contrary to my own  

Does your personal experience have any statistical significance?

> Rather, what it 
> says is that .COM is not signed.

To be statistical, which you requested, how many TLDs among many are
signed?

							Masataka Ohta

_______________________________________________
DNSOP mFrom [email-masked]  Wed Aug 13 22:29:05 2008
Date: Thu, 14 Aug 2008 14:28:30 +0900
From: Masataka Ohta <[email-masked]>
To: Ted Lemon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Andrew Sullivan <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

Ted Lemon wrote:

> statistics to back up that claim,

I presented the real-world statistical data to support my claim
that DNSSEC requires to much work. That is, it is hardly deployed
because it requires to much work.

In addition, I have talked with several real-world security experts,
unrelated to DNSSEC, on PKI deployment and confirmed that they don't
deploy DNSSEC because, in practice, PKI is not socially very secure.

PKI is deployed by governments and some large organizations such as
credit card companies, which has not enough intelligence (compared to
enough budget to waste) to evaluate real benefit of PKI. But, that's
all.

> and that claim is contrary to my own  

Does your personal experience have any statistical significance?

> Rather, what it 
> says is that .COM is not signed.

To be statistical, which you requested, how many TLDs among many are
signed?

							Masataka Ohta

DNSOPailing list

 mailing list
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Aug 2008 23:10:17 -0700

> because it requires to much work.

I must have missed that message.

No.

> To be statistical, which you requested, how many TLDs among many are

Sounds like four.   And with the root zone not signed, the pressure on  
the TLDs to sign their zones is essentially zero.   And at least  
according to the latest article on DNSSEC in Wired, the reason why it  
is not signed is that the agency currently responsible for operating  
it wants to study the process further.   No mention was made of the  
difficulty From [email-masked]  Wed Aug 13 23:10:34 2008
From: Ted Lemon <[email-masked]>
To: Masataka Ohta <[email-masked]>
Date: Wed, 13 Aug 2008 23:10:17 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> because it requires to much work.

I must have missed that message.

No.

> To be statistical, which you requested, how many TLDs among many are

Sounds like four.   And with the root zone not signed, the pressure on  
the TLDs to sign their zones is essentially zero.   And at least  
according to the latest article on DNSSEC in Wired, the reason why it  
is not signed is that the agency currently responsible for operating  
it wants to study the process further.   No mention was made of the  
difficulty ofof signing.

 signing.

---

From: Evan Hunt <[email-masked]>
Date: Thu, 14 Aug 2008 07:48:56 +0000

> because it requires to much work.

The reason it's hardly deployed is that people don't see the point.  COM
and the root zone aren't signed, so there's no perceived benefit.  Most
people would agree that *any* amount of work is too much when there's no
perceived benefit.

It would be more interesting to see what percentage of .SE and .BR domains
are signed:  There *is* some perceived benefit there, and an infrastructure
in place.  I would expect the cost/benefit analysis to shift in favor of
DNSSEC under those circumstances.

I actually agree with you that DNSSEC using BIND is more fiddly, arcane
and time-consuming than it ought to be.  (And I intend to improve it.)
But that flaw is in the tools, not the protocol.  There are lots of other
things about network configuration that used to be fiddly and arcane and
have since become simple; you seem to be arguing that DNSSEC won't follow
suit, but I see no technical reason why it shouldn't.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.
________________From [email-masked]  Thu Aug 14 00:49:11 2008
Date: Thu, 14 Aug 2008 07:48:56 +0000
From: Evan Hunt <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> because it requires to much work.

The reason it's hardly deployed is that people don't see the point.  COM
and the root zone aren't signed, so there's no perceived benefit.  Most
people would agree that *any* amount of work is too much when there's no
perceived benefit.

It would be more interesting to see what percentage of .SE and .BR domains
are signed:  There *is* some perceived benefit there, and an infrastructure
in place.  I would expect the cost/benefit analysis to shift in favor of
DNSSEC under those circumstances.

I actually agree with you that DNSSEC using BIND is more fiddly, arcane
and time-consuming than it ought to be.  (And I intend to improve it.)
But that flaw is in the tools, not the protocol.  There are lots of other
things about network configuration that used to be fiddly and arcane and
have since become simple; you seem to be arguing that DNSSEC won't follow
suit, but I see no technical reason why it shouldn't.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.
_________________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

_____________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Fri, 15 Aug 2008 11:10:57 -0400 (EDT)

> Okay, so this is a key that's arguably more important than your KSK, because 
> it's used to protect authentication information and, depending on how you do 
> business, financial information belonging to your customers.   If it's safe 
> to roll this key every two years, it's safe to roll your KSK no more often, 
> and I would argue that the same is true for your zone key.

There are a few differences here. For one, your private ZSK could live
on the nameserver and automatically resign your zone, while you keep your
KSK is secure offline storage. Though some people will want to keep the
ZSK offline as well. Second, changing the KSK requires talking to the
upstream to get the DS record published at the parent. This takes more
work and is currently not automated. You don't want to do this every
month.

>> to make it easy for an operator to deploy DNSSEC widely.

I have to disagree with that of course, as my company has made such a
tool :)

> I will point out though that the financial incentive to secure a zone varies 
> according to what is done with that zone.   My home domain, fugue.com, really 
> doFrom [email-masked]  Fri Aug 15 08:25:36 2008
Date: Fri, 15 Aug 2008 11:10:57 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Ted Lemon <[email-masked]>
Cc: Ralf Weber <[email-masked]>, "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

> Okay, so this is a key that's arguably more important than your KSK, because 
> it's used to protect authentication information and, depending on how you do 
> business, financial information belonging to your customers.   If it's safe 
> to roll this key every two years, it's safe to roll your KSK no more often, 
> and I would argue that the same is true for your zone key.

There are a few differences here. For one, your private ZSK could live
on the nameserver and automatically resign your zone, while you keep your
KSK is secure offline storage. Though some people will want to keep the
ZSK offline as well. Second, changing the KSK requires talking to the
upstream to get the DS record published at the parent. This takes more
work and is currently not automated. You don't want to do this every
month.

>> to make it easy for an operator to deploy DNSSEC widely.

I have to disagree with that of course, as my company has made such a
tool :)

> I will point out though that the financial incentive to secure a zone varies 
> according to what is done with that zone.   My home domain, fugue.com, really 
> esn't need to be signed, because I only ever use it for things where I have 
> adequate application-layer security, and nobody's going to punch their credit 
> card info into a faked fugue.com domain.   I signed it today anyway just to 
> make a point.

How much do you place trust in your home domain with your laptop? I'd
say especially your own personal domains would need to be secure. Whether
I get a fake CNN.com page is much less important to me then whether my nfs
or mail server can be access by something. Also, I put valuable data, such
as SSHFP and IPSECKEY records in my 'personal' domains, and those I clearly
want to be protected.

Paul

doesn't need to be signed, because I only ever use it for things where I have 
> adequate application-layer security, and nobody's going to punch their credit 
> card info into a faked fugue.com domain.   I signed it today anyway just to 
> make a point.

How much do you place trust in your home domain with your laptop? I'd
say especially your own personal domains would need to be secure. Whether
I get a fake CNN.com page is much less important to me then whether my nfs
or mail server can be access by something. Also, I put valuable data, such
as SSHFP and IPSECKEY records in my 'personal' domains, and those I clearly
want to be protected.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Aug 2008 09:15:17 -0700

On Aug 15, 2008, at 8:10 AM, Paul Wouters wrote:
> Whether
> or mail server can be access by something

I'm not sure how relevant this is to the discussion, but I'll answer  
the question anyway.  I don't use NFS because (a) it doesn't work very  
well in cross-platform environments and (b) its security model is "I  
am the gooey center that your firewall must protect."   And I pay  
about $100/year to use SSL certs to protect all my IMAP, POP, SMTP and  
HTTP transactions.   And I use ssh for From [email-masked]  Fri Aug 15 09:15:46 2008
From: Ted Lemon <[email-masked]>
To: Paul Wouters <[email-masked]>
Date: Fri, 15 Aug 2008 09:15:17 -0700
Cc: Ralf Weber <[email-masked]>, "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Kaminsky on djbdns bugs (fwd)
Sender: [email-masked]

On Aug 15, 2008, at 8:10 AM, Paul Wouters wrote:
> Whether
> or mail server can be access by something

I'm not sure how relevant this is to the discussion, but I'll answer  
the question anyway.  I don't use NFS because (a) it doesn't work very  
well in cross-platform environments and (b) its security model is "I  
am the gooey center that your firewall must protect."   And I pay  
about $100/year to use SSL certs to protect all my IMAP, POP, SMTP and  
HTTP transactions.   And I use ssh foremote login, which if it is  
working correctly and not vulnerable to some zero-day hack should  
prevent MitM attacks from succceeding.

I don't see DNSSEC as being necessary to protect those protocols.    
Once I succeed in talking to my server, I'm probably really talking to  
my server.   What I want DNSSEC for is to block the potential phishing  
attacks we've talked about.   Securing my zones, and adding a signed  
zone in .se, are all steps on the way to that result.

But until we have root and .com signed, and until the average end-user  
is protected by a validating resolver, we aren't done yet, and I don't  
really get any actual benefit from my efforts.   Which, tragically, is  
why it's taking so long.

The reason I signed these zones is because I'm trying to increase the  
net expertise in the world at doing these things by one head (mine)  
and hoping to inspire others to follow suit.   The more of us non- 
DNSSEC-experts who decide they want DNSSEC and take the time to learn  
how to make it happen, the sooner it will actually happen, because we  
are the ones who will actually make it happen.

r remote login, which if it is  
working correctly and not vulnerable to some zero-day hack should  
prevent MitM attacks from succceeding.

I don't see DNSSEC as being necessary to protect those protocols.    
Once I succeed in talking to my server, I'm probably really talking to  
my server.   What I want DNSSEC for is to block the potential phishing  
attacks we've talked about.   Securing my zones, and adding a signed  
zone in .se, are all steps on the way to that result.

But until we have root and .com signed, and until the average end-user  
is protected by a validating resolver, we aren't done yet, and I don't  
really get any actual benefit from my efforts.   Which, tragically, is  
why it's taking so long.

The reason I signed these zones is because I'm trying to increase the  
net expertise in the world at doing these things by one head (mine)  
and hoping to inspire others to follow suit.   The more of us non- 
DNSSEC-experts who decide they want DNSSEC and take the time to learn  
how to make it happen, the sooner it will actually happen, because we  
are the ones who will actually make it happen.

---

From: David Conrad <[email-masked]>
Date: Fri, 15 Aug 2008 11:29:13 -0700

Hi,

On Aug 15, 2008, at 9:15 AM, Ted Lemon wrote:
> But until we have root and .com signed, and until the average end- 
> user is protected by a validating resolver, we aren't done yet, and  
> I don't really get any actual benefit from my efforts.   Which,  
> tragically, is why it's taking so long.

There are people who appear to think deploying DNSSEC as soon as  
possible would be a good thing.  There are also people who appear to  
think deploying DNSSEC is a fools errand, that it won't get  
significant use because it makes things too hard, too complicated, too  
prone to failure, etc.

However, because of DO, folks who don't configure their resolvers to  
do DNSSEC shouldn't ever see any DNSSEC goop.

Given this, does anyone see any DNS security and/or stability concerns  
if a miracle were to happen and the root were to be signed tomorrow?

That is, if you don't care about DNSSEC, do you think it would be  
bad(tm) if the root were to be signed (for the sake of argument,  
ignore the time waste, administrative overhead, etc. associated with  
DNSSEC-signing)?  If so, why?

Thanks,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 15 Aug 2008 11:29:13 -0700

Hi,

Thanks,
-drc

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 15 Aug 2008 16:05:45 -0300

> if a miracle were to happen and the root were to be signed tomorrow?

Having signed a large delegation centric zone and as expected not
seeing any security/stability issue for a significant amount of time I
would say NO.

> bad(tm) From [email-masked]  Fri Aug 15 12:05:45 2008
Date: Fri, 15 Aug 2008 16:05:45 -0300
From: Frederico A C Neves <[email-masked]>
To: David Conrad <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
	(fwd))
Sender: [email-masked]

> if a miracle were to happen and the root were to be signed tomorrow?

Having signed a large delegation centric zone and as expected not
seeing any security/stability issue for a significant amount of time I
would say NO.

> DNSSEC-signing)?  If so, why?

Ok, I do care but the answer is still NO. Besides the large amount of
statements accusing if of being a pig-protocol it is really well
thought on incremental deployment for clients.

> -drc

Fred

if the root were to be signed (for the sake of argument,  
> DNSSEC-signing)?  If so, why?

Ok, I do care but the answer is still NO. Besides the large amount of
statements accusing if of being a pig-protocol it is really well
thought on incremental deployment for clients.

> -drc

Fred

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Aug 2008 12:26:02 -0700

At 11:29 AM -0700 8/15/08, David Conrad wrote:
>Given this, does anyone see any DNS security and/or stability 
>concerns if a miracle were to happen and the root were to be signed 
>tomorrow?

Yes, at the time of the first root key rollover. Well, to be more 
specific, at the time that all of the keys in the first announced set 
of root keys have been retired. Given the little effort that has been 
made in helping rDNS operators understand that they have to keep 
their trust anchors up to date, we should expect them to treat trust 
anchors the same way they treat root hints.

Even if the root rollovers are done following RFC 5011, this only 
helps rDNS operators running 5011-aware resolvers. All the rest will 
be out of luck when the last key they have in their dusty config file 
is removed.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Aug 2008 12:26:02 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Fri, 15 Aug 2008 13:01:13 -0700

Paul,

On Aug 15, 2008, at 12:26 PM, Paul Hoffman wrote:
> Yes, at the time of the first root key rollover.

If you haven't configured DNSSEC in your caching server (that is, you  
don't think DNSSEC is worth your time), I have some skepticism that  
you'd have concern about key rollover.

You're asking a different question than the one I'm asking.  While I  
agree the question you're answering (specifically, should DNSSEC be  
deployed without a better way of ensuring root key rollover doesn't  
spontaneously break the DNS) is important, I'm trying to understand  
something different.

Let me try to (hopefully) more clearly articulate my question: given  
the fact that caching servers only care about DNSSEC if they're  
explicitly configured to doFrom [email-masked]  Fri Aug 15 13:01:13 2008
From: David Conrad <[email-masked]>
To: Paul Hoffman <[email-masked]>
Date: Fri, 15 Aug 2008 13:01:13 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
	(fwd))
Sender: [email-masked]

Paul,

On Aug 15, 2008, at 12:26 PM, Paul Hoffman wrote:
> Yes, at the time of the first root key rollover.

If you haven't configured DNSSEC in your caching server (that is, you  
don't think DNSSEC is worth your time), I have some skepticism that  
you'd have concern about key rollover.

You're asking a different question than the one I'm asking.  While I  
agree the question you're answering (specifically, should DNSSEC be  
deployed without a better way of ensuring root key rollover doesn't  
spontaneously break the DNS) is important, I'm trying to understand  
something different.

Let me try to (hopefully) more clearly articulate my question: given  
the fact that caching servers only care about DNSSEC if they're  
explicitly configured to  so, does anyone anticipate any stability/ 
security concerns to those folks who _haven't_ configured DNSSEC if  
the root is signed?

Thanks,
-drc

do so, does anyone anticipate any stability/ 
security concerns to those folks who _haven't_ configured DNSSEC if  
the root is signed?

Thanks,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Aug 2008 13:51:22 -0700

At 1:01 PM -0700 8/15/08, David Conrad wrote:
>explicitly configured to do so, does anyone anticipate any 
>stability/security concerns to those folks who _haven't_ configured 
>DNSSEC if the root is signed?

Ah. Better question. My previous answer was for a different question.

If what you really, really mean to ask is "given the fact that 
caching servers only care about DNSSEC if they're explicitly 
configured to do so, does anyone anticipate any stability/security 
concerns to those folks who _don't_ configure DNSSEC if the root is 
signed?", then I would say no, I don't see any.

As to your question above: people who _haven't_ configured DNSSEC 
_will_ configure DNSSEC after the root is signed due to lots of press 
and the general feeling that more security layers are good. If we 
don't give those people the right tools to properly configure and 
properly maintain those configurations, there will be stability 
issues, as I listed earlier.

Sorry to be so picky about this, but this WG in particular is 
responsible for giving operational advice for the DNS, and I believe 
that there are certain things that will cause more people to have DNS 
operational issues. The publicity aftermath to signing the root is 
completely predictable, and will greatly increase the number of 
resolvers with DNSSEC turned on; it will also greatly increase the 
number of resolver operators who need more help in running their 
resolvers correctly.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Aug 2008 13:51:22 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Fri, 15 Aug 2008 16:07:03 -0700

Paul,

> signed?", then I would say no, I don't see any.

OK, thanks.  I suspect this question will be coming from on high at  
some point...

> _will_ configure DNSSEC after the root is signed due to lots of  
> press and the general feeling that more security layers are good. If  
> we don't give those people the right tools to properly configure and  

This reads a bit to me like "build it and they will come and hit  
themselves upside their heads with bats, so don't build it until we've  
figured out how to keep people from hurting themselves."

If someone configures DNSSEC in their caching server and then forgets  
their care and feeding duties, they will at some point discover that  
their DNS lookups aren't working so well and they'll either undertake  
their care and feeding duties with a bit more diligence (and/or  
upgrade to newer technology that handles care and feeding duties with  
minimal manual intervention) or they'll turn off DNSSEC.  So, in the  
worst case, they'll get bitten and revert back to the same level of  
security (or lack thereof) they have today.

Is this worth blocking DNSSEC deployment?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Fri, 15 Aug 2008 16:07:03 -0700

Paul,

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 Aug 2008 16:42:40 -0700

At 4:07 PM -0700 8/15/08, David Conrad wrote:
>>press and the general feeling that more security layers aFrom [email-masked]  Fri Aug 15 16:42:45 2008
Date: Fri, 15 Aug 2008 16:42:40 -0700
To: David Conrad <[email-masked]>
From: Paul Hoffman <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
 (fwd))
Sender: [email-masked]

At 4:07 PM -0700 8/15/08, David Conrad wrote:
>>press and the general feeling that more security layersre good. 
>>If we don't give those people the right tools to properly configure 
>>and properly maintain those configurations, there will be stability 
>themselves upside their heads with bats, so don't build it until 
>we've figured out how to keep people from hurting themselves."

s/keep people/keep most people/  Yes.

>If someone configures DNSSEC in their caching server and then 
>forgets their care and feeding duties, they will at some point 
>discover that their DNS lookups aren't working so well and they'll 
>either undertake their care and feeding duties with a bit more 
>diligence (and/or upgrade to newer technology that handles care and 
>feeding duties with minimal manual intervention) or they'll turn off 
>DNSSEC.

The above assumes that all the DNSSEC-capable resolvers have error 
messages for "the trust anchor for .tld has gone bad and here is what 
you can do about it" that are as easy to understand as "the trust 
anchor for .tld has gone bad and here is what you can do about it". 
That seems pretty unlikely from recent history. Even the "you might 
want to turn off DNSSEC until you understand what is happening" is a 
bit of a stretch with current resolver software.

>So, in the worst case, they'll get bitten and revert back to the 
>same level of security (or lack thereof) they have today.

Fully agree.

>Is this worth blocking DNSSEC deployment?

Nope, but that is not what you asked. You asked for "any 
stability/security concerns", not blocking concerns.

--Paul Hoffman, Director
--VPN Consortium

 are good. 
>>If we don't give those people the right tools to properly configure 
>>and properly maintain those configurations, there will be stability 
>themselves upside their heads with bats, so don't build it until 
>we've figured out how to keep people from hurting themselves."

s/keep people/keep most people/  Yes.

>If someone configures DNSSEC in their caching server and then 
>forgets their care and feeding duties, they will at some point 
>discover that their DNS lookups aren't working so well and they'll 
>either undertake their care and feeding duties with a bit more 
>diligence (and/or upgrade to newer technology that handles care and 
>feeding duties with minimal manual intervention) or they'll turn off 
>DNSSEC.

The above assumes that all the DNSSEC-capable resolvers have error 
messages for "the trust anchor for .tld has gone bad and here is what 
you can do about it" that are as easy to understand as "the trust 
anchor for .tld has gone bad and here is what you can do about it". 
That seems pretty unlikely from recent history. Even the "you might 
want to turn off DNSSEC until you understand what is happening" is a 
bit of a stretch with current resolver software.

>So, in the worst case, they'll get bitten and revert back to the 
>same level of security (or lack thereof) they have today.

Fully agree.

>Is this worth blocking DNSSEC deployment?

Nope, but that is not what you asked. You asked for "any 
stability/security concerns", not blocking concerns.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Andrews <[email-masked]>
Date: Sat, 16 Aug 2008 10:30:18 +1000

> HTTP transactions.   And I use ssh for remote login, which if it is  

	Most people talk to 1 IMAP server.
	Most people talk to 1 POP server.
	Most people talk to 1 SMTP *submission* server.

	There are no scaling issues to deal with here even using
	private certificates.  You also know the name of the ssl
	certificate you are looking for.

	For SMTP, MTA to MTA security, you need DNSSEC to validate
	the MX RRset so you can know which SSL cert to check for.

> zone in .se, are all steps on the way to that result.

	DNSSEC cannot prevent phishing attacks (name *similar* to
	target name).
 
> But until we have root and .com signed, and until the aFrom [email-masked]  Fri Aug 15 17:30:29 2008
Date: Sat, 16 Aug 2008 10:30:18 +1000

> HTTP transactions.   And I use ssh for remote login, which if it is  

	Most people talk to 1 IMAP server.
	Most people talk to 1 POP server.
	Most people talk to 1 SMTP *submission* server.

	There are no scaling issues to deal with here even using
	private certificates.  You also know the name of the ssl
	certificate you are looking for.

	For SMTP, MTA to MTA security, you need DNSSEC to validate
	the MX RRset so you can know which SSL cert to check for.

> zone in .se, are all steps on the way to that result.

	DNSSEC cannot prevent phishing attacks (name *similar* to
	target name).
 
> But until we have root and .com signed, and until the aveverage end-user  

rage end-user

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Aug 2008 14:38:39 +0200

On 15 aug 2008, at 22.01, David Conrad wrote:

> explicitly configured to do so, does anyone anticipate any stability/ 

Good question David, thanks for asking it.

My view is that the answer is NO.

Yes, just because the root is signed, we will see an uptake in the  
number of resolvers choosing to verify DNSSEC signed responses.

Yes, people will shoot themselves in the foot by forgetting the trust  
anchors, but as you have pointed out, they will discover this pretty  
quickly and then either go back to where they are today (turn off  
DNSSEC verification), or update the trust anchor.

I am though of the view that we many times in the Internet  
Architecture have created tools that give the ability to people to  
shoot themselves in their foot. Sometimes both at the same time!

But, as DNSSEC is an opt-in technology, people really have to first do  
a active opt-in action before they find their feet hurt. People can  
with a signed root choose themselves whether they want to participate  
or not.

I am today much more worried about doing "too much" signing of leaf  
nodes of the DNS tree before we can start do the signing of nodes from  
root and down the tree. Regardless of how well TAR's will work, I  
claim the ability to damage ones feet increase with the number of  
signed zones before the root is signed. But don't ask me at what  
number of TLDs (say) we pass the line of "too many".

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 16 Aug 2008 14:38:39 +0200

Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 07:24:38 +0900

> if a miracle were to happen and the root were to be signed tomorrow?

Well,it will introduce a lot of large RRs, which may cause problems.

Considering that two RRs each containing 2048 bit data will need
oversized messages, they may not be properly treated by some
servers.

Those suffering from oversized messages may turn-off DNSSEC and there
is instability for those moving with their laptops.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 07:24:38 +0900

Masataka Ohta

---

From: Dean Anderson <[email-masked]>
Date: Sat, 16 Aug 2008 19:56:06 -0400 (EDT)

People who think they don't care about DNSSEC now, should still be
concerned about any changes to root and TLD servers and should be
concerned about the consequences of those changes in the future.  There
really are no changes that have zero impact.

> DNSSEC-signing)?  If so, why?

I think this would be bad(tm). There are number of serious unresolved
DNSSEC issues--the resolution of which are anticipated to change the
protocol.  For example, besides the previously mentioned key rollover
issue, I understand that DNSSEC also doesn't allow the protocol to be
changed securely.  And we do expect the protocol to be changed.

DNSSEC deployment on the root and TLDs will merely encourage people to
invest in deploying DNSSEC servers and resolvers. Such deployment merely
makes changes to the protocol more difficult, since changes cause those
initial users to be exposed, after they have relied on secure DNS. We 
should not encourage people to rely on DNS for security.

The hype surrounding the Kaminsky report is unjustified.  For example,
one can't steal bank information with this attack, as the mainstream
press has reported.  SSL/TLS validates the certificates
cryptographically and doesn't depend on DNS, except of course that wrong
DNS information could lead to a Denial of Service attack.  DNS
information in a certificate is merely used to From [email-masked]  Sat Aug 16 16:56:12 2008
Date: Sat, 16 Aug 2008 19:56:06 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: David Conrad <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>, Ted Lemon <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
 (fwd))
Sender: [email-masked]

People who think they don't care about DNSSEC now, should still be
concerned about any changes to root and TLD servers and should be
concerned about the consequences of those changes in the future.  There
really are no changes that have zero impact.

> DNSSEC-signing)?  If so, why?

I think this would be bad(tm). There are number of serious unresolved
DNSSEC issues--the resolution of which are anticipated to change the
protocol.  For example, besides the previously mentioned key rollover
issue, I understand that DNSSEC also doesn't allow the protocol to be
changed securely.  And we do expect the protocol to be changed.

DNSSEC deployment on the root and TLDs will merely encourage people to
invest in deploying DNSSEC servers and resolvers. Such deployment merely
makes changes to the protocol more difficult, since changes cause those
initial users to be exposed, after they have relied on secure DNS. We 
should not encourage people to rely on DNS for security.

The hype surrounding the Kaminsky report is unjustified.  For example,
one can't steal bank information with this attack, as the mainstream
press has reported.  SSL/TLS validates the certificates
cryptographically and doesn't depend on DNS, except of course that wrong
DNS information could lead to a Denial of Service attack.  DNS
information in a certificate is merely used tverify the correct
certificate was returned before trying cryptographic verification. Cache
poisoning results in failure to get the correct certificate unless there
is a corresponding failure in the CA.  Certificate verification is the
better approach to establish secure connections.

There has been some assertions that SMTP anti-spam security depends on
DNS security. These schemes don't hold water. In 2003, I showed that the
information theory result that no communication system can be proven
free of covert channels implies that no communication system can be
designed 'spam-free'. So, changes to DNS or SMTP to defeat spam are
doomed to failure. Experience with failures of anti-spam schemes over
the last 10+ years is consistent with this analysis.  Ideas like
micro-payments and such are also doomed to failure for the same reasons.  
Defeating spam is a question of getting better at 'whack-a-mole',
improving communication between ISPs to track abuse, eliminating false
teaming of spammers in anti-spam operations, and having adequate legal
responses particularly against botnets.

Of course, the people hoping to sell authentication systems,
micropayment systems, etc plainly won't agree, but then people selling
perpetual motion machines similarly don't agree with the conclusions of
thermodynamics.  However, physicists and government demand to see that
the laws of thermodynamics aren't violated before funding research on
new energy systems. Similarly, I think that before we make expensive
changes to accommodate anti-spam schemes, that we should first ensure
that the laws of information theory aren't violated by the scheme.

I also seem to recall some claims that DNSSEC can create more
opportunity for cryptographic DOS attacks on DNS servers.  Can anyone
speak to that?

In conclusion, deploying DNSSEC before its ready will encourage people
to wrongly place MORE trust in DNS information, even though those people
will be exposed to greater expense and risk later.  This is a
dis-service to the public, especially when key rollover and expected
protocol changes will expose them to untrustworthy operation in the
future. Knee-jerk reactions are almost always a bad-idea, especially
when the reaction has the potential to be worse than problem.

		--Dean

o verify the correct
certificate was returned before trying cryptographic verification. Cache
poisoning results in failure to get the correct certificate unless there
is a corresponding failure in the CA.  Certificate verification is the
better approach to establish secure connections.

There has been some assertions that SMTP anti-spam security depends on
DNS security. These schemes don't hold water. In 2003, I showed that the
information theory result that no communication system can be proven
free of covert channels implies that no communication system can be
designed 'spam-free'. So, changes to DNS or SMTP to defeat spam are
doomed to failure. Experience with failures of anti-spam schemes over
the last 10+ years is consistent with this analysis.  Ideas like
micro-payments and such are also doomed to failure for the same reasons.  
Defeating spam is a question of getting better at 'whack-a-mole',
improving communication between ISPs to track abuse, eliminating false
teaming of spammers in anti-spam operations, and having adequate legal
responses particularly against botnets.

Of course, the people hoping to sell authentication systems,
micropayment systems, etc plainly won't agree, but then people selling
perpetual motion machines similarly don't agree with the conclusions of
thermodynamics.  However, physicists and government demand to see that
the laws of thermodynamics aren't violated before funding research on
new energy systems. Similarly, I think that before we make expensive
changes to accommodate anti-spam schemes, that we should first ensure
that the laws of information theory aren't violated by the scheme.

I also seem to recall some claims that DNSSEC can create more
opportunity for cryptographic DOS attacks on DNS servers.  Can anyone
speak to that?

In conclusion, deploying DNSSEC before its ready will encourage people
to wrongly place MORE trust in DNS information, even though those people
will be exposed to greater expense and risk later.  This is a
dis-service to the public, especially when key rollover and expected
protocol changes will expose them to untrustworthy operation in the
future. Knee-jerk reactions are almost always a bad-idea, especially
when the reaction has the potential to be worse than problem.

		--Dean

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Aug 2008 17:27:57 -0700

On Aug 16, 2008, at 4:56 PM, Dean Anderson wrote:
> For example, besides the previously mentioned key rollover

As a non-expert in DNSSEC, I have to admit that I am not aware of an  
expectation that the protocol will change.   Can you expand on this?    
Also, is there a way to build the protocol so that it can be changed  
securely?   I would think that the way this would happen would be that  
the resolver would ask different, or additional, questions.   Does the  
current protocol preclude that?

> press has reported.

This isn't true, because if I can convince you that a naive user that  
he or she is talking to your bank, I can get them to enter their  
information into a web page that isn't protected by SSL.

Alternatively, I can find a server that has a valid SSL cert, crack  
it, set up a redirect that sends the user's password through that  
server.   They wind up doing an SSL-validated transaction that appears  
to be completely fine, but is not.   Since I've suborned an existing  
server, even once the hack is discovered, if it is, it can't be traced  
back to me through the SSL cert trust chain.

It's true that some modifications to the browser would mitigate this,  
but those modifications would go against current practice - it's not  
uncommon for authentication to go through some kind of cross-site  
redirect.   So there is a risk that if browsers were modified to do  
this, people would disable the feature.

Furthermore, since preventing this attack depends on changes to  
browsers, such changes would only protect those people who routinely  
upgrade their browsers; unfortunately, those are the same people who  
are least likely to be fooled by an attack like this in the first place.

So while I realize that there has been a lot of theatre around the  
Kaminsky attack, I have to say that it still seems very credible to me.

> designed 'spam-free'.

I think you carry this argument a bit farther than is justified.    
It's probably true that no security system can be perfect.   Locks  
don't keep out determined lock pickers.   They certainly don't keep  
out people with fire axes.   But they do raise the cost of entry.

That's what a good computer security system does too.   That's the  
goal of DNSSEC.   Of course DNSSEC is still crackable, and of course  
people will imagine that it is not, in much the same way that they  
place too much trust in locks.   The question is, are they better off  
with the lock, or without it.   I don't think you've really spoken to  
that question here.

> opportunity for cryptographic DOS attacks on DNS servers.  Can anyone

You could definitely DoS a validating resolver by asking too many  
questions.   To the extent that people do that, it seems likely that  
the point of validation will move closer and closer to the end-user.    
So to me this seems like a problem whose solution actually improves  
security, and therefore it's kind of problem we'd like to have.   But  
you're right that it's a problem.

In practice, I expect that the way DNSSEC resolvers will be deployed  
initially is that people will install them on their own computers.    
The same caching resolvers may be used, since DNSSEC works through  
caching resolvers.   So the infrastructure won't change much, and the  
early adopters won't suffer from the DoS problem.

However, if part of the deployment involves putting DNSSEC-validating  
resolvers in the DNS caching servers, then there will be an  
opportunity for DoS attacks, and so deployments of that type will have  
to be done very carefully.

However, I think the fear of this particular sort of attack isn't  
substantial enough to justify not signing the root zone or the TLDs.    
As I understand it, preventing cryptographic DoS attacks on  
authoritative name servers is one of the key features of the current  
DNSSEC architecture.   But as I say, I'm not an expert, so if I'm  
wrong about this I'd like to hear why.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Aug 2008 17:27:57 -0700

---

From: Mark Andrews <[email-masked]>
Date: Sun, 17 Aug 2008 13:23:02 +1000

> is instability for those moving with their laptops.

	And how is this different from the answers from TLDs which
	have already turned on DNSSEC?

---

From: Mark Andrews <[email-masked]>
Date: Sun, 17 Aug 2008 13:23:02 +1000

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 00:35:16 -0400 (EDT)

> expectation that the protocol will change.   Can you expand on this?    

I'm also a non-expert on DNSSEC.  I take this excerpt from Olaf
Kolkman's message of December 1, 2007: as indicating that it will need
to change:

Begin quote ======================================================
> Please speak up if this change is of concern to you.
> If no one speaks up by Dec 7'th I will tell our AD the changes are
> fine.

So the change is that the basic-4 steps procedure was removed and
replaced with text that amounts to "We'll solve this when we get to
this".

For those who are not up to speed with the issue that is being
addressed, the thread causing all this starts here:
http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html

To me it is clear that the current text postpones dealing with the
problem that starts with the premisses in Sam Weiler's observation:
    "but we aren't (as far as I can tell) requiring that an NSEC3-
SHA256-capable resolver also support NSEC3-SHA1"

If the requirement to support old algorithms would exist, then the
rollover is one that we currently understand.
End quote ===========================================================

> Also, is there a way to build the protFrom [email-masked]  Sat Aug 16 21:35:19 2008
Date: Sun, 17 Aug 2008 00:35:16 -0400 (EDT)

> expectation that the protocol will change.   Can you expand on this?    

I'm also a non-expert on DNSSEC.  I take this excerpt from Olaf
Kolkman's message of December 1, 2007: as indicating that it will need
to change:

Begin quote ======================================================
> Please speak up if this change is of concern to you.
> If no one speaks up by Dec 7'th I will tell our AD the changes are
> fine.

So the change is that the basic-4 steps procedure was removed and
replaced with text that amounts to "We'll solve this when we get to
this".

For those who are not up to speed with the issue that is being
addressed, the thread causing all this starts here:
http://ops.ietf.org/lists/namedroppers/namedroppers.2007/msg00553.html

To me it is clear that the current text postpones dealing with the
problem that starts with the premisses in Sam Weiler's observation:
    "but we aren't (as far as I can tell) requiring that an NSEC3-
SHA256-capable resolver also support NSEC3-SHA1"

If the requirement to support old algorithms would exist, then the
rollover is one that we currently understand.
End quote ===========================================================

> Also, is there a way to build the protococol so that it can be changed  
> securely? 

Hopefully, there is.  Though mainly, I think the problem is the hash
change problem.

>   I would think that the way this would happen would be that  

I suppose not. But changing resolvers repeatedly is a big problem,
because you have to support the old resolvers.  The zones are quite
large with the current records.

> back to me through the SSL cert trust chain.

The above attacks aren't dependent on DNS attacks.  

- If the user is naive and doesn't check that connection is secure and
that the certificate belongs to their bank, then they are subject to any
number of schemes.

- If Mal cracks someone else's server, that server still doesn't have
the bank's certificate, and won't have the bank's dns domain, either.  
So the browser should think that it got the wrong certificate. 

The user should always check that they have the right certificate and
that it verifies correctly. If the user doesn't do that, no amount of
DNS security will save them from a variety of phishing or
similar-URL/similar-domain attacks. Every browser that I know of allows
the user to examine the certificate and its validation.  If the user
fails to check this, they lose.

This thread is quite interesting:
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00853.html

> > There has been some assertions that SMTP anti-spam security depends
> > on DNS security. These schemes don't hold water. In 2003, I showed
> > that the information theory result that no communication system can
> > be proven free of covert channels implies that no communication
> > system can be designed 'spam-free'.
> 

I'll try to keep it pertinent to DNSSEC. In this case, the cost of entry
is the botnet, and the cost isn't altered at all by DNSSEC, or by SMTP
alteration, micropayments, estamps, SPF, or what have you. Once the
computer is controlled by a virus, the attacker has the user's
credentials--all of the credentials.  Adding more layers of
authentication can't change anything.  People seem to have a hard time
understanding that the virus on their computer is, electronically,
_them_.

		--Dean

ol so that it can be changed  
> securely? 

Hopefully, there is.  Though mainly, I think the problem is the hash
change problem.

>   I would think that the way this would happen would be that  

I suppose not. But changing resolvers repeatedly is a big problem,
because you have to support the old resolvers.  The zones are quite
large with the current records.

> back to me through the SSL cert trust chain.

The above attacks aren't dependent on DNS attacks.  

- If the user is naive and doesn't check that connection is secure and
that the certificate belongs to their bank, then they are subject to any
number of schemes.

- If Mal cracks someone else's server, that server still doesn't have
the bank's certificate, and won't have the bank's dns domain, either.  
So the browser should think that it got the wrong certificate. 

The user should always check that they have the right certificate and
that it verifies correctly. If the user doesn't do that, no amount of
DNS security will save them from a variety of phishing or
similar-URL/similar-domain attacks. Every browser that I know of allows
the user to examine the certificate and its validation.  If the user
fails to check this, they lose.

This thread is quite interesting:
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00853.html

> > There has been some assertions that SMTP anti-spam security depends
> > on DNS security. These schemes don't hold water. In 2003, I showed
> > that the information theory result that no communication system can
> > be proven free of covert channels implies that no communication
> > system can be designed 'spam-free'.
> 

I'll try to keep it pertinent to DNSSEC. In this case, the cost of entry
is the botnet, and the cost isn't altered at all by DNSSEC, or by SMTP
alteration, micropayments, estamps, SPF, or what have you. Once the
computer is controlled by a virus, the attacker has the user's
credentials--all of the credentials.  Adding more layers of
authentication can't change anything.  People seem to have a hard time
understanding that the virus on their computer is, electronically,
_them_.

		--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 13:56:35 +0900

> 	have already turned on DNSSEC?

Though I never said answers from root servers is oversized,
if some server under such TLD generates oversized messages,
there should be instability observed.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 13:56:35 +0900

Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Aug 2008 22:09:15 -0700

> So the browser should think that it got the wrong certificate.

No, that wasn't my point.   My point is that sometimes browsers will  
warn you if you submit a form to a non-SSL server.   So an attacker  
can get rid of that warning by suborning an SSL server and directing  
your response toward it.   You won't get a warning that your data is  
being submitted over an insecure link, because it's not.   The link is  
perfectly secure - the problem is that it's the wrong link, and  
someone's listening on the other end who shouldn't be.

You can change browsers so that they warn you when you submit a form  
to a secure form on a server that's not the one that served you the  
form, but AFAIK browsers right now do not warn you in this situation,  
and it's not at all uncommon for legitimate web sites to redirect you  
in From [email-masked]  Sat Aug 16 22:09:23 2008
From: Ted Lemon <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Sat, 16 Aug 2008 22:09:15 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
	(fwd))
Sender: [email-masked]

> So the browser should think that it got the wrong certificate.

No, that wasn't my point.   My point is that sometimes browsers will  
warn you if you submit a form to a non-SSL server.   So an attacker  
can get rid of that warning by suborning an SSL server and directing  
your response toward it.   You won't get a warning that your data is  
being submitted over an insecure link, because it's not.   The link is  
perfectly secure - the problem is that it's the wrong link, and  
someone's listening on the other end who shouldn't be.

You can change browsers so that they warn you when you submit a form  
to a secure form on a server that's not the one that served you the  
form, but AFAIK browsers right now do not warn you in this situation,  
and it's not at all uncommon for legitimate web sites to redirect you  
ithis way.

> that it verifies correctly.

A security regime that depends on the user doing this has no hope of  
success.

In fact, the basic defense that users have is that if things look  
funny, they may decide not to proceed.   It's an extremely thin line  
of defense, but it's all the average user has, because all of the  
checks you propose that the user make require technical knowledge that  
even an intelligent user who's not a practitioner in our field would  
not have.

So any attack that can make things not look funny is a valuable  
attack.   And the Kaminsky attack is such an attack.   You're right  
that it's not the only one, but eliminating it still has appreciable  
value.

n this way.

> that it verifies correctly.

A security regime that depends on the user doing this has no hope of  
success.

In fact, the basic defense that users have is that if things look  
funny, they may decide not to proceed.   It's an extremely thin line  
of defense, but it's all the average user has, because all of the  
checks you propose that the user make require technical knowledge that  
even an intelligent user who's not a practitioner in our field would  
not have.

So any attack that can make things not look funny is a valuable  
attack.   And the Kaminsky attack is such an attack.   You're right  
that it's not the only one, but eliminating it still has appreciable  
value.

---

From: "Ondřej Surý" <[email-masked]>
Date: Sun, 17 Aug 2008 09:47:18 +0200

2008/8/15 David Conrad <[email-masked]>:
>> But until we have root and .com signed, and until the average end-user is
>> protected by a validating resolver, we aren't done yet, and I don't really
>> get any actual benefit from my efforts.   Which, tragically, is why it's
>> taking so long.
>
> There are people who appear to think deploying DNSSEC as soon as possible
> would be a good thing.  There are also people who appear to think deploying
> DNSSEC is a fools errand, that it won't get significant use because it makes
> things too hard, too complicated, too prone to failure, etc.
>
> However, because of DO, folks who don't configure their resolvers to do
> DNSSEC shouldn't ever see any DNSSEC goop.
>
> Given this, does anyone see any DNS security and/or stability concerns if a
> miracle were to happen and the root were to be signed tomorrow?

"If you build it, he will come."

No, I don't see any problem.  Since enabling DNSSEC validation is controlled
process - ie. you need to change configuration - people will know what they
are doing.  Sure some people will get burnt once, twice, but then they will
learn or just disable DNSSEC validation at all.

But what we need to do is to properly educate users wishing to enable DNSSEC
validation.  But that doesn't differ from TLD signing and it's more task for
TLD registry to speak to it's users.

Ondrej.
-- 
 Ondřej Surý
 technický ředitel/Chief Technical Officer
 -----------------------------------------
 CZ.NIC, z.s.p.o. -- .cz domain registry
 Americká 23,120 00 Praha 2,Czech Republic
 mailto:[email-masked] http://nic.cz/
 sip:[email-masked] tel:+420.222745110
 mob:+420.739013699 fax:+420.222745112
 -----------------------------------------
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Ondřej Surý" <[email-masked]>
Date: Sun, 17 Aug 2008 09:47:18 +0200

Ondrej.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 17 Aug 2008 11:11:26 +0200

No, it won't. As David already pointed out, people not interested won't
set the DO bit so won't ask for DNSSEC. Also, a well behavng resolver
has way less request to the root servers then to other servers.

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 17 Aug 2008 11:11:26 +0200

jaap

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 19:40:29 +0900

Jaap Akkerhuis wrote:
     
> set the DO bit so won't ask for DNSSEC.

I'm talking about people who have, foolishly enough, interested in
DNSSEC and asked for DNSSEC information sometimes in vain.

And, the result is the instability.

> Also, a well behavng resolver

Why, do you think, that servers other than the root servers won't
reply with oversized messages?

						Masataka Ohta

PS

Thank you and David for being a example of people blindly requesting
for DNSSEC without understanding its so obvious negative effects, in
addition to not so obvious lack of its positive effects.

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 19:40:29 +0900

Masataka Ohta

PS

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 17 Aug 2008 16:59:26 +0200

Don't twist my words. I never said that.

	jaa

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 17 Aug 2008 16:59:26 +0200

jaa

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 12:24:29 -0400 (EDT)

> someone's listening on the other end who shouldn't be.

Anytime the browser takes a certificate that is not user-checkable as
being both secure and trusted, there will be problems.  

> attack.  And the Kaminsky attack is such an attack.  You're right that
> it's not the only one, but eliminating it still has appreciable value.

One can live with things that are untrustworthy, so long as you know
they are untrustworthy and takes the appropriate steps to avoid placing
trust decision on untrustworthy information. SSL/TLS certificate
procedures the appropriate steps to obtain secure and trusted
communication.

Changing DNS doesn't eliminate the attack of misplaced trust. It merely
eliminates one method we know of for accomplishing the attack, at great
expense and great risk, I might add. Addressing the misplaced trust
attack in the wrong place incorrectly signals to users/browsers that
they don't need to check the certificates for trustworthiness.

DNS spoofing isn't the only way to accomplish a misplaced trust attack.  
Cross site scripting and javascript viruses are another way.

Cryptographic verification just proves the CA issued the certificate.  
Checking that the verified identity is one we trust is what ensures
trustworthiness. The combination of both checks the only thing that
ensures trustworthiness. One can't eliminate either check and remain
trustworthy.  Every certificate that a browser uses for trustworthiness
has to be both verified cryptographically and checked by the user for
trust. Multi-site secure operations have to either have multiple
certificate checks, or depend on a private CA whose certificates are
always trusted.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 12:24:29 -0400 (EDT)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Aug 2008 09:36:11 -0700

On Aug 17, 2008, at 9:24 AM, Dean Anderson wrote:
> expense and great risk, I might add.

You may not add that unless you are willing to justify the assertion,  
which thus far you have not done.

> Cross site scripting and javascript viruses are another way.

That's true.   And if you argue that we shouldn't close the DNS hole,  
your argument applies equally to these problems.   Are you arguing  
that we shouldn't address them either?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Aug 2008 09:36:11 -0700

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 12:39:07 -0400 (EDT)

> Don't twist my words. I never said that.

That you didn't say that, I think is the point.  Other, non-root,
servers may respond with oversized messages. I agree with what Masataka
is saying.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 12:39:07 -0400 (EDT)

--Dean

---

From: David Conrad <[email-masked]>
Date: Sun, 17 Aug 2008 13:45:06 -0700

Masataka,

> DNSSEC and asked for DNSSEC information sometimes in vain.

If they have configured DNSSEC, then they either are aware of the  
operational issues that concern folks or will quickly learn of the  
issues.  If they are aware of the issues, then presumably they can  
help debug the infrastructure that is failing to provide them the  
information they are asking for.  If they are unaware of the issues,  
they can either learn and/or turn DNSSEC validation off at the first  
sign of problems.

> And, the result is the instability.

The result, if they are unhappy with the behavior DNSSEC causes, will  
be to turn off DNSSEC until the issues that made them unhappy are  
resolved (e.g., new caching server software that makes using DNSSEC  
less onerous).

According to your logic, no one should turn on IPv6 since it will  
obviously cause instability.  An interesting point of view.

> addition to not so obvious lack of its positive effects.

Yawn.  Thank you for living up (or perhaps more accurately, down) to  
my expectations.

Regards,
-drc

_______________________________________________
DNSOP mailing list
[email-masked]
httpFrom [email-masked]  Sun Aug 17 13:45:15 2008
From: David Conrad <[email-masked]>
To: Masataka Ohta <[email-masked]>
Date: Sun, 17 Aug 2008 13:45:06 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
	(fwd))
Sender: [email-masked]

Masataka,

> DNSSEC and asked for DNSSEC information sometimes in vain.

If they have configured DNSSEC, then they either are aware of the  
operational issues that concern folks or will quickly learn of the  
issues.  If they are aware of the issues, then presumably they can  
help debug the infrastructure that is failing to provide them the  
information they are asking for.  If they are unaware of the issues,  
they can either learn and/or turn DNSSEC validation off at the first  
sign of problems.

> And, the result is the instability.

The result, if they are unhappy with the behavior DNSSEC causes, will  
be to turn off DNSSEC until the issues that made them unhappy are  
resolved (e.g., new caching server software that makes using DNSSEC  
less onerous).

According to your logic, no one should turn on IPv6 since it will  
obviously cause instability.  An interesting point of view.

> addition to not so obvious lack of its positive effects.

Yawn.  Thank you for living up (or perhaps more accurately, down) to  
my expectations.

Regards,
-drc

_______________________________________________
DNSOP mailing list
[email-masked]
https:s://www.ietf.org/mailman/listinfo/dnsop

//www.ietf.org/mailman/listinfo/dnsop

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Aug 2008 08:33:54 +1000

> there should be instability observed.

	Define oversized?

	A referral to the COM servers already exceeds 512 octets.
	Lots of EDNS answers already result in fragmented responses.
	Lots of EDNS answers already exceed 2K.
	There are a few EDNS answers which even set TC.

	I fail to see how turning on DNSSEC at the root will change
	anything significant with respect to responses sizes which
	is not already highly visible elsewhere in the DNS.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Aug 2008 08:33:54 +1000

Define oversized?

	Mark

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 19:12:54 -0400 (EDT)

On Sun, 17 Aug 2008, Ted Lemon wrote:

> > Changing DNS doesn't eliminate the attack of misplaced trust. It
> > merely eliminates one method we know of for accomplishing the
> > attack, at great expense and great risk, I might add.
> 

Changing DNS protocol is considered by many to be expensive and risky.  
Are you saying its not expensive or risky?  That seems to be a far more
bold assertion.

> And if you argue that we shouldn't close the DNS hole, your argument
> applies equally to these problems.  Are you arguing that we shouldn't
> address them either?

It may well impossible to close the problems of cross site scripting and
javascript viruses.

However, misplaced trust attacks can only be avoided by preventing the
sending of trusted information to untrusted sites.  Solve this problem
correctly (which is entirely doable) and none of these attacks will be
effective at obtaining trusted information.  Changing DNS protocol is
not necessary to prevent misplaced trust attacks.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 19:12:54 -0400 (EDT)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Aug 2008 16:43:26 -0700

> Are you saying its not expensive or risky?  That seems to be a far  

Actually, you and Ohta-san seem to be taking that position.   That's  
not "many."   I just deployed DNSSEC.   My servers are ticking over  
happily, and I haven't had any complaints from users.   So I guess I  
don't think it's all that risky, no.  It may be that I'm wrong, but  
you haven't said anything surprising yet, so I'm still waiting for the  
revelation that will convince me that your fears are justified.

> effective at obtaining trusted information.

Forgive me for pointing this out, but about three exchanges ago you  
said that solving this problem was provably impossible. From [email-masked]  Sun Aug 17 16:43:25 2008
From: Ted Lemon <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 16:43:26 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
	(fwd))
Sender: [email-masked]

> Are you saying its not expensive or risky?  That seems to be a far  

Actually, you and Ohta-san seem to be taking that position.   That's  
not "many."   I just deployed DNSSEC.   My servers are ticking over  
happily, and I haven't had any complaints from users.   So I guess I  
don't think it's all that risky, no.  It may be that I'm wrong, but  
you haven't said anything surprising yet, so I'm still waiting for the  
revelation that will convince me that your fears are justified.

> effective at obtaining trusted information.

Forgive me for pointing this out, but about three exchanges ago you  
said that solving this problem was provably impossible  Have you  
changed your mind, or am I missing something?

.   Have you  
changed your mind, or am I missing something?

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 19:43:47 -0400 (EDT)

> security concerns to those folks who _haven't_ configured DNSSEC if  

There are two more problems with this. 

First, Putting any kind of large record in the root creates the
opportunity to use root servers in a DOS attack by sending queries for
the large records to the root servers. Because of Root Anycasting, there
are over 100+ root servers spread around the world that will respond to
queries. A botnet distributed worldwide should be able to send queries
to most or all of these servers.  Most or many of these servers have
very high bandwidth connections. Same would be true for TLD servers, and
large, high traffic domains like microsoft.com, etc. It is very hard, if
not impossible, to mitigate attacks coming from root, TLD or other
significant sites.

Second, as I start to look closer at DNSSEC, there appears to be a
problem in the DNSSEC protocol in that if caching servers don't care
about DNSSEC, then caches could store RRSIG records that are out of sync
with the RR they sign.  When the security-aware resolver obtains both
records from the caching server, the resolver that finally checks one
record against the other will find that the signature doesn't match.
This scenario could happen by accident during zone updates between
master and slaves after the RR was changed, if the cache gets one RR
from the master and receives the RRSIG from another server (one might
try to avoid this by adding RRSIG records as additional, but there is
still a race on the internal representation if multiple responses are
received from different servers).  Or it could happen on purpose using a
cache poisoning attack.  Once the incorrect records are cached, a DOS
occurs. (its only an attack if its on purpose)

If the caching server checks the signature of all records, its
susceptible to a DOS attack by lots of DNSSEC queries that take a lot of
computation to check.  Seems to be no-win.

The first problem is reason enough not to deploy DNSSEC. The second
problem is serious, too, but I think only affects DNSSEC users who have
shot themselves, other DNSSEC users, and those using DNSSEC-aware
caching servers in the foot, so to speak. Back to the drawing board?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 19:43:47 -0400 (EDT)

--Dean

---

From: Jim Reid <[email-masked]>
Date: Mon, 18 Aug 2008 01:23:15 +0100

On 18 Aug 2008, at 00:43, Dean Anderson wrote:

> the large records to the root servers.

Well in that case we better not put anything into any DNS zone.  
Because a botnet that's in a net that doesn't do proper egress  
filtering could use spoofed source addresses to generate lots of DNS  
responses from any decent authoritative server infrastructure for a  
(D)DoS attack. The actual size of the DNS responses doesn't matter.  
What's the difference between 50 million DNS responses of 1 Kb each  
and 500 million of 100 bytes? In other words, if the botnet's not big  
enough to do the necessary damage, just get a bigger one.

> with the RR they sign.

This makes no sense. If caching servers don't care about DNSSEC, why  
would they be storing RRSIGs? Please explain. And why would these  
caching servers be signing anything? It's the master server that signs  
the zone.

I suspect you're talking about the absurdly hypothetical scenario  
where someone gets a non DNSSEC-aware resolving server to lookup some  
RRSIG, then the zone is resigned, then they ask that server for the  
QTYPE that the already cached RRSIG once signed. If that's the  
situation you've dreamt up, so what? Have you read and actually  
understood RFC3225? Nobody's going to get that cached RRSIG unless  
they query the caching server with the DO bit set. Which the server  
will ignore because it doesn't care about DNSSEC. So it won't send a  
response containing the cached RRSIG. Now if that resolving server  
does pay attention to the DO bit, it will set it on the query it makes  
to the authoritative server. That makes the authoritative server  
return an answer which will contain the new RRSIG and the resolving  
server's cache is updated accordingly.

Even if you're talking about some other scenario, your concern is  
still unjustified. Whatever contrivance you've invented will be no  
different from the case where a resolving server queries a slave that  
hasn't yet picked up the latest version of the zone from the master  
server. Which can happen irrespective of whether DNSSEC is used or  
not. The DNS is a loosely coherent distributed database after all.

---

From: Jim Reid <[email-masked]>
Date: Mon, 18 Aug 2008 01:23:15 +0100

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2008 20:19:07 -0400 (EDT)

> not impossible, to mitigate attacks coming from root, TLD or other

If it is TCP, due to large DNSSEC answers, you won't easilly be able
to use these for amplifying your DOS attack. If the answer would fit
in UDP, you wouldnt really have an issue.

> Second, as I start to look closer at DNSSEC

It keeps amusing me how people who have critisied DNSSEC for years,
end up asking me things like "so how does it work?" or in your case
"I actually looked at it now".

> , there appears to be a

This is not the case, but if so, why would you bootstrap a DNSSEC enabled
server using a non-DNSSEC forwarder?

> from the master and receives the RRSIG from another server (one might

Don't you get the RRSIG as Authoritive or Additional data when getting
the new RR?

> occurs. (its only an attack if its on purpose)

You lost me here.

> computation to check.  Seems to be no-win.

That's not a DOS attack. That's the price of cryptogrpahically signing
the DNS.

> caching servers in the foot, so to speak. Back to the drawing board?

Because root servers could potentialy amplify a single spoofed packet
into more (which I described is not as bad as you make it appear), that
would be a reason not to deploy secure DNS? This is an answer looking
for a reasoning.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2008 20:19:07 -0400 (EDT)

You lost me here.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2008 20:30:57 -0400 (EDT)

On Sat, 16 Aug 2008, Ted Lemon wrote:

> This isn't true, because if I can convince you that a naive user that he or 
> she is talking to your bank, I can get them to enter their information into a 
> web page that isn't protected by SSL.
>
> Alternatively, I can find a server that has a valid SSL cert, crack it, set

Even easier, just grab the ones that were created on Debian.

Funny how DNSSEC-phobic people keep referring to SSL as the solution. Reread
Dan's slides to see how to combine the DNS and the Debian SSL issue into a
mega attack.

> resolvers in the DNS caching servers, then there will be an opportunity for 
> DoS attacks, and so deployments of that type will have to be done very 
> carefully.

At least you won't be receiving endless streams of DNS packets trying to
race your DNS resolver using NXDOMAIN records using Dan's attack. I'd rather
have some extra CPU load to mitigate the bandwidth losses.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Sun, 17 Aug 2008 20:30:57 -0400 (EDT)

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Aug 2008 10:37:07 +0900

Jim Reid wrote:

> I suspect you're talking about the absurdly hypothetical scenario  where 
> someone gets a non DNSSEC-aware resolving server to lookup some  RRSIG, 

Suppose you are using DNSSEC-unaware caching forwarder shared by
others including those who are using PODS, which is often the case
when you are behind NAT.

RFC3225 does admit such a case as:

   non-compliant caching or forwarding servers inappropriately copy data
   from classic headers as queries are passed on to authoritative
   servers, the use of a bit from the EDNS0 header is proposed.

You ask a query on some name, maybe with DO bit set, and receive
an answer without any SIG RRs.

You now ask SIG RRs of the name through TCP (SIG RRs is usually
larger than 1500B and can easily be larger than 64KB) and the SIG
RRs will be cached, if everything works fine.

There are a lot of possibilities that you can't get any SIG RRs,
though. For example, the caching forwarder may not support TCP or
may not be able to accept large answers.

And, you must turn DNSSEC off, which is the instability I already
mentioned.

If you are little more unlucky, server's cache may overflow,
inappropriate code against which may crash the server, which
may never occured before with small PODS answers.

It should also be noted that, in RFC3225, SIG RR query through TCP,
which is unavoidable in this case, is considered harmful asFrom [email-masked]  Sun Aug 17 18:43:51 2008
Date: Mon, 18 Aug 2008 10:37:07 +0900
From: Masataka Ohta <[email-masked]>
To: Jim Reid <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
Sender: [email-masked]

Jim Reid wrote:

> I suspect you're talking about the absurdly hypothetical scenario  where 
> someone gets a non DNSSEC-aware resolving server to lookup some  RRSIG, 

Suppose you are using DNSSEC-unaware caching forwarder shared by
others including those who are using PODS, which is often the case
when you are behind NAT.

RFC3225 does admit such a case as:

   non-compliant caching or forwarding servers inappropriately copy data
   from classic headers as queries are passed on to authoritative
   servers, the use of a bit from the EDNS0 header is proposed.

You ask a query on some name, maybe with DO bit set, and receive
an answer without any SIG RRs.

You now ask SIG RRs of the name through TCP (SIG RRs is usually
larger than 1500B and can easily be larger than 64KB) and the SIG
RRs will be cached, if everything works fine.

There are a lot of possibilities that you can't get any SIG RRs,
though. For example, the caching forwarder may not support TCP or
may not be able to accept large answers.

And, you must turn DNSSEC off, which is the instability I already
mentioned.

If you are little more unlucky, server's cache may overflow,
inappropriate code against which may crash the server, which
may never occured before with small PODS answers.

It should also be noted that, in RFC3225, SIG RR query through TCP,
which is unavoidable in this case, is considered harmful :

   TCP DNS queries result in significant overhead due to connection
   setup and teardown.  Operationally, the impact of these TCP queries
   will likely be quite detrimental in terms of increased network
   traffic (typically five packets for a single query/response instead
   of two), increased latency resulting from the additional round trip
   times, increased incidences of queries failing due to timeouts, and
   significantly increased load on nameservers.

						Masataka Ohta

PS

I'm very happy now because my proposal of "Simple Secure DNS", which
was designed to carefully avoid using large messages, is not deployed.

as:

   TCP DNS queries result in significant overhead due to connection
   setup and teardown.  Operationally, the impact of these TCP queries
   will likely be quite detrimental in terms of increased network
   traffic (typically five packets for a single query/response instead
   of two), increased latency resulting from the additional round trip
   times, increased incidences of queries failing due to timeouts, and
   significantly increased load on nameservers.

						Masataka Ohta

PS

I'm very happy now because my proposal of "Simple Secure DNS", which
was designed to carefully avoid using large messages, is not deployed.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Aug 2008 12:11:54 +1000

> RRs will be cached, if everything works fine.

	Sorry we are talking about RFC 4035 not RFC 2535.

	RFC 2535 was designed to work through a non-RFC 2535 aware
	cache.

	RFC 4035 requires the upstream cache to be RFC 4035 aware.

	RFC 4035 compliant validators DO NOT request RRSIGs if they
	are missing from the response.  Instead the response is
	rejected if it is deemed the response should have included
	them.

	The type code roll prevents RFC 2535 aware caches impacting
	on the operation of RFC 4035 validators.

> may not be able to accept large answers.

	And lack of TCP support will also break PODS responses as well.
	Authoritative servers can sometimes get away with disabling TCP.
	Stub and caches have never been able to get away with disabling
	TCP.
 
> which is unavoidable in this case, is considered harmful as:
>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Aug 2008 12:11:54 +1000

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 17 Aug 2008 22:17:33 -0400

On Sun, Aug 17, 2008 at 8:23 PM, Jim Reid <[email-masked]> wrote:

> someone gets a non DNSSEC-aware resolving server to lookup some RRSIG, then
> the zone is resigned, then they ask that server for the QTYPE that the
> already cached RRSIG once signed.

Not that hypothetical.  Its just another attack vector.  And one that would
work well against non signed zones.  A non DNSSEC resolver could be used to
poison DNSSEC aware resolvers.

In any case - DNSSEC is a dead issue.  The problem here is UDP.  We have to
move to a more reliable transport.  TCP with UDP fallback?  Thats easy to do
and will still take years to deploy.  The network is slow when it comes to
upgrading.

Just imagine the impact DNSSEC will have.  Not very much.  The large
corporations who swallow the commercial BIND fud will be first to deploy.
But most of the world won't bother and once the world discovers DNSSEC give
root control over to ICANN the net result will be a black eye for ICANN.

Poor little ICANN can't afford more scrutiny.  Their market share in root
services has gone from 100% to 70%.  Thats not impressive.  If it were not
for my putting an end to the European HEX that amount today would be more
like 40%.  Back then the HEX accounted for a 5% drop in ICANN's market share
of root services.

later
joe baptista

-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
Office: +1 (360) 526-6077 (extension 052)
Fax: +1 (509) 479-0084
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 17 Aug 2008 22:17:33 -0400

later
joe baptista

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 17 Aug 2008 22:32:55 -0400

On Fri, Aug 15, 2008 at 4:51 PM, Paul Hoffman <[email-masked]> wrote:

> security layers are good. If we don't give those people the right tools to
> properly configure and properly maintain those configurations, there will be
> stability issues, as I listed earlier.

Let me tell you something.  All this DNSSEC fud has been very very good for
DNS consultants.  One thing I make clear to the client base is that DNSSEC
is just more bad patching on top of more bad patching.  The BIND boys are
patching freaks and have yet to build a BIND version that is stable.

My advise to them is to watch the developments in DNSSEC and not believe
everything they read.  The solution I like implementing instead of DNSSEC is
an IPS monitoring the resolver.  And of course making sure their resolvers
don't act as authoritative primaries or secondaries.

One things for sure - many businesses are going to end up paying big bucks
to protect themselves and even bigger bucks to deploy the DNSSEC patch.  The
BIND boys are marketing gurus.

cheers
joe baptista

---

From: "Joe Baptista" <[email-masked]>
Date: Sun, 17 Aug 2008 22:32:55 -0400

cheers
joe baptista

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 23:03:41 -0400 (EDT)

> revelation that will convince me that your fears are justified.

I'm always amazed when advocates of something come out and say "I did
it, and I'm still here", and assume that means that it can be done
worldwide for free and that it also means there are no issues with
scaling their effort, and that it means there are no downsides that
might come to light after a lot of sites do what they did. SPF script
DOS attacks come to mind as a good example.

But if only myself and Ohta-san think changing DNS protocol is expensive 
and risky, then perhaps we should change the protocol even more and do 
it more often.

> said tFrom [email-masked]  Sun Aug 17 20:03:48 2008
Date: Sun, 17 Aug 2008 23:03:41 -0400 (EDT)

> revelation that will convince me that your fears are justified.

I'm always amazed when advocates of something come out and say "I did
it, and I'm still here", and assume that means that it can be done
worldwide for free and that it also means there are no issues with
scaling their effort, and that it means there are no downsides that
might come to light after a lot of sites do what they did. SPF script
DOS attacks come to mind as a good example.

But if only myself and Ohta-san think changing DNS protocol is expensive 
and risky, then perhaps we should change the protocol even more and do 
it more often.

> said that solving this problem was provably impossible.   Have you  

You are indeed missing something.  Constructing a system free of covert
channels is not the same as limiting the distribution of trusted
information.  To put it another way, its fairly easy to limit the "To:"  
list on sending email, but its much harder to keep spam out of your
mailbox.  One problem is doable. The other isn't.

		--Dean

hat solving this problem was provably impossible.   Have you  
> changed your mind, or am I missing something?

You are indeed missing something.  Constructing a system free of covert
channels is not the same as limiting the distribution of trusted
information.  To put it another way, its fairly easy to limit the "To:"  
list on sending email, but its much harder to keep spam out of your
mailbox.  One problem is doable. The other isn't.

		--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Aug 2008 12:16:27 +0900

> 	RFC 4035 requires the upstream cache to be RFC 4035 aware.

Thanks. As examplified by assumptions of RFC3225, that's a so
unrealistic requirement that no further discussion on DNSSEC
is necessary. PERIOD.

>	Stub and caches have never been able to get away with disabling
 
In theory, yes, in practice, only those who supply large RRs
requiring TCP (or EDNS) will suffer.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Aug 2008 12:16:27 +0900

Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Aug 2008 13:36:07 +1000

> unrealistic requirement that no further discussion on DNSSEC

	Given just about anyone can configure a validator to talk
	directly to authoritative servers or can configure it to
	talk to a cache which *is* DNSSEC aware which in turn talks
	to the authoritative servers directly, I'm not worried about
	those that *choose* to use a forwarder which is not DNSSEC
	aware.

	In other words just about anyone that wants to use DNSSEC
	can put themselves in a position to use DNSSEC.  The tools
	are available to do it.

	We know there is unlikely to ever be universal deployment
	of DNSSEC.  The fact that it is not universal however should
	not be seen as a reason not to deploy it where it can be
	deployed.

> requiring TCP (or EDNS) will suffer.

	Well we are there now.  Lots of answers require EDNS and/or
	TCP and the DNS resolution has not fallen over.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 18 Aug 2008 13:36:07 +1000

---

From: Dean Anderson <[email-masked]>
Date: Sun, 17 Aug 2008 23:42:39 -0400 (EDT)

> in UDP, you wouldnt really have an issue.

I'm not sure you understand EDNSO. EDNSO UDP can be 8KB in size.

TCP isn't susceptible to this kind of attack at all. TCP spoofing is
just about impossible if you aren't in the path, because there is a
32bit random sequence ID. If you don't get that sequence id, you won't
get the connection established, and the target won't get the DNS
response.  A botnet spread worldwide mostly won't be in the path.

> It keeps amusing me howFrom [email-masked]  Sun Aug 17 20:42:41 2008
Date: Sun, 17 Aug 2008 23:42:39 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Paul Wouters <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>, David Conrad <[email-masked]>,
	Paul Hoffman <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
 (fwd))
Sender: [email-masked]

> in UDP, you wouldnt really have an issue.

I'm not sure you understand EDNSO. EDNSO UDP can be 8KB in size.

TCP isn't susceptible to this kind of attack at all. TCP spoofing is
just about impossible if you aren't in the path, because there is a
32bit random sequence ID. If you don't get that sequence id, you won't
get the connection established, and the target won't get the DNS
response.  A botnet spread worldwide mostly won't be in the path.

> "I actually looked at it now".

This seems strange only if you don't know the history of DNSSEC.  
Because they keep messing up in major ways, and keep starting over on
the protocol, what I looked at years ago has no bearing on DNSSEC now.  
And I thought it was a dumb idea years ago, too.

> > , there appears to be a problem in the DNSSEC protocol in that if
> > caching servers don't care about DNSSEC, then caches could store
> > RRSIG records that are out of sync with the RR they sign.  When the
> > security-aware resolver obtains both records from the caching
> > server, the resolver that finally checks one record against the
> > other will find that the signature doesn't match.
> 
> This is not the case, but if so, why would you bootstrap a DNSSEC
> enabled server using a non-DNSSEC forwarder?

You haven't been following along with the discussion.  There may be
DNSSEC-aware authority zones and DNSSEC-aware stub resolvers that might
use DNSSEC-oblivious intermediate caches.  For example, suppose
example.com signs its zone, and you install a DNSSEC-aware resolver on
your laptop.  Now suppose you go to starbucks, which didn't do DNSSEC
and has a DNSSEC-oblivious caching server. Next you try to access
example.com using the starbucks caching server.  The DNSSEC-oblivious
cache will just cache the records as ordinary (very large) records. 

> Don't you get the RRSIG as Authoritive or Additional data when getting

I'm not entirely sure it works that way. I didn't see that specified.  
But it certainly could work that way, as I said below.

> > received from different servers).  

When the internal representation is updated, it is often done one RR at
a time. So two responses updating the same two records could be
interleaved.  This is a simple database problem called a race condition.
Transaction isolation and locking is used to protect against this.  DNS
servers usually aren't designed to support transactions on the update of
multiple records in one response.  

> > Or it could happen on purpose using a cache poisoning attack.  Once
> > the incorrect records are cached, a DOS occurs. (its only an attack
> > if its on purpose)
> 
> You lost me here.

Sorry.  When the RR isn't the same as the one for which the RRSIG was
computed, the DNSSEC-aware stub resolver will reject the record. If it
asks the caching server again, it gets the same records. So the resolver
will fail, and will continue to fail until the TTL expires.  The bad guy 
just creates two records with long TTL, and you have the DOS attack. 

> That's not a DOS attack. That's the price of cryptogrpahically signing

When your server can't handle the load of all these calculations on
millions of queries sent by the attacker, its a DOS attack.

> would be a reason not to deploy secure DNS? This is an answer looking

I don't think you quite understand DOS attack mitigation. 

Now imagine the target spoofed IP's are the nameservers of, say
yourdomain.com.  When the roots (or TLDs, etc) get millions of forged
UDP packets, the roots can't block the incoming packets---that would
severely harm the target IP addresses. On the other end, the target IP
addresses can't block the root servers---that would also seriously harm
the target IP addresses. The target just has to 'take it'.

The greater the amplification factor (Response size / request size--
perhaps only 64 bytes), the more damaging this attack is.  Since there
are (or may be--probably will be)  a number of additional (and large)
DNSSEC records in a response, the response could get quite large,
causing significant damage. So yes, that is a reason not to deploy
DNSSEC.

		--Dean

 people who have critisied DNSSEC for years,
> "I actually looked at it now".

This seems strange only if you don't know the history of DNSSEC.  
Because they keep messing up in major ways, and keep starting over on
the protocol, what I looked at years ago has no bearing on DNSSEC now.  
And I thought it was a dumb idea years ago, too.

> > , there appears to be a problem in the DNSSEC protocol in that if
> > caching servers don't care about DNSSEC, then caches could store
> > RRSIG records that are out of sync with the RR they sign.  When the
> > security-aware resolver obtains both records from the caching
> > server, the resolver that finally checks one record against the
> > other will find that the signature doesn't match.
> 
> This is not the case, but if so, why would you bootstrap a DNSSEC
> enabled server using a non-DNSSEC forwarder?

You haven't been following along with the discussion.  There may be
DNSSEC-aware authority zones and DNSSEC-aware stub resolvers that might
use DNSSEC-oblivious intermediate caches.  For example, suppose
example.com signs its zone, and you install a DNSSEC-aware resolver on
your laptop.  Now suppose you go to starbucks, which didn't do DNSSEC
and has a DNSSEC-oblivious caching server. Next you try to access
example.com using the starbucks caching server.  The DNSSEC-oblivious
cache will just cache the records as ordinary (very large) records. 

> Don't you get the RRSIG as Authoritive or Additional data when getting

I'm not entirely sure it works that way. I didn't see that specified.  
But it certainly could work that way, as I said below.

> > received from different servers).  

When the internal representation is updated, it is often done one RR at
a time. So two responses updating the same two records could be
interleaved.  This is a simple database problem called a race condition.
Transaction isolation and locking is used to protect against this.  DNS
servers usually aren't designed to support transactions on the update of
multiple records in one response.  

> > Or it could happen on purpose using a cache poisoning attack.  Once
> > the incorrect records are cached, a DOS occurs. (its only an attack
> > if its on purpose)
> 
> You lost me here.

Sorry.  When the RR isn't the same as the one for which the RRSIG was
computed, the DNSSEC-aware stub resolver will reject the record. If it
asks the caching server again, it gets the same records. So the resolver
will fail, and will continue to fail until the TTL expires.  The bad guy 
just creates two records with long TTL, and you have the DOS attack. 

> That's not a DOS attack. That's the price of cryptogrpahically signing

When your server can't handle the load of all these calculations on
millions of queries sent by the attacker, its a DOS attack.

> would be a reason not to deploy secure DNS? This is an answer looking

I don't think you quite understand DOS attack mitigation. 

Now imagine the target spoofed IP's are the nameservers of, say
yourdomain.com.  When the roots (or TLDs, etc) get millions of forged
UDP packets, the roots can't block the incoming packets---that would
severely harm the target IP addresses. On the other end, the target IP
addresses can't block the root servers---that would also seriously harm
the target IP addresses. The target just has to 'take it'.

The greater the amplification factor (Response size / request size--
perhaps only 64 bytes), the more damaging this attack is.  Since there
are (or may be--probably will be)  a number of additional (and large)
DNSSEC records in a response, the response could get quite large,
causing significant damage. So yes, that is a reason not to deploy
DNSSEC.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 00:11:36 -0400 (EDT)

On Mon, 18 Aug 2008, Jim Reid wrote:

> And why would these caching servers be signing anything? It's the
> master server that signs the zone.

I never said otherwise.

Ok, I agree that totally DNSSEC-oblivious servers won't be a problem for
DOS, but of course remain susceptible to poisoning even if the stub 
resolver and the authority server both implement DNSSEC.

> Now if that resolving server does pay attention to the DO bit, it will
> set it on the query it makes to the authoritative server. That makes
> the authoritative server return an answer which will contain the new
> RRSIG and the resolving server's cache is updated accordingly.

Ok. So what about caching servers that do understand the DO bit but
don't actually verify the responses? They just cache the response for
the stub resolver to verify?  These servers can still be poisoned with
invalid record combinations that they pass on to stub resolvers,
resulting in the DOS.  Such servers may still be subject to the race
condition I described.

And the caching servers that do verify, are susceptible to the DOS 
attack I described.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 00:11:36 -0400 (EDT)

I never said otherwise.

		--Dean

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 00:03:46 -0400 (EDT)

> your laptop.  Now suppose you go to starbucks, which didn't do DNSSEC

I wouldn't be using starbucks resolver, since i just installed my
own DNSSEC-aware resolver?

> interleaved.  This is a simple database problem called a race condition.

However, we have TTL's and signature life times, so older entries will only
get updated with newer entries, so this "race" is not a problem.

> just creates two records with long TTL, and you have the DOS attack.

Mark and Roy already explained why this is not the case.

> millions of queries sent by the attacker, its a DOS attack.

So is not getting any traffic because you lost .com due to cache poisoning.

In fact, what I understood is that resolvers mostly have problems switching
to DNSSEC not due to DNSSEC but due to DNSSEC requiring EDNS0. And mind you,
the EDNS0 was released in what? 1999?

It's not the crypto that's the resolvers issue. That's easilly solved by
adding a cpu or a box.

> causing significant damage. So yes, that is a reason not to deploy

This has also been explained earlier. Just get a botnet that's 100x
the size to accomplish the same. This argument amounts to something
like "let's not do HDTV because the home user DSL might not be able
to download it in real time anyway".

But all these discussions have happened for 10 years. The result is
DNSSEC.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 00:03:46 -0400 (EDT)

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Aug 2008 13:34:02 +0900

> 	TCP and the DNS resolution has not fallen over. 

OK. So, those who supply large RRs requiring TCP (or EDNS) are
suffering, now.

If they are clever enough, they will learn to put their data
somewhere else.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 18 Aug 2008 13:34:02 +0900

Masataka Ohta

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 08:59:56 +0200

> TCP isn't susceptible to this kind of attack at all. TCP spoofing is

While this is true, it turns out the current crop of authoritative
nameservers, including mine, is not up to serving thousands of
requests/second over TCP. Or at least not thousands of new sessions/second.

I'm working on in-place spoofing countermeasures and I've already had to
stop my tests because I ended up overloading the authentic authoritative
servers with TCP queries.

So TCP is not the end-all to our worries. Nor is DNSSEC however - the
current crop of auth servers doesn't have that enabled or working either.

	Bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 08:59:56 +0200

Bert

---

From: Jim Reid <[email-masked]>
Date: Mon, 18 Aug 2008 13:27:10 +0100

> resolver and the authority server both implement DNSSEC.

Kindly explain how is this any different from when poisoning occurs  
when stub resolver and authority server don't implement DNSSEC.

The fact is DNSSEC is the *only* game in town for preventing cache  
poisoning. So to go back to David's original question: will deploying  
DNSSEC break anything that's already in use that doesn't support DNSSEC?

> resulting in the DOS.  Such servers may still be subject to the race

How is this different from a resolving server not getting the correct  
answer because it queried an authoritative server that hasn't seen the  
latest version of the zone on the master? In fact in the somewhat  
contrived scenario you pose, the stub resolver gets a validation  
failure. So they at least know something has gone wrong. WhicFrom [email-masked]  Mon Aug 18 05:27:49 2008
From: Jim Reid <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:27:10 +0100
Cc: [email-masked]
Subject: Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
Sender: [email-masked]

> resolver and the authority server both implement DNSSEC.

Kindly explain how is this any different from when poisoning occurs  
when stub resolver and authority server don't implement DNSSEC.

The fact is DNSSEC is the *only* game in town for preventing cache  
poisoning. So to go back to David's original question: will deploying  
DNSSEC break anything that's already in use that doesn't support DNSSEC?

> resulting in the DOS.  Such servers may still be subject to the race

How is this different from a resolving server not getting the correct  
answer because it queried an authoritative server that hasn't seen the  
latest version of the zone on the master? In fact in the somewhat  
contrived scenario you pose, the stub resolver gets a validation  
failure. So they at least know something has gone wrong. Whh has to  
be a great leap forward from getting bad (poisoned) data and not  
having the slightest clue that has happened.

Ahhh. I see it now. Someone will deploy DNSSEC in their stub resolver.  
But then they'll make that query a resolving server that doesn't speak  
DNSSEC whenever their stub resolver wants to do a DNSSEC-aware lookup.  
Right. Makes perfect sense. [Add scarcasm to taste.]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

ich has to  
be a great leap forward from getting bad (poisoned) data and not  
having the slightest clue that has happened.

Ahhh. I see it now. Someone will deploy DNSSEC in their stub resolver.  
But then they'll make that query a resolving server that doesn't speak  
DNSSEC whenever their stub resolver wants to do a DNSSEC-aware lookup.  
Right. Makes perfect sense. [Add scarcasm to taste.]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Aug 2008 09:29:06 -0400

On Fri, Aug 15, 2008 at 04:07:03PM -0700, David Conrad wrote:

> intervention) or they'll turn off DNSSEC.  So, in the worst case, they'll 
> get bitten and revert back to the same level of security (or lack thereof) 
> they have today.
>

It seems to me that that story is the one by which DNSSEC becomes
permanently hobbled on the Interned, as various overworked or
semi-incompetent system administrators make a mistake of this sort and
cause sites to go dark for significant portions of the Internet.  When
the CTO receives the incident report, the CTO is going to say, "So if
we never turned on DNSSEC, this wouldn't have happened?  Ok.  New
policy: no DNSSEC."

At least, that's the way it would have worked in most large
institutions I ever worked in/around.

A

-- From [email-masked]  Mon Aug 18 06:29:05 2008
Date: Mon, 18 Aug 2008 09:29:06 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns
	bugs	(fwd))
Sender: [email-masked]

On Fri, Aug 15, 2008 at 04:07:03PM -0700, David Conrad wrote:

> intervention) or they'll turn off DNSSEC.  So, in the worst case, they'll 
> get bitten and revert back to the same level of security (or lack thereof) 
> they have today.
>

It seems to me that that story is the one by which DNSSEC becomes
permanently hobbled on the Interned, as various overworked or
semi-incompetent system administrators make a mistake of this sort and
cause sites to go dark for significant portions of the Internet.  When
the CTO receives the incident report, the CTO is going to say, "So if
we never turned on DNSSEC, this wouldn't have happened?  Ok.  New
policy: no DNSSEC."

At least, that's the way it would have worked in most large
institutions I ever worked in/around.

A

-
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104

- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104

---

From: Peter Koch <[email-masked]>
Date: Mon, 18 Aug 2008 16:46:26 +0200

> do DNSSEC shouldn't ever see any DNSSEC goop.

so, one question is whether the "DO" bit actually signals understanding of
the correct version of DNSSEC and what that means for responses with RRSIGs
absent any trust anchor at the resolver.  Just as a random data point,
DE servers "see" 20-35% of the queries carry the DO bit.

> DNSSEC-signing)?  If so, why?

Not flagging confirmed issues, but trying to focus on what _could_ be
problematic, based on perceived change:

For non-DO sending resolvers, only responses to ANY queries for the "." itself
as well as all TLDs should grow.  There is no good reason to ask
for ANY in the first place, but we have seen reports mentioning problems
with size issues and ANY before.  Priming should not be affected since it is
supposed to work by QTYPE NS only.

All TLDs will have an NSEC RR as well as an RRSIG (assuming the root won't
be signed using NSEC3), the signed TLDs will have an additional DS RR and
its RRSIG RR.  Also, at least the DS/RRSIG pair is now authoritative in
the parent, so an ANY query for, say, a signed SE to the root name servers
will result in data in the answer section.  However, this behaviour isn't
new because old software didn't really always send true referrals, but used
the delegation NS RRs to fill the answer section.

Of course, one might claim that anybody using ANY in any production system
(pun intended) gets what they deserve.

These effects should be visible now, but since we can't judge what query
load the signed zones face today and whether the resolver population is
representative in any way, it's hard to tell that issues would already have
hit the surface.   Apart from the priming all of the above would equally
apply to TLDs, SLDs or otehr levels of the hierarchy.

-Peter (hatless)

---

From: Peter Koch <[email-masked]>
Date: Mon, 18 Aug 2008 16:46:26 +0200

-Peter (hatless)

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Aug 2008 09:02:20 -0700

At 1:27 PM +0100 8/18/08, Jim Reid wrote:
>The fact is DNSSEC is the *only* game in town for preventing cache poisoning.

Note the subject of this particular thread. A more carefully-worded 
sentence would be "The fact is DNSSEC is the *only* game in town for 
completely preventing cache poisoning." We have methods to reduce an 
attacker's ability to poison caches effectively.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Aug 2008 09:02:20 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Aug 2008 09:05:37 -0700

>(pun intended) gets what they deserve.

Fully agree. Maybe a BCP document titled "Asking for ANY Considered 
Unwise" would be useful.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 18 Aug 2008 09:05:37 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 16:34:30 +0000

> Fully agree. Maybe a BCP document titled "Asking for ANY Considered 

better still, let's deprecate these bit patterns altogether for OP=QUERY:

	QTYPE=255

	QCLASS=255

	RA=1 AND RD=0

and let's also make explicit that TCP is not to be used unless UDP returns
TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA.

none of these serve any nondiagnostic purpose, and they are all dangerous
to the stability of responders.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 16:34:30 +0000

QTYPE=255

	QCLASS=255

	RA=1 AND RD=0

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 19:15:46 +0200

> TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA.

This means disabling one of the more widely used MTAs. TCP is a first class
DNS citizen, and it has its uses.

> to the stability of responders.

It may require some work to beef up TCP support though, which is currently
by far not as well stressed as UDP support.

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 19:15:46 +0200

Bert

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:35:51 -0400 (EDT)

> own DNSSEC-aware resolver?

Ordinarilly , when you get a DHCP-supplied nameserver from starbucks,
your stub resolver directs its requests to that caching server.  It is
indeed possible that your stub resolver could make its own queries,
including to the root and TLD servers, but putting this non-cached
end-user load on those servers is yet another unanticpated operational
problem.  No one has accounted for such increased load for DNSSEC.

> get updated with newer entries, so this "race" is not a problem.

I don't think you understand the programming issues.  This has nothing
to do with TTLs or signature lifetimes.  The point is that DNS servers
don't currently perform transactions internally; normally, records don't
depend tightly on other records (hence the term 'loosely coherent').  
BTW, adding transaction capability greatly slows down database servers.
This is probably one of the reasons people like to put stuff in DNS
instead of databases.  DNS is fast because of its stateless nature.
DNSSEC changes that, and imposes speed-reducing demands on server
architecture.  Or else, won't work right.  This change alters DNS from 
being loosely coherent to tightly coherent, with corresponding 
performance impacts to get correct operation.

> Mark and Roy already explained why this is not the case.

Who do you mean by 'Mark and Roy'? Mark Andrews and Roy Arends? When?

> >>> susceptible to a DOS attack by lots of DNSSEC queries that take a
> >>> lot of computation to check.  Seems to be no-win.
> >>

True enough. Same problem continues after all the DNSSEC effort, and now
we have created the additional problems of the other DDOS attacks using
the signed records.  Seems to be a giant step backward, with no step
forward.

> In fact, what I understood is that resolvers mostly have problems
> switching to DNSSEC not due to DNSSEC but due to DNSSEC requiring
> EDNS0. And mind you, the EDNS0 was released in what? 1999?
> 
> It's not the crypto that's the resolvers issue. That's easilly solved
> by adding a cpu or a box.

The transition issue you speak of is a different problem.  The DOS 
attack I speak of is when your caching server gets lots of requests for 
DNSSEC records, which it then must verify. These requests aren't 
'legitimate' in the sense that users made these queries genuinely trying 
to get information.  These requests are bogus, generated only with the 
purpose of creating load on the server.  Verifying the crypto keys is 
not easy.  Verifying millions is impossible. 

> > yourdomain.com.  When the roots (or TLDs, etc) get millions of
> > forged UDP packets, the roots can't block the incoming
> > packets---that would severely harm the target IP addresses. On the
> > other end, the target IP addresses can't block the root
> > servers---that would also seriously harm the target IP addresses.
> > The target just has to 'take it'.
> >
> > perhaps only 64 bytes), the more damaging this attack is.  Since
> > there are (or may be--probably will be)  a number of additional (and
> > large) DNSSEC records in a response, the response could get quite
> > large, causing significant damage. So yes, that is a reason not to
> > deploy DNSSEC.
> 
> like "let's not do HDTV because the home user DSL might not be able to
> download it in real time anyway".

No, actually, it isn't like that at all.  If there is no amplification,
the botnet will simply use ICMP or something it already has a program to
do. When there is amplification (perhaps up to 100x in this case) a very
small botnet can do a very great deal of damage, for a much longer time.  
A great deal of effort has gone into eliminating 'smurf amps'; networks
that allow broadcast ping responses.  DNSSEC is the greatest smurf amp
of all time, and it can't be shut off like one can blocking ICMP to a
broadcast addresss.

To put it another way, the necessary size of the botnet was reduced by a
factor of 100. That size reduction puts 'taking down microsoft' in the
range of much, much smaller botnets. 

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:35:51 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:39:39 -0400 (EDT)

> requests/second over TCP. Or at least not thousands of new sessions/second.

I agree. TCP connection caching is necessary.  

> servers with TCP queries.

I am interested in helping with this.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:39:39 -0400 (EDT)

--Dean

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Aug 2008 13:45:43 -0400

bert hubert wrote:
> This means disabling one of the more widely used MTAs.

Could you please elaborate on this? Which MTA, how does it use DNS, and 
is the way it uses it intractable?

> It may require some work to beef up TCP support though,

The problem, I think, is TCP itself, not TCP support within 
implementations. E.g. resource limits per IP address (16 bits of port 
number) don't scale to current-size Internet scale.

So, short of dramatic changes to TCP that support better scalability and 
performance, it's kind of out of scope for DNS itself.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Aug 2008 13:45:43 -0400

Brian

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 19:46:39 +0200

On Mon, Aug 18, 2008 at 05:27:24PM +0000, Paul Vixie wrote:

> TCP/53 a redheaded stepchild and its uses are all dangerous or unscalable.
> (that initiators do the close, and that responders have a minimum 2-minute
> timeout, says that any conformant implementation can be slapped down hard
> with a three line perl script running anywhere on the internet.)

DNS over TCP is a damn sight easier than WWW over TCP. Ask the webserver
guys about their query rates..

We've just had it easy over the past years, and it shows.

The server I mean by the way is microsoft exchange, which likes to do DNS
over TCP.

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 19:46:39 +0200

Bert

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:51:20 -0400 (EDT)

On Mon, 18 Aug 2008, Jim Reid wrote:

> > Ok, I agree that totally DNSSEC-oblivious servers won't be a problem
> > for DOS, but of course remain susceptible to poisoning even if the
> > stub resolver and the authority server both implement DNSSEC.
> 

Its not any different; its exactly the same problem.  And DNSSEC creates 
more problems, without solving any.

> poisoning. 

TCP is another 'game in town'.  We may also be able to invent other
'games', as DJB suggests.

> So to go back to David's original question: will deploying DNSSEC
> break anything that's already in use that doesn't support DNSSEC?

Yes: DNSSEC enables DDOS attacks that didn't exist before, and doesn't
eliminate any attacks that previously existed.

> >> Now if that resolving server does pay attention to the DO bit, it
> >> will set it on the query it makes to the authoritative server. That
> >> makes the authoritative server return an answer which will contain
> >> the new RRSIG and the resolving server's cache is updated
> >> accordingly.
> >
> > don't actually verify the responses? They just cache the response
> > for the stub resolver to verify?  These servers can still be
> > poisoned with invalid record combinations that they pass on to stub
> > resolvers, resulting in the DOS.  Such servers may still be subject
> > tFrom [email-masked]  Mon Aug 18 10:51:20 2008
Date: Mon, 18 Aug 2008 13:51:20 -0400 (EDT)

On Mon, 18 Aug 2008, Jim Reid wrote:

> > Ok, I agree that totally DNSSEC-oblivious servers won't be a problem
> > for DOS, but of course remain susceptible to poisoning even if the
> > stub resolver and the authority server both implement DNSSEC.
> 

Its not any different; its exactly the same problem.  And DNSSEC creates 
more problems, without solving any.

> poisoning. 

TCP is another 'game in town'.  We may also be able to invent other
'games', as DJB suggests.

> So to go back to David's original question: will deploying DNSSEC
> break anything that's already in use that doesn't support DNSSEC?

Yes: DNSSEC enables DDOS attacks that didn't exist before, and doesn't
eliminate any attacks that previously existed.

> >> Now if that resolving server does pay attention to the DO bit, it
> >> will set it on the query it makes to the authoritative server. That
> >> makes the authoritative server return an answer which will contain
> >> the new RRSIG and the resolving server's cache is updated
> >> accordingly.
> >
> > don't actually verify the responses? They just cache the response
> > for the stub resolver to verify?  These servers can still be
> > poisoned with invalid record combinations that they pass on to stub
> > resolvers, resulting in the DOS.  Such servers may still be subject
> >o the race condition I described.
> 
> latest version of the zone on the master?

In that scenario, the old data is consistent. In my scenario, poisoning
has created inconsistent data on the non-verifying DNSSEC cache.

> In fact in the somewhat contrived scenario you pose, the stub resolver
> gets a validation failure. So they at least know something has gone
> wrong. Which has to be a great leap forward from getting bad
> (poisoned) data and not having the slightest clue that has happened.

The resolver 'knows' perhaps, but the user doesn't know anything. They
just know that they typed in 'www.yahoo.com' and got no IP address.  
That's a DOS.

And its no leap forward. In the original cache poisoning case, the user
either gets, nothing, a non-working IP or they get the wrong server. If
they get the wrong server, their SSL verification and trust procedure
will exclude that server from use.  That's a DOS, too. 

> Right. Makes perfect sense. [Add scarcasm to taste.]

No, I already agreed that a totally DNSSEC-oblivious wasn't going to
pose a DNSSEC problem.  Your sarcasm is misplaced.

		--Dean

 to the race condition I described.
> latest version of the zone on the master?

In that scenario, the old data is consistent. In my scenario, poisoning
has created inconsistent data on the non-verifying DNSSEC cache.

> In fact in the somewhat contrived scenario you pose, the stub resolver
> gets a validation failure. So they at least know something has gone
> wrong. Which has to be a great leap forward from getting bad
> (poisoned) data and not having the slightest clue that has happened.

The resolver 'knows' perhaps, but the user doesn't know anything. They
just know that they typed in 'www.yahoo.com' and got no IP address.  
That's a DOS.

And its no leap forward. In the original cache poisoning case, the user
either gets, nothing, a non-working IP or they get the wrong server. If
they get the wrong server, their SSL verification and trust procedure
will exclude that server from use.  That's a DOS, too. 

> Right. Makes perfect sense. [Add scarcasm to taste.]

No, I already agreed that a totally DNSSEC-oblivious wasn't going to
pose a DNSSEC problem.  Your sarcasm is misplaced.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:56:09 -0400 (EDT)

> attacker's ability to poison caches effectively.

If the DNSSEC cache doesn't verify the records it caches, it is still 
suceptible to poisoning.

DNSSEC caches that verify are subject to a crypto-overload attack by 
large numbers of queries.

Both kinds of attacks ultimately result in a DOS

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 18 Aug 2008 13:56:09 -0400 (EDT)

--Dean

---

From: "Joe Baptista" <[email-masked]>
Date: Mon, 18 Aug 2008 14:26:59 -0400

On Mon, Aug 18, 2008 at 12:02 PM, Paul Hoffman <[email-masked]>wrote:

> Note the subject of this particular thread. From [email-masked]  Mon Aug 18 11:27:08 2008
Date: Mon, 18 Aug 2008 14:26:59 -0400
From: "Joe Baptista" <[email-masked]>
To: [email-masked]
Subject: [DNSOP] Fwd:  Pointless FUD and confusion about DNSSEC deployment
Sender: [email-masked]
On Mon, Aug 18, 2008 at 12:02 PM, Paul Hoffman <[email-masked]>wrote:

> Note the subject of this particular threadA more carefully-worded

No it is not so little grasshopper.  The best way to secure DNS recursive
servers is to integrate a smart IDS and firewall solution.  Commerce needs
solutions - not more patches to patch the patches that should have been
patched years ago.

cheers
joe baptista

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Aug 2008 11:34:16 -0700

On Aug 18, 2008, at 11:26 AM, Joe Baptista wrote:
> The best way to secure DNS recursive servers is to integrate a smart  
> IDS and firewall solution.

Hard shell, gooey interior?   You're kidding, right?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Aug 2008 11:34:16 -0700

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 21:36:11 +0200

On Mon, Aug 18, 2008 at 07:20:16PM +0000, Paul Vixie wrote:
> it *can't* scale.  laws of physics.

'When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong.'

Consider this a compliment.

> so what does microsoft exchange do when it tries to talk to a tinydns service
> like everydns.net who doesn't implement TCP/53 at all?

It doesn't need to - it speaks to resolvers.

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 21:36:11 +0200

Bert

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Aug 2008 15:45:03 -0400

> large numbers of queries.

Surely another way to express the same thing is, "DNSSEC-enabled
servers and caching recursors require many more resources in order to
avoid susceptibility to DoS."  Or something like that.  After all,
resource-exhaustion attacks are also possible against DNSSEC-oblivious
systems.  DNSSEC does open a new line of such attack, and one needs to
provision for it.  No?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 18 Aug 2008 15:45:03 -0400

A

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Aug 2008 15:48:38 -0400

> It doesn't need to - it speaks to resolvers.

Okay, so there's a huge difference between "disabling one of the more 
widely used MTAs", and "creates a reasonable dependence on 
locally-operated resolvers".

Paul's original proposal, IIIIC (if I interpret it correctly) applies to 
resolver<->authority-server communications, not stub<->resolver 
communications.

Anyone can install and operate a resolver that permits (local) TCP 
connections from stub clients, and as such, even if other parts of the 
food chain change, this doesn't break - meaning the aforementioned MTA 
doesn't get disabled by the proposal.

So, I think this is a bit of a red herring...

"MTA (TCP) resolver (UDP) authority server" is perfectly reasonable, 
especially if the (UDP) includes (EDNS +/- DNSSEC).

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 18 Aug 2008 15:48:38 -0400

Brian

---

From: "Joe Baptista" <[email-masked]>
Date: Mon, 18 Aug 2008 15:51:53 -0400

On Mon, Aug 18, 2008 at 2:34 PM, Ted Lemon <[email-masked]> wrote:

>> The best way to secure DNS recursive servers is to integrate a smart IDS
>> and firewall solution.
>>
>

No.  I was thinking more of a smart porcupine with attitude.  At least use
the IDS to notify the system administrator an attack is in progress.  I've
attached a document that uses snort to log the event.  That could be used to
notify the system administrator.

But the vision I have is of an integrated DNS - IDS - Firewall solution with
an appropriate rules base for known attack vectors.

cheers
joe baptista
On Mon, Aug 18, 2008 at 2:34 PM, Ted Lemon <[email-masked]> wrote:

>cZrAGgThNSrAKTQylJsA1prmCafto32Noi/TSSu
>> The best way to secure DNS recursive servers is to integrate a smart IDS
>> and firewall solution.
>>
>

No.  I was thinking more of a smart porcupine with attitude.  At least use
the IDS to notify the system administrator an attack is in progress.  I've
attached a document that uses snort to log the event.  That could be used to
notify the system administrator.

But the vision I have is of an integrated DNS - IDS - Firewall solution with
an appropriate rules base for known attack vectors.

cheers
joe baptista

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Aug 2008 13:02:29 -0700

On Aug 18, 2008, at 12:51 PM, Joe Baptista wrote:
> No.  I was thinking more of a smart porcupine with attitude.  At  
> least use the IDS to notify the system administrator an attack is in  
> progress.  I've attached a document that uses snort to log the  
> event.  That could be used to notify the system administrator.

You can call it whatever you want, but whether the exterior is hard or  
spiny, if you depend on that for network security, you don't have much  
security.   I mean, if you really think that's the way to go, tell me  
this: do you still use rsh to log into your servers?   Because really  
that's what you're saying when you say that the security in DNSSEC or  
some other DNS security protocol isn't important.   You're saying that  
authentication based on IP address is sufficient.

If you really hate DNSSEC, I could be sympathetic to the idea of using  
TSIG to protect your resolvers.   That's what started this whole long  
thread, if you remember.   But what you're talking about is snake oil  
security.   There's a lot of money in it, don't get me wrong.   But  
it's not a solution the IETF should be promoting.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 Aug 2008 13:02:29 -0700

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 19:55:43 +0000

> resolver<->authority-server communications, not stub<->resolver 

no, i was pretty much ruling them out period.  especially (RA=1 AND RD=0).
however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS on
TCP/53 as long as we also add a SHOULD on RDNS for "accept only
transactions from intended clients, most likely from within the same LAN,
campus, or ISP."  "SHOULD" is great since people who don't do it are still
compliant.  opendns wouldn't be in trouble.  but vendors would become
advised to set their defaults to a non-global ACL and then TCP/53 is
"safer."

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 19:55:43 +0000

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 22:28:31 +0200

> number) don't scale to current-size Internet scale.

It is possible to host >100000 connections on 1 IP address and 1 port, and
this happens in practice. Think, again, of webservers, which all have to
listen on port 80, yet support lots of clients simultaneously.

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 22:28:31 +0200

Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 23:06:14 +0200

On Mon, Aug 18, 2008 at 07:49:20PM +0000, Paul Vixie wrote:
> > > so what does microsoft exchange do when it tries to talk to a tinydns
> > > service like everydns.net who doesn't implement TCP/53 at all?
> > 
> what would it do if it had a TCP-forbidding firewall between it and its RDNS?

Dunno, but when PowerDNS had TCP bugs in its resolver code, all the
complaints I got were from Exchange users.

What's the rush with deprecating DNS/TCP btw? It languished in the shade for
25 years..

I worry because it turns out a single multiplexed connection between a
resolver and an authoritative server is just the ticket for doing almost
unspoofeable queries while under attack.

It serves as a semi-persistent channel (few seconds, minutes perhaps) over
which all the queries triggering the questions that are under attack can
safely be answered.

So I care about DNS over TCP as part of the entropy raising arsenal that is
(mostly) available today.

I'd hate to see it taken away!

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 18 Aug 2008 23:06:14 +0200

Bert

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 21:11:24 +0000

> complaints I got were from Exchange users.

they'll cope.

> What's the rush with deprecating DNS/TCP btw? It languished in the shade for

that's what we said about udp port randomization after bernstein invented it.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 21:11:24 +0000

they'll cope.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 18:03:38 -0400 (EDT)

> systems.  DNSSEC does open a new line of such attack, and one needs to

A factor of 100 is nothing compared to Moore's Law.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 18:03:38 -0400 (EDT)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 18:08:07 -0400 (EDT)

On Mon, 18 Aug 2008, Joe Baptista wrote:

> No.  I was thinking more of a smart porcupine with attitude.  At least use the IDS to notify the system
> administrator an attack is in progress.  I've attached a document that uses snort to log the event.  That could be
> used to notify the system administrator.
> 
> But the vision I have is of an integrated DNS - IDS - Firewall solution with an appropriate rules base for known
> attack vectors.

Okay. So now an attack is going on, and your pager told you. What are you going to do?

1) nothing
2) clean the cache every 5 minutes hoping the race won't do damage in between cleanups
3) drop all incoming DNS packets for the spoofed domain, effectively DOS'ing the domain under attack
4) enable DNSSEC to deal with the situation

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 18:08:07 -0400 (EDT)

1) nothing

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 18:11:14 -0400 (EDT)

> listen on port 80, yet support lots of clients simultaneously.

Bad example. One of the reasons we don't see more crypto per default on
web browsing is precisely the limitations of SSL/CA's on using SSL with
virtual host web sites. I'd hardly call the lack of port 443 a success
story.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 18:11:14 -0400 (EDT)

Paul

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 00:31:09 +0200

> virtual host web sites. I'd hardly call the lack of port 443 a success

I must be more stupid than normal - care to elaborate how limitations (I
wasn't aware of, btw) on virtual webhosting authenticated and encrypted
using SSL certificates have any bearing on the suitability of TCP/IP for DNS
levels of performance?

	Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 00:31:09 +0200

Bert

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Aug 2008 15:47:46 -0700

Andrew,

On Aug 18, 2008, at 6:29 AM, Andrew Sullivan wrote:
> When the CTO receives the incident report, the CTO is going to say,  
> "So if

In today's Internet, most network engineers (at least at real  
companies) don't go turning on new, weird technologies for fun.  If  
some technology is going to be deployed, there is generally a business  
reason for that to happen.  If there is a failure of that technology,  
it may make sense to back out of deployment, but presumably that  
failure does not remove the business reason that caused the technology  
to be deployed in the first place.  As such, the new policy most  
likely will have an "unless <condition>" clause.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Aug 2008 15:47:46 -0700

Andrew,

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 22:57:50 +0000

> virtual host web sites. I'd hardly call the lack of port 443 a success

we don't need a reason to deprecate tcp/53 beyond what's written in rfc1035.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Aug 2008 22:57:50 +0000

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 09:21:05 +0900

Not at all.

If a caching server is not required to perform public key computation
to verify RRs before caching, cache poisoning won't be detected by
the caching server, average clients of which suffer from long lasting
DOS of DNSSEC verification failure, turn off DNSSEC and will be a
victim of another poisoning on their own cache.

A property of Kaminsky's attack that it is effective against a single
target is useful, here.

If a caching server is required to perform public key computation to
verify RRs before caching, it can't support much clients and will be
a so easy victim of DDOS. Average clients of it turn off DNSSEC and ...
Or, an average administrator of the server turns off DNSSEC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 09:21:05 +0900

Not at all.

						Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Aug 2008 12:26:59 +1000

> listen on port 80, yet support lots of clients simultaneously.

	Recursive nameserver have different scaling problems to
	HTTP servers.  It's not just the connections coming in.
	It's, more importantly, the connections going out as well.

	It's the re-tuning/replacement of the OS.  It the
	re-tuning/replacment of the firewall/NAT.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Aug 2008 12:26:59 +1000

Mark

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Aug 2008 20:03:31 -0700

>> The fact is DNSSEC is the *only* game in town for preventing cache  

Which game do you propose?

> to verify RRs before caching, ...

Then the caching server isn't really implementing DNSSEC.

> a so easy victim of DDOS.

Hence, one of the reasons for the desire to push DNSSEC towards the  
end user.  For example, I am fairly confident the validating caching  
server running on my laptop isn't going to be any more subject to a  
DDOS due to the increased cost of crypto verification that it would be  
subject to a DDOS due to (say) a ping flood.

I am curious what you propose as an alternative.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Aug 2008 20:03:31 -0700

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 12:22:42 +0900

David Conrad wrote:

> Hence, one of the reasons for the desire to push DNSSEC towards the  end 
> user.

You mean all the DNSSEC clients should directly ask authoritative
nameservers and all the firewalls preventing so should be modified.

OK.

Let's assume all the clients agree with you and start using DNSSEC
and all the administrators of firewalls agree with you and perform
modification (though I don't know how NAT can be modified).

Then, the increased load is a very good reason for root servers not
support DNSSEC.

> I am curious what you propose as an alternative.

Abandon DNSSEC and accept the reality that, even with DNSSEC,
management of DNS is not very secure.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 12:22:42 +0900

OK.

						Masataka Ohta

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2008 23:31:52 -0400 (EDT)

> nameservers and all the firewalls preventing so should be modified.

(distributed) point to point encryption (or validation) is the future!

> modification (though I don't know how NAT can be modified).

I see no problem for port 53 through NAT's. That is when using DNSSEC.
When not using DNSSEC, you have issues with NAT devices undoing your
source port randomizations. Also, firewall admins can still do things
like transparent proxying of DNS. But really, so many desktop applications
do direct DNS now themselves with disregard of the OS, those networks
would be broken anyway.

> Then, the increased load is a very good reason for root servers not

I believe 99% of the load of root servers is bogus queries anyway.
Plus, I'm sure they wouldn't mind an increase to signal/noise ratio.
Plus, those are addressed my things like anycast. It all scales fairly
well, DNS being a distributed system and all. I'll take this argument
as valid as soon as a root server operator comes forward and tells us
this is a problem. For YOUR objections, let's stick to YOUR problems.

>> I am curious what you pFrom [email-masked]  Mon Aug 18 20:45:38 2008
Date: Mon, 18 Aug 2008 23:31:52 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>, David Conrad <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> nameservers and all the firewalls preventing so should be modified.

(distributed) point to point encryption (or validation) is the future!

> modification (though I don't know how NAT can be modified).

I see no problem for port 53 through NAT's. That is when using DNSSEC.
When not using DNSSEC, you have issues with NAT devices undoing your
source port randomizations. Also, firewall admins can still do things
like transparent proxying of DNS. But really, so many desktop applications
do direct DNS now themselves with disregard of the OS, those networks
would be broken anyway.

> Then, the increased load is a very good reason for root servers not

I believe 99% of the load of root servers is bogus queries anyway.
Plus, I'm sure they wouldn't mind an increase to signal/noise ratio.
Plus, those are addressed my things like anycast. It all scales fairly
well, DNS being a distributed system and all. I'll take this argument
as valid as soon as a root server operator comes forward and tells us
this is a problem. For YOUR objections, let's stick to YOUR problems.

>> I am curious what you proropose as an alternative.
>

That's not an alternative (nor correct)

Paul

pose as an alternative.
> management of DNS is not very secure.

That's not an alternative (nor correct)

Paul

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 13:01:39 +0900

> (distributed) point to point encryption (or validation) is the future!

It's no future.

> I see no problem for port 53 through NAT's.

NAT often captures and modifies packet to port 53.

> But really, so many desktop applications
> do direct DNS now themselves with disregard of the OS,

Today, most of them are using a DHCP-supplied server.

> I believe 99% of the load of root servers is bogus queries anyway.

The amount of bogus queries will also increases, of course.

> this is a problem. For YOUR objections, let's stick to YOUR problems.

FYI, root server load was my problem and anycast is my thing.

More anycasting means more cost.

> That's not an alternative (nor correct)

That's the reality with no alternatives.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 13:01:39 +0900

It's no future.

						Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Aug 2008 21:22:30 -0700

On Aug 18, 2008, at 8:22 PM, Masataka Ohta wrote:
> nameservers

Yes.

> and all the firewalls preventing so should be modified.

The vast majority of firewalls allow 'connections' (even UDP ones) to  
be initiated from the inside.  Those that prevent DNS from working  
correctly could be modified or upgraded or the administrators could  
trust in that firewall to protect the caching server used by multiple  
clients from the DDoS attacks you are concerned about.

> modification (though I don't know how NAT can be modified).

NAT does not need to be modified.  As I type this, I am behind a  
commercial (relatively low end -- an Apple Airport Extreme  
basestation) NAT with firewalling enabled.  It works just fine.

> Then, the increased load is a very good reason for root servers not

The root server operators have demonstrated that they are quite  
capable of ramping capacity to meet demand (actually, the root servers  
are wildly over provisioned to try to deal with DDoS attacks so I  
doubt the increase in load caused by what I'm suggesting would even be  
an issue).

Alternatively, we could move to a more distributed model of DNS  
operations in which the caching servers that are doing DNSSEC cache  
the entire root zone, perhaps zone transferring the signed root zone  
from some authoritative and trusted place.  Since the root trust  
anchor would be published, the root zone data would be verifiable so  
fears of a corrupted root zone would be eliminated.

I suspect a combination of both would more than suffice.

What's more, recent studies have indicated that approximately 98% of  
the traffic hitting the root servers is pure crap.  Interestingly,  
when the L-root server was renumbered, it seems the quantity of  
traffic hitting that root server is significantly lower than the  
others.  One possible reason for this could be that people just don't  
like ICANN.  Another reason could be that a really tremendous amount  
of crap is being generated by servers that are so old that they don't  
notice a root server address change.  In the latter case, pushing  
caching servers out towards the edges would almost certainly entail  
upgrading those name servers.  As a result, the root servers might  
actually see a reduction in traffic.

> management of DNS is not very secure.

Ah.  The "Math is hard.  Let's go shopping." alternative.  Not sure  
this is particularly helpful.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 18 Aug 2008 21:22:30 -0700

Yes.

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Aug 2008 08:55:31 -0400

On Mon, Aug 18, 2008 at 03:47:46PM -0700, David Conrad wrote:

> In today's Internet, most network engineers (at least at real companies) 
> don't go turning on new, weird technologies for fun.  

This is true.

> If some technology is going to be deployed, there is generally a
> business reason for that to happen.

This is also true, but in my experience one of those business reasons
is, depressingly often, "This is the Current Thinking I read in
_Network World_.  We need to get this done!"  If there is a boom on
for DNSSEC deployment, and the tools are not available, and naive
deployers screw it up, the cost:benefit evaluation ("analysis" is
way too generous) in such companies will, I predict, change back to
"don't deploy", and stay there.  Those companies will never look at
the technology again, whatever the business reason is.  "Too risky.
It doesn't work.  It breaks things."

Sure, large organizations with large, mostly competent, and very
conservative IT departments (think "banks") will probably not have
this problem and will probably deploy successfully.  None of that will
matter, however, if everyone else starts adopting policies like
"disable DNSSEC -- too risky."

Now, maybe that doesn't matter for many of these cases.  It is
entirely possible that DNSSEC deployment for most zones is just not
worth it.  If that's true, however, why are we so worried about poison
attacks?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Aug 2008 08:55:31 -0400

This is true.

A

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 15:09:38 +0200

> worth it.  If that's true, however, why are we so worried about poison

Because quite a number of people care deeply about the success of DNSSEC,
and this is a window of opportunity where DNSSEC finally addresses something
operators worry about.

The cost is not an issue that is dwelled upon now.

	Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 15:09:38 +0200

Bert

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 19 Aug 2008 22:40:45 +0900

David Conrad wrote:

> commercial (relatively low end -- an Apple Airport Extreme  basestation) 
> NAT with firewalling enabled.  It works just fine.

So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly. Unlike highe end NAT, low end NAT won't
bother to interfere DNS.
  
Cloud you please provide us, not your personal experience, but
an *EXHAUSTIVE*, or, at least exhaustive on high end, list on
varieties of NAT functionalities?

> The root server operators have demonstrated that they are quite  capable 
> of ramping capacity to meet demand (actually, the root servers  are 
> wildly over provisioned to try to deal with DDoS attacks so I  doubt the 
> increase in load caused by what I'm suggesting would even be  an issue).

Increase on the nameservers directly interacting authoritative
nameservers increases not only legitimate queries but also DDOS
queries.

> operations in which the caching servers that are doinFrom [email-masked]  Tue Aug 19 06:42:05 2008
Date: Tue, 19 Aug 2008 22:40:45 +0900

David Conrad wrote:

> commercial (relatively low end -- an Apple Airport Extreme  basestation) 
> NAT with firewalling enabled.  It works just fine.

So what? NAT at airport must be, unlike NATs in enterprises,
consumer friendly. Unlike highe end NAT, low end NAT won't
bother to interfere DNS.
  
Cloud you please provide us, not your personal experience, but
an *EXHAUSTIVE*, or, at least exhaustive on high end, list on
varieties of NAT functionalities?

> The root server operators have demonstrated that they are quite  capable 
> of ramping capacity to meet demand (actually, the root servers  are 
> wildly over provisioned to try to deal with DDoS attacks so I  doubt the 
> increase in load caused by what I'm suggesting would even be  an issue).

Increase on the nameservers directly interacting authoritative
nameservers increases not only legitimate queries but also DDOS
queries.

> operations in which the caching servers that are dog DNSSEC cache  the 
> entire root zone, perhaps zone transferring the signed root zone  from 
> some authoritative and trusted place.

Are you seriously saying that you actively want to have intermediate
caching servers between your laptop and authoritative servers?

Then, as I mentioned, the caching server are so easy victims of DOS.

Anyway, your approach is meaningless against "com.".

> Another reason could be that a really tremendous amount  of crap is 
> being generated by servers that are so old that they don't  notice a 
> root server address change.

Thank you for providing yet another evidence that DNSSEC won't be
deployed so much.

> this is particularly helpful.

Remember that I was the only person who understood the math of
both DNS and PKI, when DENSEC was initially discussed.

Yes, "Math is hard" for you.

As the person who still understand the math of both, I can
authoritatively declare that DNSSEC is fundamentally broken,
which you could have argue against 10 years ago but not now.

							Masataka Ohta

ing DNSSEC cache  the 
> entire root zone, perhaps zone transferring the signed root zone  from 
> some authoritative and trusted place.

Are you seriously saying that you actively want to have intermediate
caching servers between your laptop and authoritative servers?

Then, as I mentioned, the caching server are so easy victims of DOS.

Anyway, your approach is meaningless against "com.".

> Another reason could be that a really tremendous amount  of crap is 
> being generated by servers that are so old that they don't  notice a 
> root server address change.

Thank you for providing yet another evidence that DNSSEC won't be
deployed so much.

> this is particularly helpful.

Remember that I was the only person who understood the math of
both DNS and PKI, when DENSEC was initially discussed.

Yes, "Math is hard" for you.

As the person who still understand the math of both, I can
authoritatively declare that DNSSEC is fundamentally broken,
which you could have argue against 10 years ago but not now.

							Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 07:52:38 -0700

> consumer friendly. Unlike highe end NAT, low end NAT won't

Right.  Because low-end consumer gear is always so much better  
implemented than enterprise gear.

> varieties of NAT functionalities?

I'll get right on that.

Actually, on second thought, you seem to be the one asserting  
fundamentally broken behavior on the part of high end gear.  Shouldn't  
it be you that provides the data to back up your assertions?

> nameservers increases not only legitimate queries but also DDOS

You seem to be asserting that DDOS queries come from the same source  
as legitimate queries.  Can I see your data that backs up this  
statement?

>> operations in which the caching servers that are doing DNSSEC  
>> cache  the

No. I'm suggesting that if the root zone is signed, the root zone data  
can be obtained from places other than the root servers without  
concerns about data corruption and installed in caching servers  
(something quite a few folks already do, ignoring the risk of  
corrupted data).  This data can then be distributed out to the edge.   
This should address any concerns anyone might have with overloading  
the root servers.

> Anyway, your approach is meaningless against "com.".

Due to the thrash in the COM zone, yes. Fortunately, I didn't suggest  
applying the distributed model to COM.

> authoritatively declare that DNSSEC is fundamentally broken,

Well, I guess that settles it then.  You don't have to turn on DNSSEC.

> which you could have argue against 10 years ago but not now.

It's such a shame that computer processing technology for doing stuff  
like cryptography hasn't advanced in 10 years.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 07:52:38 -0700

I'll get right on that.

Regards,
-drc

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 09:09:20 -0700

> like cryptography hasn't advanced in 10 years.

Unfortunately, the Internet has grown in 10 years, too.

Do you want to fund my costs of supporting (and encouraging my clients 
to use) DNSSEC?

If I'm going to spend cycles on improving the state of the art, it will 
be with a solution that is:

1) Solving a real customer need
2) Possible to evaluate
3) Realistic to implement

I've yet to be shown how DNSSEC is any of those things. D-H key 
exchanges, DTLS, DNS PING, all sound far more appealing.

-David

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 09:09:20 -0700

-David

---

From: Richard Lamb <[email-masked]>
Date: Tue, 19 Aug 2008 09:14:45 -0700

Another 10 year delay would benefit all our respective businesses ;-) But to move forward you sometimes have to take chances.
-Rick

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Ulevitch
Sent: Tuesday, August 19, 2008 9:09 AM
To: David Conrad
Cc: [email-masked] WG
Subject: Re: [DNSOP] Cache poisoning on DNSSEC

-David

---

From: Richard Lamb <[email-masked]>
Date: Tue, 19 Aug 2008 09:14:45 -0700

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Ulevitch
Sent: Tuesday, August 19, 2008 9:09 AM
To: David Conrad
Cc: [email-masked] WG
Subject: Re: [DNSOP] Cache poisoning on DNSSEC

-David

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 12:07:04 -0400 (EDT)

> "disable DNSSEC -- too risky."

DNSSEC is purely optional though. Anyone can decide to 1) not publish
DNSSEC auth data and 2) not use DNSSEC based resolvers. What happens
after that, is not up to engineers. It will be up to lawyers to proof
someone not deploying DNSSEC made the best decision in the interest
of their customers. As for TLD's, I wonder what will happen if .eu
decides to go DNSSEC, but .com won't. It will be interesting to watch
and see if organisations start migrating away from .com then, at
which point DNSSEC would have to be deployed to ensure not losing
customers.

> worth it.  If that's true, however, why are we so worried about poison

Because this is only true for the authorative part of DNSSEC. Since
Dan showed you can cache poison any non-DNSSEC resolver for ANY domain,
not just the domains you are not protecting, you basically have no choice
but to mitigate this problem. And DNSSEC, for good or bad, is what we
have right now.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 12:07:04 -0400 (EDT)

Paul

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 19:00:45 +0200

> but to mitigate this problem. And DNSSEC, for good or bad, is what we

Is there some sort of shield preventing people from reading or even arguing
with
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01213.html 
?

All those things can be done today, unilaterally, and they start working
from the moment you enable them.

In fact, I'm so far not having luck getting around even my 3-year old
primitive anti-spoofing behaviour. I've reduced the number of ports I use to
10 to make things more doable, but no luck.

So please consider other options before repeating the holy mantra 'DNSSEC is
the only solution'. 

	Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 19:00:45 +0200

Bert

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:09:16 -0700

On Aug 19, 2008, at 10:00 AM, bert hubert wrote:
> primitive anti-spoofing behaviour.

Have you tried dsniff anywhere on the path the DNS packets take?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:09:16 -0700

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:03:00 -0700

David,

On Aug 19, 2008, at 9:09 AM, David Ulevitch wrote:
>> It's such a shame that computer processing technology for doing  
>> stuff like cryptography hasn't advanced in 10 years.

Indeed it has.  However, I gather Masataka is concerned about (D)DoS  
against caching servers due to the increased workload of validating  
cryptographic signatures.  If the caching server is moved down closer  
to the end node, the fact that the Internet has grown becomes  
irrelevant since the validation load is being spread across many  
machines.

> Do you want to fund my costs of supporting (and encouraging my  
> clients to use) DNSSEC?

I don't use your service.  If your customers feel there is value in  
what DNSSEC can provide, they'll presumably pay you for DNSSEC  
functionality and if you don't have it, they'll find some other way of  
meeting their needs.  Of course, the decision is yours as to whether  
and/or at what point in time you want to take the risk/cost of adding  
DNSSEC functionality to your service.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:03:00 -0700

David,

Regards,
-drc

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:06:17 -0400 (EDT)

> from the moment you enable them.

Unless, for example, you're behind a NAT router undoing source port randomizations.
Yes, a lot of large companies with enough bandwidth do silly things like that.

> So please consider other options before repeating the holy mantra 'DNSSEC is

Making a race harder is not a solution. It is a workaround. What is needed
is a real solution. 10 years ago, in 1998, most people had bandwidth of
about 14k4 on dialup and the transaction ID was good enough. Now, when
I move into a new house here I get Fast Ethernet, and we know that it is
not good From [email-masked]  Tue Aug 19 10:20:40 2008
Date: Tue, 19 Aug 2008 13:06:17 -0400 (EDT)
From: Paul Wouters <[email-masked]>
To: bert hubert <[email-masked]>
Cc: [email-masked], Andrew Sullivan <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
 (fwd))
Sender: [email-masked]

> from the moment you enable them.

Unless, for example, you're behind a NAT router undoing source port randomizations.
Yes, a lot of large companies with enough bandwidth do silly things like that.

> So please consider other options before repeating the holy mantra 'DNSSEC is

Making a race harder is not a solution. It is a workaround. What is needed
is a real solution. 10 years ago, in 1998, most people had bandwidth of
about 14k4 on dialup and the transaction ID was good enough. Now, when
I move into a new house here I get Fast Ethernet, and we know that it is
not gooenough and we patched it up using source port randomisations. In
another 10 years, 1 billion mobile phones with have that bandwidth each.

Sure, it was cool we could delay a real solution today using port randomisations,
but it's still a workaround, one that was resisted as long as we could for
good reasons. Do we really want to wait another 10 years and then add another
few bits with something like dns-0x20? And who says there won't be easier
races to be run in the near future? Or yet more not-so-random transaction
ids or not-so-random source ports?

On top of that, people seem to forget about the simpler cases of DNS spoofing.
When we're on 3G and wifi all the time, anyone can see our DNS requests, and
spoofing those is trivial. Your quoted URL disregards that as "a lost case
anyway", which it is not. If deploying DNSSEC, attackers can see and try to
modify all the way, but it won't help them lure me to their evil sites. And
dns-0x20 or soure port randomistion is not going to help me there.

The case for a theoretically secure DNS is long past us. If I can't use the
internet at Star Bucks safely, it is not a solution for this era.

Paul

d enough and we patched it up using source port randomisations. In
another 10 years, 1 billion mobile phones with have that bandwidth each.

Sure, it was cool we could delay a real solution today using port randomisations,
but it's still a workaround, one that was resisted as long as we could for
good reasons. Do we really want to wait another 10 years and then add another
few bits with something like dns-0x20? And who says there won't be easier
races to be run in the near future? Or yet more not-so-random transaction
ids or not-so-random source ports?

On top of that, people seem to forget about the simpler cases of DNS spoofing.
When we're on 3G and wifi all the time, anyone can see our DNS requests, and
spoofing those is trivial. Your quoted URL disregards that as "a lost case
anyway", which it is not. If deploying DNSSEC, attackers can see and try to
modify all the way, but it won't help them lure me to their evil sites. And
dns-0x20 or soure port randomistion is not going to help me there.

The case for a theoretically secure DNS is long past us. If I can't use the
internet at Star Bucks safely, it is not a solution for this era.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Aug 2008 10:20:39 -0700

> exchanges, DTLS, DNS PING, all sound far more appealing.

A simple solution that doesn't work always sounds better than a  
complex solution that does work, particularly if you analyze neither  
solution deeply enough to understand what each one buys you, and what  
each one does not buy you.

The question is not, "do you want to implement DNSSEC?"   Clearly you  
don't.   It's not "can we use DTLS to protect the last mile in the  
current DNS model?"   Clearly we can, if people want to, and nobody's  
saying not to do that.

The real question is, "are you harmed if people who *do* see DNSSEC as  
solving a real need that they have do implement it?"   Or perhaps  
better stated, "should people who need DNSSEC be prevented from  
implementing for your benefit?"

The answer to that question has to take into account what benefit  
accrues to you from preventing DNSSEC from being deployed.   And that  
is why David asked the question he asked.   What benefit accrues to  
you from stopping the deployment of DNSSEC?

It's really silly for us to be debating whether or not we personally  
want to use DNSSEC.   If you don't want to use it, don't use it.   But  
I *do* want to use it.   And in order for me to use it, the root zone  
and the TLDs have to start using it.   So the question is, is that bad  
for you for some reason?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Aug 2008 10:20:39 -0700

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:13:44 -0400 (EDT)

> primitive anti-spoofing behaviour.

Funny, that's not what Dan's talk said. PowerDNS specifically was trivial to
spoof based on bogus query types, since PowerDNS dropped those packets and
the evil guy could race without the good guy racing, and therefor always win
and inject bogus records. You, like everyone else needed to patch against
one of Dan's attacks. So don't come with this "my 3 year old code was not
vulnerable" thing just because you didn't have the same bug as bind. You had
a different bug, which would have not been an issue if three years ago instead
you had DNSSEC.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:13:44 -0400 (EDT)

Paul

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 10:27:39 -0700

David Conrad wrote:

> I don't use your service.  If your customers feel there is value in what 
> DNSSEC can provide, they'll presumably pay you for DNSSEC functionality 
> and if you don't have it, they'll find some other way of meeting their 
> needs.  Of course, the decision is yours as to whether and/or at what 
> point in time you want to take the risk/cost of adding DNSSEC 
> functionality to your service.

You forgot to wrap that in </I once read a business magazine on an 
airplane>.  But I'll take your non-answer as a "no."

Nonetheless, I'll share some data. I've yet to have a single person, who 
was not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS.

-David

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 10:27:39 -0700

-David

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:35:54 -0700

Andrew,

On Aug 19, 2008, at 5:55 AM, Andrew Sullivan wrote:
> _Network World_.
...
> Those companies will never look at

I long ago gave up fighting against the market for what I felt was  
'the right thing' in Internet technology.  If a sufficient portion of  
the market decides DNSSEC is too risky or it doesn't work or it breaks  
things, so be it.  Trust me when I say it is not something I will lose  
sleep over.

The reason for my earlier question is that I believe that there is  
sufficient interest in getting the root signed by folks who have  
interest in DNSSEC for it to actually happen.  If signing the root  
were to have a significant and direct negative impact on folks who  
consider DNSSEC a fool's errand then it would argue strongly against  
signing the root. However, lacking that and since the only folks that  
will experience the joys of DNSSEC should be those who explicitly  
configure it, it would seem the harm done by signing the root would be  
minimal.

So far, I have seen what appears to be a lot of FUD from Masataka and  
the usual concerns/complaints about DNSSEC from folks who haven't  
implemented it in their products or services.  Peter Koch did provide  
an interesting data point that warrants further investigation (20-35%  
of queries having DO bit on seems a bit high to me) and someone else  
responded privately that signing the root could impact the root  
servers due to an increase in the number of TCP connections caused by  
folks who turn on DNSSEC but pretty much everyone else who has  
responded said they see no problems.

I suspect the question as to what will break if the root is signed  
will be asked in "venues that matter" in the near future.  It would be  
nice to have an answer, or at least an idea of what to look for,  
before hand.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:35:54 -0700

Andrew,

...

Regards,
-drc

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 10:39:01 -0700

Ted Lemon wrote:
> accrues to you from preventing DNSSEC from being deployed.   And that is 
> why David asked the question he asked.   What benefit accrues to you 
> from stopping the deployment of DNSSEC?

First -- this is the most rational email on this thread.  Thanks.

Second -- My goal is not to derail DNSSEC.  It does that on its own.  My 
goal is to make sure people don't buy into the kool-aid being poured 
that DNSSEC is the only solution.  It isn't.

> want to use DNSSEC.   If you don't want to use it, don't use it.   But I 
> *do* want to use it.   And in order for me to use it, the root zone and 
> the TLDs have to start using it.   So the question is, is that bad for 
> you for some reason?

Sort of.  It means I have to start another company that will charge 
slightly less egregious fees than the rest of you plan on doing to do 
DNSSEC management for companies the same way Thawte and Verisign did for 
SSL certs.

And my plate is pretty full at the moment.

-David

---

From: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 10:39:01 -0700

-David

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 10:47:02 -0700

David,

On Aug 19, 2008, at 10:27 AM, David Ulevitch wrote:
>> functionality and if you don't have it, they'll find some other way  
>> of meeting their needs.  Of course, the decision is yours as to  
>> whether and/or at what point in time you want to take the risk/cost  
>> of adding DNSSEC functionality to your service.
>
> airplane>.

Hmm.  Sorry if you feel your business model is threatened.

> But I'll take your non-answer as a "no."

That is indeed my answer.  Sorry if that wasn't clear.  Not sure why  
you'd think it would be an appropriate question to even ask.

> Nonetheless, I'll share some data. I've yet to have a single person,  
> who was not a DNSSEC implementor or fanboy, request DNSSEC support  
> at OpenDNS.

Nice to know.  How many people requested "D-H key exchange, DFrom [email-masked]  Tue Aug 19 10:47:39 2008
From: David Conrad <[email-masked]>
To: David Ulevitch <[email-masked]>
Date: Tue, 19 Aug 2008 10:47:02 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

David,

On Aug 19, 2008, at 10:27 AM, David Ulevitch wrote:
>> functionality and if you don't have it, they'll find some other way  
>> of meeting their needs.  Of course, the decision is yours as to  
>> whether and/or at what point in time you want to take the risk/cost  
>> of adding DNSSEC functionality to your service.
>
> airplane>.

Hmm.  Sorry if you feel your business model is threatened.

> But I'll take your non-answer as a "no."

That is indeed my answer.  Sorry if that wasn't clear.  Not sure why  
you'd think it would be an appropriate question to even ask.

> Nonetheless, I'll share some data. I've yet to have a single person,  
> who was not a DNSSEC implementor or fanboy, request DNSSEC support  
> at OpenDNS.

Nice to know.  How many people requested "D-H key exchange, DTLTLS, DNS  
PING"?

Regards,
-drc

S, DNS  
PING"?

Regards,
-drc

---

From: kevin graham <[email-masked]>
Date: Tue, 19 Aug 2008 10:47:27 -0700 (PDT)

On Tue, 19 Aug 2008, David Conrad wrote:

> Right.  Because low-end consumer gear is always so much better implemented 
> than enterprise gear.

At least in IOS's case, there was some gross misunderstanding that CNAME's 
should have their TTL's 0'ed (CSCsj10772) as a part of their translating
payloads that contain A's and PTR's that are within nat address pools.

The behavior is now configurable ("no ip nat service dns-reset-ttl"), but 
the stance was that "it's been this way so long we can't change the 
default". Ultimately, it was the breakage due to DNSSEC (rather than 
simple incorrectness) that got it addressed.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: kevin graham <[email-masked]>
Date: Tue, 19 Aug 2008 10:47:27 -0700 (PDT)

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:35:33 -0400 (EDT)

On Tue, 19 Aug 2008, David Ulevitch wrote:

> Nonetheless, I'll share some data. I've yet to have a single person, who was 
> not a DNSSEC implementor or fanboy, request DNSSEC support at OpenDNS.

Well duh. For once, anyone who is asking you gets qualified as "fan boy", so your
statement is self-fullfilling.

Second, anyone using OpenDNS has already outsources their DNS security with you,
so they expect you to do 'the right thing'.

This is like saying just because i tell my car mechanic "replace my tires when you
think they need replacement", and no one has asked for Good Year tires, you 
as the car mechanic conclude there is no demand for Good Year tires. On the contrary,
I assume you give me the best tires.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:35:33 -0400 (EDT)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:40:33 -0400 (EDT)

On Tue, 19 Aug 2008, David Ulevitch wrote:

> Sort of.  It means I have to start another company that will charge slightly 
> less egregious fees than the rest of you plan on doing to do DNSSEC 
> management for companies the same way Thawte and Verisign did for SSL certs.

Except now, there are no browser vendors dictating who gets a cert or at what
price one can start selling certs or at which policy one is allowed into the
browser's pre-installed trusted SSL treasure trove.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2008 13:40:33 -0400 (EDT)

Paul

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 21:23:07 +0200

> spoof based on bogus query types, since PowerDNS dropped those packets and

You misunderstood Dan's talk in that case. See
http://doc.powerdns.com/powerdns-advisory-2008-02.html for details. 

> vulnerable" thing just because you didn't have the same bug as bind. You
> had a different bug, which would have not been an issue if three years ago
> instead you had DNSSEC.

Perhaps I should explain myself better. The software I refer to has detected
spoofing attempts in the past 3 years already, and acted on that. The
software I refer to has further behaviour that, unintentionally, makes
spoofing it very hard.

Again - this is about TODAY. DNSSEC might be the end all solution but even
if it is, it is not deployed widely today and it won't be 12 months from
now.

Countermeasures serve a function.

	Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 21:23:07 +0200

Bert

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Aug 2008 15:43:14 -0400

On Tue, Aug 19, 2008 at 10:35:54AM -0700, David Conrad wrote:

> it in their products or services.  Peter Koch did provide an interesting 
> data point that warrants further investigation (20-35% of queries having DO 
> bit on seems a bit high to me) and someone else responded privately that 

I think Peter's data point sure warrants further investigation, yes.

> I suspect the question as to what will break if the root is signed will be 
> asked in "venues that matter" in the near future.  It would be nice to have 
> an answer, or at least an idea of what to look for, before hand.

I completely agree with this.  The reason I didn't answer the actual
question you asked is, of course, I don't know.  We haven't collected
the data so far.  The best we can say is, "It shouldn't, assuming
correct protocol implementations out there."  We know, however, that
the correct protocol implementations are not the only implementations,
and therefore that we will have surprise breakages during deployment.
I suspect this is a risk we will have to live with in the case of any
deployment of significant new DNS features, unfortunately.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Aug 2008 15:43:14 -0400

A

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 21:24:32 +0200

> Have you tried dsniff anywhere on the path the DNS packets take?

Not yet - I have inspected the packets I am transmitting and the spoofing
attempts.

I do get a lot of 'near miss' packets that almost succeeded though, so the
tools I am using are getting their packets in.

	Bert

---

From: bert hubert <[email-masked]>
Date: Tue, 19 Aug 2008 21:24:32 +0200

Bert

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Aug 2008 13:05:33 -0700

> if it is, it is not deployed widely today and it won't be 12 months  

Nobody's disputing that point.   Is this why we are arguing?   The  
reason I'm pushing DNSSEC is with a view to the future, not with the  
idea that we're going to solve the spoofing problem on a practical  
level right now.   I just want us to start down the road, because if  
we don't start we will never get to the point where DNSSEC is a  
solution for anyone.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Aug 2008 13:05:33 -0700

---

From: [email-masked]
Date: Tue, 19 Aug 2008 23:09:33 +0200 (CEST)

>From my own limited investigations (less than 10 servers, but millions
of DNS queries thus hopefully somewhat statistically significant):

  Authoritative servers: 35 - 45%
  Recursive servers:     In the noise (less than 0.5%)

which seems to indicate that there are quite a few recursive servers
out there that set the DO bit when querying authoritative servers.

One of the authoritative servers measured is a ccTLD server for .no.

Steinar Haug, Nethelp consulting, [email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: [email-masked]
Date: Tue, 19 Aug 2008 23:09:33 +0200 (CEST)

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 16:37:28 -0700

On Aug 19, 2008, at 2:09 PM, [email-masked] wrote:
>>> Peter Koch did provide an interesting
>>> bit on seems a bit high to me)
>>

Yes.  I've just been told by a fairly authoritative source that BIND  
9.5.1 (at least) sets the DO bit on by default, regardless of whether  
DNSSEC is configured. This would explain the high number of queries  
coming in with DO set.

The implication of this implementation decision is that if the root is  
signed, folks using BIND 9.5.1 (at least) will be requesting DNSSEC  
regardless of whether the caching server operator has configured  
DNSSEC or is prepared to handle a DNSSEC-related response.

Food for thought.

Regards,
-drc

P.S. Seems I need to revise 3225...

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Aug 2008 16:37:28 -0700

Food for thought.

Regards,
-drc

---

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Aug 2008 22:32:23 -0400 (EDT)

> What's the rush with deprecating DNS/TCP btw? It languished in the shade for

TCP doesn't work with Anycast, as was stated in RFC1546.  And Root
server operators are supposed to offer TCP to everyone, not just those
that use the stateless UDP service that works with Anycast.  Do you
remember that David Kessens, then the Operations Area Director took out
a PR action against me to silence discussion about Anycast Root server
operations?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Aug 2008 22:32:23 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Aug 2008 23:15:12 -0400 (EDT)

The claims that verifying DNSSEC caches can't be poisoned isn't true
after all.

> A property of Kaminsky's attack that it is effective against a single

I don't know if anyone noticed, but in fact, according to RFC4035 the
delegation records and the glue records are not signed.  A verifying
DNSSEC cache can be poised with bad glue records using the poisoning
attack, with only a slight change to the Kaminsky software.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 19 Aug 2008 23:15:12 -0400 (EDT)

--Dean

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Aug 2008 20:27:17 -0700

On Aug 19, 2008, at 8:15 PM, Dean Anderson wrote:
> A verifying

Do you mean that it can be convinced that an answer is valid when it  
is not?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Aug 2008 20:27:17 -0700

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 20 Aug 2008 09:41:15 +0200

> bit on seems a bit high to me) and someone else responded privately that 
        
I seem to remember that some time back (two years or so?) RIPE-NCC
also published data points and they were in about the same range.

Some searching reveals:

	Ref:            ripe-352
	Title:          Measuring the resource requirements of DNSSEC
	Author:         Olaf Kolkman
		RIPE NCC / NLnet Labs
	Date:           October 2005
	Format:         PDF=5367108

The URL for this: ftp://ftp.ripe.net/ripe/docs/ripe-352.pdf.

Already three years ago, time flies

	jaap

---

From: Jaap Akkerhuis <[email-masked]>
Date: Wed, 20 Aug 2008 09:41:15 +0200

Some searching reveals:

	Ref:            ripe-352

	jaap

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 09:46:31 +0200

> better still, let's deprecate these bit patterns altogether for OP=QUERY:

Breaks some sendmail versions and qmail.

> 	QCLASS=255

QCLASS != IN seems more reasonable to me.

> 	RA=1 AND RD=0

By the responder or the initiator?

> and let's also make explicit that TCP is not to be used unless UDP
> returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned
> only one SOA.

I strongly oppose this approach.  Unsolicited TCP has its place.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 09:46:31 +0200

---

From: Jelte Jansen <[email-masked]>
Date: Wed, 20 Aug 2008 10:03:59 +0200

> Already three years ago, time flies

We also did another one for ripe a little bit later, but still more than
two years ago:

http://nlnetlabs.nl/downloads/publications/dnssec/From [email-masked]  Wed Aug 20 01:04:04 2008
Date: Wed, 20 Aug 2008 10:03:59 +0200
From: Jelte Jansen <[email-masked]>
To: Jaap Akkerhuis <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs
 (fwd))
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

> Already three years ago, time flies

We also did another one for ripe a little bit later, but still more than
two years ago:

http://nlnetlabs.nl/downloads/publications/dnssednssec-effects.pdf

Jelte

---

From: Alexander Gall <[email-masked]>
Date: Wed, 20 Aug 2008 11:17:38 +0200

> I think Peter's data point sure warrants further investigation, yes.

More data points from two authoritative servers for the ch ccTLD:
40-50% (I've attached the relevant DSC graphs for the past month).

I looked more closely on one of the servers.  Out of about 22 million
queries in the past 11 hours, about 10 million from 161000 different
sources had the DO flag set.

-- 
Alex

---

From: Alexander Gall <[email-masked]>
Date: Wed, 20 Aug 2008 11:17:38 +0200

-- 
Alex

---

From: "Ondřej Surý" <[email-masked]>
Date: Wed, 20 Aug 2008 11:24:35 +0200

2008/8/19 kevin graham <[email-masked]>:
> default". Ultimately, it was the breakage due to DNSSEC (rather than simple
> incorrectness) that got it addressed.

It took me hell lot of time and emails to explain this problem to tacman :-(.

Origin of this bug comes from broken implementation of RFC2694.  And
unfortunatelly
I was not able to explain to them that they should modify TTL only in cases
covered by RFC2694.

The bad side of this bug is, that it breaks TSIG :(.  I tried to have my own
public resolvers protected by TSIG.

Ondrej.

---

From: "Ondřej Surý" <[email-masked]>
Date: Wed, 20 Aug 2008 11:24:35 +0200

Ondrej.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 11:55:34 +0200

> sources had the DO flag set.

Interesting, thanks.  It seems that the BIND 9.3 recursor sets the DO
bit by default, even if it does not support DNSSEC on the client
interface without "dnssec-enable yes;" (IOW, the DO bit is ignored
there).

(Unbound sets the DO bit, too, but it processes it on the responder
side as well.)

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 11:55:34 +0200

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Aug 2008 20:49:46 +1000

DO says that you *understand* DNSSEC and that it is ok to
	send a DNSSEC response.  It does not mean that you will be
	validating the response.

	named in all production versions of BIND 9 (9.1.0 onwards)
	has set DO on all EDNS queries.  BIND 9.1.1 onwards named
	copies DO to the response.

	BIND 8 does EDNS w/o setting or examining D0.

	What this says is that over half the world is in a position
	to turn on DNSSEC validation today if they want to.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Aug 2008 20:49:46 +1000

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 22:16:58 +0900

David Conrad wrote:

> implemented it in their products or services.

Unlike me, you have no implementation expertise.

I did implement server code for my proposal of "Simple Secure
DNS" more than 10 years ago to confirm that, unlike DNSSEC, it can
be implemented easily. From the beginning, I knew it is essentially
(except to support read/write new RR types from/to zone file) less
than 100 lines of modification to BIND and it actually was so.

As a lazy implementor, I can design protocols to avoid useless
implementation efforts. As a faithful protocol designer, I
implement my design to confirm it actually require little
implementation efforts.

At that time, because of fundamental complexFrom [email-masked]  Wed Aug 20 06:18:09 2008
Date: Wed, 20 Aug 2008 22:16:58 +0900
From: Masataka Ohta <[email-masked]>
To: David Conrad <[email-masked]>
Cc: [email-masked], Andrew Sullivan <[email-masked]>
Subject: Re: [DNSOP] A different question (was Re: Kaminsky on djbdns	bugs
 (fwd))
Sender: [email-masked]

David Conrad wrote:

> implemented it in their products or services.

Unlike me, you have no implementation expertise.

I did implement server code for my proposal of "Simple Secure
DNS" more than 10 years ago to confirm that, unlike DNSSEC, it can
be implemented easily. From the beginning, I knew it is essentially
(except to support read/write new RR types from/to zone file) less
than 100 lines of modification to BIND and it actually was so.

As a lazy implementor, I can design protocols to avoid useless
implementation efforts. As a faithful protocol designer, I
implement my design to confirm it actually require little
implementation efforts.

At that time, because of fundamental complity, there was no DNSSEC
implementation.

Thus, I am the implementer who can authoritatively declare that all
the impelementors and system administrators of DNSSEC do not
understand both of DNS and PKI and are brain dead.

I, of course, won't bother to implement proven-to-be-fundamentally-
broken DNSSEC nor join proven-to-be-useless attempts to improve
the proven-to-be-fundamentally-broken protocol.

Anyway, the other problem of DNSSEC is that PKI, as a concept, is
fundamentally broken, against which no PKI protocol can be useful.

						Masataka Ohta

exity, there was no DNSSEC
implementation.

Thus, I am the implementer who can authoritatively declare that all
the impelementors and system administrators of DNSSEC do not
understand both of DNS and PKI and are brain dead.

I, of course, won't bother to implement proven-to-be-fundamentally-
broken DNSSEC nor join proven-to-be-useless attempts to improve
the proven-to-be-fundamentally-broken protocol.

Anyway, the other problem of DNSSEC is that PKI, as a concept, is
fundamentally broken, against which no PKI protocol can be useful.

						Masataka Ohta

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 15:27:25 +0200

> fundamentally broken, against which no PKI protocol can be useful.

I think we need to recast DNSSEC as mere transport protection measure.
It might be a overengineered for this purpose, but it's what we've got
now.  At this stage, I doubt that a simpler, more lightweight protocol
could be deployed with less effort.

I think I can understand your pains.  With hindsight, the original
IPv6 design ("Simple Internet Protocol") turned out to be superior to
the current spec, too.  It 's not fair, but unfortunately, it doesn't
matter. 8-(

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 15:27:25 +0200

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 22:41:50 +0900

> delegation records and the glue records are not signed.

Really? (I am not interested in reading RFC4035 only to confirm DNSSEC
is broken beyond any attempt of repair)

Then, it should not have been a problem if correct authority model
of refferal was used, because cached glue records should have been
used only for the refferal of same <random> domain name appears again,
probability of which is negligible.

However, according to Paul, most implementations are broken, 
upgrading of which is as time consuming as upgrading implementations
to use modified protocol with, say, effectively 64 bit ID.

> attack, with only a slight change to the Kaminsky software.

Can you demonstrate it with existing implementations?

							Masataka Ohta

PS

Birtyday attacks can, seemingly, be protected against if outstanding
query is invalidated (query fails) upon a reception of partially
matching (query and server address but not ID matches) answer.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 22:41:50 +0900

Masataka Ohta

PS

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 22:53:31 +0900

>	copies DO to the response.

Caching servers not validating the response?

Then, the following argument applies.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 22:53:31 +0900

Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 14:01:54 +0000

[email-masked] (David Ulevitch) writes:

> ... -- My goal is not to derail DNSSEC.  It does that on its own.  My 

that depends on the problem statement, really.  if the problem statement is
"how can we secure hop-by-hop" then there are other solutions on the table
right now besides DNSSEC.  if the problem statement is "how can we secure
end-to-end" then there are no other solutions on the table right now.

my chosen problem statement is "how can we secure end-to-end" because i am
worried about corruption inside servers not just between them, and i want
to defend against provider-in-the-middle attacks (including several that
opendns currently monetizes.)
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 14:01:54 +0000

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 16:11:36 +0200

> Caching servers not validating the response?

Yes, this is still a widely-held view.  To be honest, I don't think it
makes much sense.  We need DNSSEC right now, not at some unknown
future date when operating system vendors have shipped security-aware,
validating stub resolvers for a while, so that there is finally a
client population which supports end-to-end DNSSEC.

What's worse, end-to-end DNSSEC support for mobile devices (which move
from networks with resolvers which support end-to-end DNSSEC to
networks which don't) is a completely unsolved problem.  We are
basically at stage 0: denial that the problem exists.  Not good at
all.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 16:11:36 +0200

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 14:14:53 +0000

> opendns currently monetizes.)

i forgot to mention, i'm also worried about on-path attackers not just the
off-path attackers kaminsky, klein and dagon have recently noted.  no hop-
by-hop solution can address the problem of a MiTM who can see and/or alter
your queries and responses.

therefore even though end-to-end ("DNSSEC") has been painful and has taken
too long to get deployable and is rather ugly, i'm backing it.
-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 14:14:53 +0000

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 23:15:06 +0900

> It might be a overengineered for this purpose, but

DNSSEC is too overengineered and, thus, complex to be a reliable
protection.

> I doubt that a simpler, more lightweight protocol

Isn't port randomization enough? If not, DNS over TCP is no more
difficult to deploy than DNSSEC.

> the current spec, too.

My understanding is that, though IPv6 is more complex than SIP, neither
really addresses the issue of routing table explosion that they are
equally bad.

So, I'm recently working on a protocol named IP--, which is carefully
desinged to enable automatic renumbering of not only customers but
also ISPs, which is an essential part to solve routing table
explosion.

> It 's not fair, but unfortunately, it doesn't matter. 8-(

It doesn't matter, because we keep using PODS and IPv4. DNS in a
new generation network will use 64 bit IDs.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 23:15:06 +0900

Masataka Ohta

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 07:19:32 -0700

> Unlike me, you have no implementation expertise.

Um. Right.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 07:19:32 -0700

Um. Right.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 23:25:39 +0900

Paul Vixie wrote: 

> right now besides DNSSEC.

Wrong.

PKI, including DNSSEC, does require hop-by-hop security between CAs,
which is no different from hop-by-hop security between ISPs.

Note that, at least in Japan, both ISPs and CAs are leagally required
to be secure, which has nothing to do with cryptographic security.

> my chosen problem statement is "how can we secure end-to-end"

And the answer is "by sharing security information directly by both
ends", which is not the case with PKI where security information is
shared (or confirmed) hop-by-hop through multiple third party CAs.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 20 Aug 2008 23:25:39 +0900

Wrong.

							Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2008 10:26:03 -0400

> attack, with only a slight change to the Kaminsky software.

Please outline exactly how you think this will work.  I just re-read
section 5 of RFC 4035, and I can't see how it can, assuming you do in
fact have a set of valid trust anchors for some superordinate zone to
the victim domain.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Aug 2008 10:26:03 -0400

A

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 00:34:01 +1000

> At that time, because of fundamental complexity, there was no DNSSEC
> implementation.
> 

	The current DNSSEC essentially matches "Simple Secure DNS".

		NSEC + RRSIG(NSEC) <=> ZL
		RSIG(type) <=> RRD + NSIG
		DNSKEY <=> ZA
		RRSIG(DS) <=> ZSIG
		DS <=> RDD(ZA)
	
	The trust model is the same as "Simple Secure DNS".
	The threat model is the same as "Simple Secure DNS".
	ZL has the same issues as NSEC has.

	KSK/ZSK maps directly into this from "Simple Secure DNS".

					 A secure zone is a zone whose
   authentication is provided by the protocol whereas a secure node is a
   node authoritatively belongs to a secure zone.  A secure zone has its
   own secret information to generate signatures for secure nodes in the
   zone.

	DNSKEY uses public keys which you recommended.

				The signature can be verified by
   sharing secret information between related parties or by using
   private/public key technology.

	RRSIG = TYPE + 32768 would have been better than how we
	actually did it in RFC 4035.

	While things are encoded slightly differently RFC 4035 is
	a implementation of "Simple Secure DNS".
	
	Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 00:34:01 +1000

Mark

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 14:41:41 +0000

> > ... let's deprecate these bit patterns altogether for OP=QUERY:
> >
> > 	QTYPE=255
> 

i once hacked sendmail internals, and what i remember is that it would try
a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the
hopeful assumption that they had the same domain name.  an earlier version
had a bug whereby it didn't know ANY was hop-by-hop even in the presence of
RD=1, so a partial answer of "A alone" was taken to mean there was no MX, but
this was fixed before my son (who is now 17) was born.  no version i know of
will fail to make an explicit MX query if ANY comes up dry, or fail to make
follow-on A queries if ANY comes up without an A.

so, can you explain what you mean by "breaks", both for sendmail and qmail?

> QCLASS != IN seems more reasonable to me.

i don't think we should foreclose the possibility that QCLASS != IN will be
useful to somebody some day.  do you know a specific risk for QCLASS != IN?

> By the responder or the initiator?

nonrecursive queries of recursive servers are a useful diagnostic but also an
information leak that can help an attacker shape their flows.  peter koch has
reminded me that a server that's both authoritative and recursive would not
be able to answer wearing its authoritative hat if this were literally
enforced, and while iFrom [email-masked]  Wed Aug 20 07:41:50 2008
From: Paul Vixie <[email-masked]>
To: [email-masked]
Date: Wed, 20 Aug 2008 14:41:41 +0000
Subject: Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
Sender: [email-masked]

> > ... let's deprecate these bit patterns altogether for OP=QUERY:
> >
> > 	QTYPE=255
> 

i once hacked sendmail internals, and what i remember is that it would try
a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the
hopeful assumption that they had the same domain name.  an earlier version
had a bug whereby it didn't know ANY was hop-by-hop even in the presence of
RD=1, so a partial answer of "A alone" was taken to mean there was no MX, but
this was fixed before my son (who is now 17) was born.  no version i know of
will fail to make an explicit MX query if ANY comes up dry, or fail to make
follow-on A queries if ANY comes up without an A.

so, can you explain what you mean by "breaks", both for sendmail and qmail?

> QCLASS != IN seems more reasonable to me.

i don't think we should foreclose the possibility that QCLASS != IN will be
useful to somebody some day.  do you know a specific risk for QCLASS != IN?

> By the responder or the initiator?

nonrecursive queries of recursive servers are a useful diagnostic but also an
information leak that can help an attacker shape their flows.  peter koch has
reminded me that a server that's both authoritative and recursive would not
be able to answer wearing its authoritative hat if this were literally
enforced, and while think there should be no server wearing both a recursive
hat and an authoritative hat, i don't think we should legislate against it in
this proposal.  so we can't literally outlaw a bit pattern, but we can say,
if RD=0 then no non-authority data should be returned.

> > returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only
> > one SOA.
> 

are you strongly in favour of amending RFC 1035 4.2.2 to say that responders
initiate close, or that timeouts of less than two minutes are allowed?  this
is the one of the least scalable and most vulnerable elements in all of DNS.

with rich stevens gone and nobody to complete or champion T/TCP, we're left
with several bad multipacket protocols including IP fragmentation and TCP for
handling data larger than the MTU.  i don't know how to make TCP scale for
this, it's not like TCP/80 where server operators who want to handle a million
simultaneous queries know that they'll need a lot of silicon+power to do it.

did RDP (RFC 908, RFC 1151) ever achieve critical mass?

 i think there should be no server wearing both a recursive
hat and an authoritative hat, i don't think we should legislate against it in
this proposal.  so we can't literally outlaw a bit pattern, but we can say,
if RD=0 then no non-authority data should be returned.

> > returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only
> > one SOA.
> 

are you strongly in favour of amending RFC 1035 4.2.2 to say that responders
initiate close, or that timeouts of less than two minutes are allowed?  this
is the one of the least scalable and most vulnerable elements in all of DNS.

with rich stevens gone and nobody to complete or champion T/TCP, we're left
with several bad multipacket protocols including IP fragmentation and TCP for
handling data larger than the MTU.  i don't know how to make TCP scale for
this, it's not like TCP/80 where server operators who want to handle a million
simultaneous queries know that they'll need a lot of silicon+power to do it.

did RDP (RFC 908, RFC 1151) ever achieve critical mass?

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 17:07:25 +0200

* Paul Vixie:

[QTYPE=ANY deprecation]

> so, can you explain what you mean by "breaks", both for sendmail and

I thought deprecation means that responders (especially resolvers) are
free to discard such queries.  At least that's how the binary label
deprecation was interpreted by some folks.  I don't see how this would
be different, at least for resolvers.

[QCLASS != IN deprecation]

> i don't think we should foreclose the possibility that QCLASS != IN
> will be useful to somebody some day.  do you know a specific risk
> for QCLASS != IN?

Reducing the arbitrariness of the DNS header reduces the risk that you
run into a query/response loop with some other service (like chargen
or time).

> nonrecursive queries of recursive servers [snip]

Ahem, my concern was that the RA bit is set by the responder, while
the RD bit is set by the initiator.  RA=1 *queries* don't make much
sense, no matter what the RD bit is.  As Peter Koch noted, RA=1, RD=0
responses occur in the wild.  So I was confused.

[DNS over TCP deprecation]

> are you strongly in favour of amending RFC 1035 4.2.2 to say that
> responders initiate close, or that timeouts of less than two minutes
> are allowed?

No need to update RFC 1035, RFC 1123 already did that: "A name server
MAY limit the resources it devotes to TCP queries" (section 6.1.3.2).

> it's not like TCP/80 where seFrom [email-masked]  Wed Aug 20 08:08:01 2008
To: Paul Vixie <[email-masked]>
From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 17:07:25 +0200
Cc: [email-masked]
Subject: Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
Sender: [email-masked]

* Paul Vixie:

[QTYPE=ANY deprecation]

> so, can you explain what you mean by "breaks", both for sendmail and

I thought deprecation means that responders (especially resolvers) are
free to discard such queries.  At least that's how the binary label
deprecation was interpreted by some folks.  I don't see how this would
be different, at least for resolvers.

[QCLASS != IN deprecation]

> i don't think we should foreclose the possibility that QCLASS != IN
> will be useful to somebody some day.  do you know a specific risk
> for QCLASS != IN?

Reducing the arbitrariness of the DNS header reduces the risk that you
run into a query/response loop with some other service (like chargen
or time).

> nonrecursive queries of recursive servers [snip]

Ahem, my concern was that the RA bit is set by the responder, while
the RD bit is set by the initiator.  RA=1 *queries* don't make much
sense, no matter what the RD bit is.  As Peter Koch noted, RA=1, RD=0
responses occur in the wild.  So I was confused.

[DNS over TCP deprecation]

> are you strongly in favour of amending RFC 1035 4.2.2 to say that
> responders initiate close, or that timeouts of less than two minutes
> are allowed?

No need to update RFC 1035, RFC 1123 already did that: "A name server
MAY limit the resources it devotes to TCP queries" (section 6.1.3.2).

> it's not like TCP/80 where rver operators who want to handle a
> million simultaneous queries know that they'll need a lot of
> silicon+power to do it.

I agree it's a bad idea to roll out TCP-only resolvers without changes
on the authoritative side.  An EDNS0 flag saying "I'm willing to take
the TCP load" might be necessary.

> did RDP (RFC 908, RFC 1151) ever achieve critical mass?

Not likely, given that the acronym has been reused for something
totally different.  I think for reliable datagram transport with some
deployment, you need to use SCTP.  I've never seen this RDP in the
wild.

server operators who want to handle a
> million simultaneous queries know that they'll need a lot of
> silicon+power to do it.

I agree it's a bad idea to roll out TCP-only resolvers without changes
on the authoritative side.  An EDNS0 flag saying "I'm willing to take
the TCP load" might be necessary.

> did RDP (RFC 908, RFC 1151) ever achieve critical mass?

Not likely, given that the acronym has been reused for something
totally different.  I think for reliable datagram transport with some
deployment, you need to use SCTP.  I've never seen this RDP in the
wild.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 01:17:44 +1000

> basically at stage 0: denial that the problem exists.  Not good at

	The end state is likely to be something like.

			 Machine
	------------------------------------------------------
	| DNSSEC aware client <-> validating iterative cache |
	------------------------------------------------------

	The DNSSEC aware client may or may not leave the validation
	to the validating iterative cache.

	At the moment we have

	  HOME			  ISP
	----------		---------
	| client |	<->	| cache |
	----------		---------

	Moving to the following generally would be a good steps forward

	  HOME			           HOME
	----------		------------------------------
	| client |	<->	| validating iterative cache |
	----------		------------------------------

			or 

		     Machine 
	-----------------------------------------
	| client <-> validating iterative cache |
	-----------------------------------------

	as it puts the policy with the policy consumer.

	If you have a validating stub resolver you need to think
	about what cache it talks to.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 01:17:44 +1000

Machine

	At the moment we have

	  HOME			  ISP
	----------		---------
	| client |	<->	| cache |
	----------		---------

	  HOME			           HOME

			or 

		     Machine 

	Mark

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 00:26:25 +0900

> 	The current DNSSEC essentially matches "Simple Secure DNS".

Well, mostly. Thank you for your pointer to RFC4035 I ignored.

And, congratulations that the WG has wasted only 10 years of
implementation and operational experiences to reach the
conclusion that the original DNSSEC is, as I said with a small
implementation and no operational effort, broken.

Now, I'm saying, for these 10 years, that PKI, including DNSSEC,
is broken.

Can't you simply believe me?

> 	actually did it in RFC 4035.

Yes, An essential difference is that NSIG is a lot more compact than
entire RSIG or RRSIG.

However, another essential difference is that as you increases the
variations of cryptography algorithms, the size of the entire RSIG
or RRSIG increases, which is, IMO, more serious than the increase
of possible RR types.

So, I designed simple secure DNS so that everything fits within
512B assuming RSA data of 1024 bit or 1500B assuming 2048 bit
(Unlike many Japanese, I don't believe in PK with elliptic
functions).

> 	ZL has the same issues as NSEC has.

The non-issue is based on a misunderstanding that online generation
of signature were insecure, even though the signature generation
mechanism must, anyway, be socially accessible.

That signature generation mechanism is accessible on line dose not
necessarily mean that a private key is accessible on line.
 
> 	KSK/ZSK maps directly into this from "Simple Secure DNS".

I have no idea on what KSK/ZSK means. But, it's OK.

> 	DNSKEY uses public keys which you recommended.

As a person who dose understand PKI but without much expertise on it,
I was not sure that public key cryptography was reliable. So, I tried
to make "Simple Secure DNS" work with shared key cryptography with
KDCs.

Now, I'm sure neither CAs nor KDCs are not very reliable, because
they need blind belief on intelligent intermediate entities of CAs
or KDCs, directly violating the end-to-end principle.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 00:26:25 +0900

Masataka Ohta

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 15:27:15 +0000

i answered this on namedroppers, where the thread actually belongs.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 15:27:15 +0000

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 17:36:43 +0200

> Can't you simply believe me?

No, because DNSSEC, as it will be deployed, is not a PKI.  There is no
registration process which is universally agreed upon.  As a result, a
DNSSEC signature carries no semantic value.  (It's possible to change
this through local configuration, but this still doesn't give you a
globally interoperable PKI.)

---

From: Florian Weimer <[email-masked]>
Date: Wed, 20 Aug 2008 17:36:43 +0200

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 00:42:16 +0900

> client population which supports end-to-end DNSSEC.

Fortunately enough, we don't need DNSSEC at all.

> basically at stage 0: denial that the problem exists.  Not good at

What's wrong with resolvers on mobile hosts? I'm afraid you are
assuming roaming over private IP networks without end-to-end
visibility, which is often the case with 3GPP, which is not
a problem of the Internet.

BTW, DNS is definitely not end-to-end, because it relies on
intelligent intermediate eitities of name servers.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 00:42:16 +0900

Masataka Ohta

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2008 08:45:42 -0700

At 5:36 PM +0200 8/20/08, Florian Weimer wrote:
>No, because DNSSEC, as it will be deployed, is not a PKI.

Masataka is right that PKI as it is widely used (PKIX) is broken. 
Florian is right that DNSSEC as it stands today is not PKI. The trust 
model in DNSSEC is completely parallel to the data model. In the PKIX 
world, it is bolted on to the side in a way that often surprises 
users.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2008 08:45:42 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 01:03:20 +0900

Florian Weimer wrote:

> registration process which is universally agreed upon.

A PKI with a universally agreed registration process of "it depends"
is still a PKI.

However, a problem of PKI is that, even if such a process is agreed
upon, the process is not cryptographically enforced, which means PKI
is not cryptographically secure.

> but this still doesn't give you a globally interoperable PKI.)

As "universal" is a wiesel word with its own scope, a PKI is not
necessarily globally interoperable.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 01:03:20 +0900

Masataka Ohta

---

From: David Ulevitch <[email-masked]>
Date: Wed, 20 Aug 2008 10:30:51 -0700

Paul Vixie wrote:
> no hop-by-hop solution can address the problem of a MiTM who can see
> and/or alter your queries and responses.

If you have a malicious man in the middle, he will do bad things to you.

DNSSEC will not stop that.

---

From: David Ulevitch <[email-masked]>
Date: Wed, 20 Aug 2008 10:30:51 -0700

---

From: Brian Dickson <[email-masked]>
Date: Wed, 20 Aug 2008 13:59:02 -0400

> DNSSEC will not stop that.

Too many pronouns...

DNSSEC provides the ability to determine that a given authoritative 
answer is signed (by DS on the delegation from the parent),
and provides cryptographic signatures on such authoritative answers.

The signatures can be chased up to a configured trust anchor, ideally a 
signed root.
And without any private key in that chain of trust, he can't change 
signed authoritative data without causing validation to fail.

With apologies to Meat Loaf:

A Man in the middle can
 bedevil your wits,
He can fiddle with packets,
 he can twiddle the bits,
He can easily spoof your
 sequence numbers and such,

But he can't spoof sigs,
 No he can't do that.
Oh, no,
No, he can't do that.

--
Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Wed, 20 Aug 2008 13:59:02 -0400

Too many pronouns...

A Man in the middle can
 bedevil your wits,

But he can't spoof sigs,
 No he can't do that.
Oh, no,
No, he can't do that.

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 11:02:16 -0700

David,

> If you have a malicious man in the middle, he will do bad things to  

Yep.  Question is, how many opportunities do you want to provide for  
MITM attacks?

> DNSSEC will not stop that.

The full DNS lookup path is almost always different than the data  
content path.  As such, it introduces a new MITM attack vector (and a  
particularly effective one at that as Kaminsky described).  DNSSEC is  
intended to protect against that attack vector and does so albeit at  
some cost in terms of complexity of software and operations.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 11:02:16 -0700

David,

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 18:30:13 +0000

> DNSSEC will not stop that.

please explain how i can get undetectably bad data in a dnssec environment,
where "bad" means "did not come from the zone editor."

---

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Aug 2008 18:30:13 +0000

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2008 12:28:56 -0700

>DNSSEC will not stop that.

DNSSEC will stop some of "that". It will prevent you from accepting 
changed data.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Aug 2008 12:28:56 -0700

--Paul Hoffman, Director
--VPN Consortium

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Aug 2008 23:38:02 +0200

In your previous mail you wrote:

=> it is not a mantra but the reality:
 - transaction protection is not enough if we want to keep caching
  in the middle
  (the argument is it has to be a perfect protection to be efficient,
   a single hole somewhere can corrupt an unbound amount of clients)
 - data protection is the solution
 - the right granularity is the RRset because coarser (name for instance)
  is inefficient and finer (RR) is prone to specific DoS attacks
 - the needed protection is origin and integrity, this calls for
  a signature system
So the complete solution for the cache poisoning issue is to sign RRsets.
You can specify something new from zero but it shall look very similar
to DNSSEC...

Regards

[email-masked]
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Aug 2008 23:38:02 +0200

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 00:17:11 +0200

=> as you know the DO bit means DNSSEC RRs are accepted, so an
implementation which supports them should set the DO bit.

=> s/requesting/accepting/

=> I agree only for the second (is prepared to handle).
Note this is bound to EDNS0, without it no DO, IPv6, size negotiation,
etc.

=> this was the intented side effect of 3225 so if you change you mind
you know what to do (-:).

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 00:17:11 +0200

Regards

---

From: David Conrad <[email-masked]>
Date: Wed, 20 Aug 2008 16:06:05 -0700

Francis,

On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote:
> as you know the DO bit means DNSSEC RRs are accepted, so an

Mumble.

So, DO=1 by default will result in DNSSEC-related RRs being returned,  
regardless of whether those RRs will actually be used.  What my intent  
was with 3225 is no longer particularly relevant since shipping code  
has been doing this for quite some time.

The implication of this is that the day the root gets signed, the root  
servers will be responding with DNSSEC-related RRs, regardless of  
whether caching servers intend on doing anything with them.  This  
raises a few potential operational issues:

- if the advertised EDNS0 buffer size is not large enough, it will  
trigger truncation and, as a result, an increase in the number of TCP  
sessions going to the root.

- if the advertised EDNS0 buffer size is large enough, but the network  
MTU is too small, fragmentation will occur which may cause the  
response to be dropped (for a variety of reasons).

- if there are middle boxes in the way that do stupid things (e.g.,  
disallow DNS over TCP), those middle boxes will likely drop the larger  
responses.

The concern I see (that I had hoped would be avoided by DO being set  
to 1 only when the caching server administrator had explicitly  
configured DNSSEC awareness) is that folks who are blissfully unaware  
of the root being signed would, through no fault or action on their  
part, could begin to see odd DNS failures due to one of the three  
issues I mention above.

InFrom [email-masked]  Wed Aug 20 16:06:00 2008
From: David Conrad <[email-masked]>
To: Francis Dupont <[email-masked]>
Date: Wed, 20 Aug 2008 16:06:05 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

Francis,

On Aug 20, 2008, at 3:17 PM, Francis Dupont wrote:
> as you know the DO bit means DNSSEC RRs are accepted, so an

Mumble.

So, DO=1 by default will result in DNSSEC-related RRs being returned,  
regardless of whether those RRs will actually be used.  What my intent  
was with 3225 is no longer particularly relevant since shipping code  
has been doing this for quite some time.

The implication of this is that the day the root gets signed, the root  
servers will be responding with DNSSEC-related RRs, regardless of  
whether caching servers intend on doing anything with them.  This  
raises a few potential operational issues:

- if the advertised EDNS0 buffer size is not large enough, it will  
trigger truncation and, as a result, an increase in the number of TCP  
sessions going to the root.

- if the advertised EDNS0 buffer size is large enough, but the network  
MTU is too small, fragmentation will occur which may cause the  
response to be dropped (for a variety of reasons).

- if there are middle boxes in the way that do stupid things (e.g.,  
disallow DNS over TCP), those middle boxes will likely drop the larger  
responses.

The concern I see (that I had hoped would be avoided by DO being set  
to 1 only when the caching server administrator had explicitly  
configured DNSSEC awareness) is that folks who are blissfully unaware  
of the root being signed would, through no fault or action on their  
part, could begin to see odd DNS failures due to one of the three  
issues I mention above.

 any event, I have an answer to my question...

Regards,
-drc

In any event, I have an answer to my question...

Regards,
-drc

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 01:17:21 +0200

nobody to complete or champion T/TCP

=> it seems T/TCP is dead because of some security issues.

In another thread about fragmentation (vs firewalls) someone proposed DCCP.
At least, it avoids RFC 1035 4.2.2 (:-)!

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 01:17:21 +0200

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 09:21:38 +1000

> intelligent intermediate eitities of name servers.

	Actually it doesn't.  It can be configured that way but
	there is no requirement to actually use a caching nameserver.

	Authoritative nameserver to iterative client works.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 09:21:38 +1000

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 02:01:54 +0200

If a caching server is required to perform public key computation to
   verify RRs before caching, it can't support much clients...

=> the common assumption that public key computation is slow or
expensive is *wrong*. According to 'openssl speed rsa', My old
20EUR/month box is at 2900 verify/s (1024 bits) and any recent
desktop should be >> 10000 verify/s.
DNSSEC has a cost but it is not in the asymmetric crypto part!

Regards

PS: I (as many Frenchs) believe in Elliptic Curves (mainly
because of the size, i.e., not only for the speed).
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 02:01:54 +0200

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 02:07:14 +0200

Now, I'm saying, for these 10 years, that PKI is broken.
   
=> what is broken? Crypto, trust model, architecture (including
the RA/CA stuff), etc. There should be many ways to be broken (:-).

   That signature generation mechanism is accessible on line does not
   necessarily mean that a private key is accessible on line.
    
=> I fully agree and this is IMHO the main interest of HSM (aka
crypto hardware/accelerators), which as I explained is not the
speed even some can go in 19"30...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 02:07:14 +0200

Regards

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 09:33:19 +0900

> 	there is no requirement to actually use a caching nameserver.

I'm not talking about caching servers.

> 	Authoritative nameserver to iterative client works.

There are intelligent intermediate entities of root, TLD and
other servers between you and authoritative nameservers of your
peer.

Because DNS is not end to end, DNSSEC is not secure end to end.

Root, TLD and other zones between you and a zone of your peer
are the targets of MitM attacks on DNSSEC.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 09:33:19 +0900

Masataka Ohta

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 11:00:57 +1000

> disallow DNS over TCP), those middle boxes will likely drop the larger  

	These are basically EDNS problems and will be happening
	today, as the root servers are EDNS capable, to a lesser
	or greater extent.

	Any of the clients that make queries from any of the already
	signed TLD's will have experienced the same issues.  None
	of this is new.

	You are not the first major player to sign.  You are the
	one major player that every talFrom [email-masked]  Wed Aug 20 18:02:14 2008
To: David Conrad <[email-masked]>
From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 11:00:57 +1000
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

> disallow DNS over TCP), those middle boxes will likely drop the larger  

	These are basically EDNS problems and will be happening
	today, as the root servers are EDNS capable, to a lesser
	or greater extent.

	Any of the clients that make queries from any of the already
	signed TLD's will have experienced the same issues.  None
	of this is new.

	You are not the first major player to sign.  You are the
	one major player that every talksks to.

	Caches will cope with all of the above.  There may be some
	retries.  The retries will be logged by some caches.  The
	broken middle boxes will get fixed/replaced.

	Vendors will ship less cr*pware initially as the result of
	the root being signed as their in house tests will have a
	higher probability of detecting the damage their products
	are doing.

 to.

	Caches will cope with all of the above.  There may be some
	retries.  The retries will be logged by some caches.  The
	broken middle boxes will get fixed/replaced.

	Vendors will ship less cr*pware initially as the result of
	the root being signed as their in house tests will have a
	higher probability of detecting the damage their products
	are doing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 18:07:35 -0700

>        broken middle boxes will get fixed/replaced.

Mark, is it the case that BIND is setting the DO bit and then not  
verifying signatures?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 18:07:35 -0700

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 11:27:06 +1000

> are the targets of MitM attacks on DNSSEC.

	Which can be removed if needed by exchanging trust anchors
	with peers.

	Anything other that one-to-one exchange of secrets/public
	keys involves some trust in the introducer is doing the
	right thing.

	The introducers in DNSSEC are the parent chain.
	The introducers in HTTPS are the CAs.

	If you have a solution that scales I'd love to hear it.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 11:27:06 +1000

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 11:56:47 +1000

> Mark, is it the case that BIND is setting the DO bit and then not  

	DO is not controlled by dnssec-enable or dnssec-validation.

	DNSSEC is designed to be validator to authoritative server.
	If you introduce caches then you need to ensure that your
	cache is doing something sensible.  This implies you need
	to control your cache.

	The stub to third party cache model is going away.

	You won't accept incorrect data using a third party cache
	but you can be DoS'd using a third party cache.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 11:56:47 +1000

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 10:57:15 +0900

> 	Which can be removed if needed by exchanging trust anchors

You can't.

To exchange the trust anchors, you need cryptographically secure
end to end security, which is not provided by DNSSEC.

If you and your peer already have secure channel, you have no
reason to use DNSSEC for secure identification nor communication
with the peer.

> 	keys involves some trust in the introducer is doing the

As the level of security is no different from PODS, it is the
worst thing to bother to exchange public keys.

> 	If you have a solution that scales I'd love to hear it.

Because DNS is not end to end, DNS does not really scale,
manifestation of which is load on root servers.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 10:57:15 +0900

You can't.

						Masataka Ohta

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 19:00:30 -0700

>        cache is doing something sensible.  This implies you need

So I guess the question is, do the versions of BIND that set DO have  
problems when they get big answers.   If they don't, we should be  
okay, since (correct me if I'm wrong, Mark), they will not send those  
answers out in response to queries that don't have the DO bit set.

However, that's a pretty big if.   Do we have any data one way or the  
other?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 19:00:30 -0700

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 19:03:52 -0700

> reason to use DNSSEC for secure identification nor communication

Ohta-san, this is clueless in so many ways.   It's inspiring.

First of all, perhaps you do have a secure channel to your trust  
anchor.   This doesn't mean that you have a secure channel to all the  
zones that depend from it.   So you can get the trust anchor key, and  
because you have it, you can now validate all those zones for which  
you have no such secure channel.

Secondly, secure channels can be automatic or manual.   Frequently  
they're manual.   So you use the manual channel to set up an automatic  
channel.   This is what, e.g., the PGP key signing that happens at  
every IETF is all about.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 19:03:52 -0700

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 12:21:07 +1000

> reason to use DNSSEC for secure identification nor communication

	Incorrect.
> worst thing to bother to exchange public keys.

	Incorrect.
 
> manifestation of which is load on root servers.

	None answer.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 12:21:07 +1000

Incorrect.

	Incorrect.

	None answer.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 12:32:10 +1000

> problems when they get big answers.

	No.  They advertise what they are capable of accepting.  If
	there is broken middlewhere in between that clobbers the
	response they retry.

		EDNS@4096 -> EDNS@512 -> plain DNS

> If they don't, we should be  

	The server side honours the clients DO requests.

> However, that's a pretty big if.   Do we have any data one way or the  

	How about years of operation (going back to 9.1.0) without
	people even noticing that DO is set.  If DO caused non
	recoverable problems we would have seen them long before
	now.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Aug 2008 12:32:10 +1000

Mark

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 20:03:19 -0700

>        recoverable problems we would have seen them long before

It would be helpful to have some hard data.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Aug 2008 20:03:19 -0700

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 12:15:21 +0900

> 	Incorrect.

Thank you for the convincing demonstration that I am correct.

> 	Incorrect.

Thanks again.

> 	None answer.

Wrong question.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 12:15:21 +0900

Thanks again.

Wrong question.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 12:30:31 +0900

> anchor.

First of all, you don't have a secure channel to a zone
administrator of some homepage you encountered during
netsurfing.

> This doesn't mean that you have a secure channel to all the  
> because you have it, you can now validate all those zones for which  you 
> have no such secure channel.

The problem, then, is that the validation is indirectly hop by
hop, not end to end.

There will be MitM attacks on intermediate zones.

> This is what, e.g., the PGP key signing that happens at  
> every IETF is all about.

Another example of hop by hop security can not deny the fact that
DNS security is not end to end.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 12:30:31 +0900

Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 14:41:21 +0900

Ted Lemon wrote:
 
> Ohta-san, if you want to comment on the protocol, you really ought to  
> learn how it works first.

I really hope you can learn how to read mails before sending yours.

> This is not how it works.   The way it works is that the validating  
> resolver does _all_ of the validation.

First, let your resolver try to resolve something with network
connections detached and see what happens.

Then, read the following mail of mine again (or, for the first time?).

> Subsequent validations

Such chaining of the validations is hop by hop.

No attempt to call it end to end alters the reality that MitM
attacks are possible on intermediate zones on the validation
chain.

						Masataka Ohta

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.From [email-masked]  Wed Aug 20 22:43:28 2008
Date: Thu, 21 Aug 2008 14:41:21 +0900
From: Masataka Ohta <[email-masked]>
To: Ted Lemon <[email-masked]>,  [email-masked]
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

Ted Lemon wrote:
 
> Ohta-san, if you want to comment on the protocol, you really ought to  
> learn how it works first.

I really hope you can learn how to read mails before sending yours.

> This is not how it works.   The way it works is that the validating  
> resolver does _all_ of the validation.

First, let your resolver try to resolve something with network
connections detached and see what happens.

Then, read the following mail of mine again (or, for the first time?).

> Subsequent validations

Such chaining of the validations is hop by hop.

No attempt to call it end to end alters the reality that MitM
attacks are possible on intermediate zones on the validation
chain.

						Masataka Ohta

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.ororg/mailman/listinfo/dnsop

g/mailman/listinfo/dnsop

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 21 Aug 2008 11:30:08 +0200

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Masataka Ohta

This is on data distribution path level, not infrastructure, nor data.

> Because DNS is not end to end, DNSSEC is not secure end to end.

I don't care if the infrastructure is TCP, UDP, Token ring or carier pigeons, I don't trust the infrastructure because it has a MITM (or pigeon in the middle) I don't know.
I even don't trust the data distribution, DNS, as it has a MITM as you say.
Trying to secure the infrastructure hop-by-hop is the bell-head solution, which, with an increase of operators has proven to be not scalable nor efficient.
Data is the ultimate end-to-end, from your brain into mine, whithout any dependency on the infrastructure in between.

> are the targets of MitM attacks on DNSSEC.

All these MITM are MITM in infrastructure, but not all in Data.
None of these infrastructure MITM can fiddle with the end-users data without the end-users cooperation or notice.
The only thing a MITM can do is revoke the data path to reach a trust anchor, which will trigger the flag that the data path is not secure anymore.

I agree with you that a data Parent can, without cooperation of a child, set up a new thrust-anchor, data path and data.
But parents are not the only MITM's. Parents are to be trusted, as you have accepted them in your data path. You are aware of their existence. Other MITM not in the data path, but present in the infrastructure path, aren't to be trusted.

Secure the data path not the infrastructure.
I believe that is what DNSSEC does.

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970
E [email-masked]
W http://www.sidn.nl/
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Antoin Verschuren" <[email-masked]>
Date: Thu, 21 Aug 2008 11:30:08 +0200

Antoin Verschuren

Technical Policy Advisor
SIDN
Utrechtseweg 310
PO Box 5022
6802 EA Arnhem
The Netherlands

T +31 26 3525500
F +31 26 3525505
M +31 6 23368970

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Aug 2008 08:55:43 -0400

> 	recoverable problems we would have seen them long before

I don't think that follows, which is (if I interpret him correctly)
what David Conrad was pointing out.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Aug 2008 08:55:43 -0400

A

---

From: Dean Anderson <[email-masked]>
Date: Thu, 21 Aug 2008 10:09:50 -0400 (EDT)

> Do you mean that it can be convinced that an answer is valid when it  

I mean that a validating cache can be convinced to think that a
delegation is unsigned by getting unsigned glue records without a DS
record.  This glue can refer to a working (bogus) nameserver, or it can
be a DOS on the delegation.  I might try to demonstrate this by running
code next week sometime.

One might be able prevent this only if all zones and all delegations
have been preconfigured keys, in which case RFC 4035 says a resolver
SHOULD believe a zone is signed if it has a preconfigured key. (so one
might still be spoof-able by an implmentation that doesn't reject
unsigned responses in zones with preconfigured keys. 

Of course, updating all these preconfigured keys is going to be a PITA.
This is another operational drawback, and significant operational
expense. So DNSSEC is probably a self-inflicted DOS in practice after
some key changes.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 21 Aug 2008 10:09:50 -0400 (EDT)

--Dean

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 21 Aug 2008 11:35:57 -0300

> 40-50% (I've attached the relevant DSC graphs for the past month).

I'm seeing almost the same numbers for .br.

It was 45% in May and now it's 55%.

Even that now we are doing a double signing KSK rollover the transport
% using TCP represent only 0.02%.

Fred

> 40-50% (I've attached the relevant DSC graphs for the past month).

I'm seeing almost the same numbers for .br.

It was 45% in May and now it's 55%.

Even that now we are doing a double signing KSK rollover the transport
% using TCP represent only 0.02%.

Fred

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 21 Aug 2008 23:50:20 +0900

> This is on data distribution path level, not infrastructure, nor data.

FYI, "I" of PKI is "Infrastructure".

> I don't care if the infrastructure is TCP, UDP, Token ring or carier pigeons,

The infrastructure here is PKI.

> I don't trust the infrastructure because it has a MITM

Yup. You shouldn't trust an infrastructure of PKI because it has a MitM.

> None of these infrastructure MITM can fiddle with the end-users data without the end-users cooperation or notice.

Fiddling with the end-users data is Man-at-the-edge attack and,
because of fate sharing, is not a problem.

Instead, MitM attack on DNSSEC is performed, for example, within
intermediate zones with forged signature on child zone with forged
end-users data.

> But parents are not the only MITM's. Parents are to be trustedFrom [email-masked]  Thu Aug 21 08:04:10 2008
Date: Thu, 21 Aug 2008 23:50:20 +0900
From: Masataka Ohta <[email-masked]>
To: Antoin Verschuren <[email-masked]>
Cc: [email-masked]
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

> This is on data distribution path level, not infrastructure, nor data.

FYI, "I" of PKI is "Infrastructure".

> I don't care if the infrastructure is TCP, UDP, Token ring or carier pigeons,

The infrastructure here is PKI.

> I don't trust the infrastructure because it has a MITM

Yup. You shouldn't trust an infrastructure of PKI because it has a MitM.

> None of these infrastructure MITM can fiddle with the end-users data without the end-users cooperation or notice.

Fiddling with the end-users data is Man-at-the-edge attack and,
because of fate sharing, is not a problem.

Instead, MitM attack on DNSSEC is performed, for example, within
intermediate zones with forged signature on child zone with forged
end-users data.

> But parents are not the only MITM's. Parents are to be trusted,
> as you have accepted them in your data path. You are aware of
> their existence.

Then, upstream ISPs are to be trusted, as we have accepted them
in our data path. We are aware of their existence.

It means that there is no MitM attack on PODS.

> I believe that is what DNSSEC does.

Your fundamental misunderstanding is that you misunderstand PKI
not an infrastructure.

							Masataka Ohta

,
> as you have accepted them in your data path. You are aware of
> their existence.

Then, upstream ISPs are to be trusted, as we have accepted them
in our data path. We are aware of their existence.

It means that there is no MitM attack on PODS.

> I believe that is what DNSSEC does.

Your fundamental misunderstanding is that you misunderstand PKI
not an infrastructure.

							Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Aug 2008 10:36:47 -0400

On Fri, Aug 22, 2008 at 12:01:16AM +1000, Mark Andrews wrote:

> The issues David was pointing out have been visible for years.  So
> to has the recovery behaviour if one choose to look for it.  There
> is nothing new in what David has been saying.

I think you may be missing the import of what he's saying, though.
The entire deployment strategy for DNSSEC has been a gradual
deployment strategy, in which zone operators may start signing their
zones and expect zero effects for security-oblivious resolvers.  That
assumption is still accurate, but we appear to have failed to think of
one class of deployment: the security-oblivious resolver operator with
a security-aware resolver.

Yes, some of those people are already running into the issues, and yes
the recovery is happening.  But David was asking, "If we just start
signing now, will anything happen to people who don't care about
DNSSEC?"  The answer, one might be surprised to learn, is, "Yes,
although probably nothing unrecoverable."  That answer is not as
encouraging as, "No." 
 
> longer desirable now that DNSSEC is seeing deployment.  It much
> better to get the problems fixed and that requires noise.

Well, that's certainly true.

A

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 Aug 2008 10:36:47 -0400

A

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 17:42:11 +0200

=> it seems the three problems are more from EDNS0 than from
the DO=1 (and without EDNSO there is no DO bit :-) so DO is not
the real source of the problems, it is EDNS0 and how it can be
badly handled by not-compliant middle boxes & co.

So IMHO we should first fix the EDNS0 issues. I don't know
where is the idea to make EDNS0 support mandatory BTW...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Aug 2008 17:42:11 +0200

Regards

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Aug 2008 11:45:57 -0400

> Well, that's certainly true.

Here's a couple of leading questions (not directed at anyone in 
particular, just whoever knows the answers):

How stable is the content of the root zone?
(Really, really stable, I'd guess.)

If a signed root zone were installed on the root servers for some period 
of time, e.g. one refresh interval,
what would the effects be towards DNSSEC-configured caching, validating 
resolvers?

And, if the signed root zone were pulled after that period, and replaced 
with the unsigned version, how long
would the "good" aspects of the cached DNSSEC bits continue to be useful?

If the root zone were to "strobe" between signed and unsigned, what 
minimum duration of "signed", and what
maximum duration of "unsigned" would be likely to not cause operational 
problems for the aforementioned
DNSSEC-configured caching, validating resolvers?

I'm specifically pondering "short period signed, long period unsigned, 
repeat again and again...".

And what about DNSSEC-capable, but non-DNSSEC-configured caches, when 
used by DNSSEC-validating
clients? Does this differ from the first case (caching validating 
resolvers)?

As a cautious first step, does this make sense? Or even doing this one 
some subset of root servers or root server
instances?

It's kind of like dipping one's toe into bath water, to avoid getting 
too badly burned, while still testing the waters.

Just thinking outside the box, out loud...

Brian Dickson

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Aug 2008 11:45:57 -0400

Brian Dickson

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 09:47:38 -0700

Brian,

> (Really, really stable, I'd guess.)

On average, there are about 20-30 changes to the root zone per month  
(not including SOA serial number increments) with the trend  
increasing.  August has been a bit special (48 changes to date) due to  
the Kaminsky thing.

> If a signed root zone were installed on the root servers for some  
> period of time, e.g. one refresh interval,
> what would the effects be towards DNSSEC-configured caching,  
> validating resolvers?

If the validating caching name server operators configured the root  
trust anchor, they'd be able to validate chains of trust up to the  
root and be able to remove the trust anchors they've configured for  
signed TLDs.

> And, if the signed root zone were pulled after that period, and  
> replaced with the unsigned version, how long

Obviously depends on the validity period of the signatures and the TTL  
of the RRs.

> maximum duration of "unsigned" would be likely to not cause  
> operational problems for the aforementioned

I'm unclear how going from a signed root zone to an unsigned root zone  
would work.  If you've configured your root truFrom [email-masked]  Thu Aug 21 09:50:39 2008
From: David Conrad <[email-masked]>
To: Brian Dickson <[email-masked]>
Date: Thu, 21 Aug 2008 09:47:38 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

Brian,

> (Really, really stable, I'd guess.)

On average, there are about 20-30 changes to the root zone per month  
(not including SOA serial number increments) with the trend  
increasing.  August has been a bit special (48 changes to date) due to  
the Kaminsky thing.

> If a signed root zone were installed on the root servers for some  
> period of time, e.g. one refresh interval,
> what would the effects be towards DNSSEC-configured caching,  
> validating resolvers?

If the validating caching name server operators configured the root  
trust anchor, they'd be able to validate chains of trust up to the  
root and be able to remove the trust anchors they've configured for  
signed TLDs.

> And, if the signed root zone were pulled after that period, and  
> replaced with the unsigned version, how long

Obviously depends on the validity period of the signatures and the TTL  
of the RRs.

> maximum duration of "unsigned" would be likely to not cause  
> operational problems for the aforementioned

I'm unclear how going from a signed root zone to an unsigned root zone  
would work.  If you've configured your root trustst anchor and you get  
back a response that isn't signed, wouldn't that be treated as a  
validation failure?

> I'm specifically pondering "short period signed, long period  
> unsigned, repeat again and again...".

This would seem to maximize the chances for instability.

> And what about DNSSEC-capable, but non-DNSSEC-configured caches,  
> when used by DNSSEC-validating

Implementation decision, I suspect.

> As a cautious first step, does this make sense?

Doesn't appear to to me.

> Or even doing this one some subset of root servers or root server  
> instances?

I think it would likely be a mistake for the root servers to not be  
serving the same data.  It would probably be challenging to debug for  
most folks.

Now, I've always thought a separate root infrastructure that you had  
to opt in to would be a good way to go, but this quickly gets bogged  
down in extremely annoying (at least to me) layer 9 politics and I'll  
let someone else try to push that boulder up the mountain this time  
(Who me? Bitter?  Never).

Regards,
-drc

 anchor and you get  
back a response that isn't signed, wouldn't that be treated as a  
validation failure?

> I'm specifically pondering "short period signed, long period  
> unsigned, repeat again and again...".

This would seem to maximize the chances for instability.

> And what about DNSSEC-capable, but non-DNSSEC-configured caches,  
> when used by DNSSEC-validating

Implementation decision, I suspect.

> As a cautious first step, does this make sense?

Doesn't appear to to me.

> Or even doing this one some subset of root servers or root server  
> instances?

I think it would likely be a mistake for the root servers to not be  
serving the same data.  It would probably be challenging to debug for  
most folks.

Now, I've always thought a separate root infrastructure that you had  
to opt in to would be a good way to go, but this quickly gets bogged  
down in extremely annoying (at least to me) layer 9 politics and I'll  
let someone else try to push that boulder up the mountain this time  
(Who me? Bitter?  Never).

Regards,
-drc

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Aug 2008 13:32:02 -0400

> increasing.  August has been a bit special (48 changes to date) due to 

That's reasonably stable, I'd say.

> Obviously depends on the validity period of the signatures and the TTL 

For the root zone itself, it looks like the minimum is 86400, and lots 
of RRs in the zone have various longer TTLs, such as 518400 (for the 
authority records for "."), and 3600000 for A records for 
[a-m].root-servers.net.

> I'm unclear how going from a signed root zone to an unsigned root zoneFrom [email-masked]  Thu Aug 21 10:31:55 2008
Date: Thu, 21 Aug 2008 13:32:02 -0400
From: Brian Dickson <[email-masked]>
To: David Conrad <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

> increasing.  August has been a bit special (48 changes to date) due to 

That's reasonably stable, I'd say.

> Obviously depends on the validity period of the signatures and the TTL 

For the root zone itself, it looks like the minimum is 86400, and lots 
of RRs in the zone have various longer TTLs, such as 518400 (for the 
authority records for "."), and 3600000 for A records for 
[a-m].root-servers.net.

> I'm unclear how going from a signed root zone to an unsigned root zo 
> would work.  If you've configured your root trust anchor and you get 

Yes, it would. The question is, if there is a cached (validated) RRset 
for the whole root zone, would the result of an attempted refresh where 
the validation fails, result in the cached version still being kept and 
considered valid?

In which case, things that normally trigger SOA serial number changes, 
would ideally trigger the chain:
a) root zone content change
b) root zone SOA SN change
c) root zone gets signed
d) root zone SOA SN increments
e) serve signed root zone for TTL(refresh) * N + M (for some values N and M)
f) strip signatures from root zone, but don't change TTL (yes, I know, 
bad practice, danger, danger, high voltage!)
or
f) strip signatures from root zone, increment TTL, server for 
TTL(something else)

When time-out of TTL(something else) occurs, or when a change to the 
root zone content is needed (including any new DS on child zone(s)), go 
to (a).

> let someone else try to push that boulder up the mountain this time 

Perhaps this could be handled for volunteer clients, via extra rules on 
the front-end load balancers on one or more root zone instances.
It is also conceivable that load balancers could look at D0 and choose 
root server back-end instances based on whether or not DNSSEC versions 
of the root zone make sense.

Brian

ne 
> would work.  If you've configured your root trust anchor and you get 

Yes, it would. The question is, if there is a cached (validated) RRset 
for the whole root zone, would the result of an attempted refresh where 
the validation fails, result in the cached version still being kept and 
considered valid?

In which case, things that normally trigger SOA serial number changes, 
would ideally trigger the chain:
a) root zone content change
b) root zone SOA SN change
c) root zone gets signed
d) root zone SOA SN increments
e) serve signed root zone for TTL(refresh) * N + M (for some values N and M)
f) strip signatures from root zone, but don't change TTL (yes, I know, 
bad practice, danger, danger, high voltage!)
or
f) strip signatures from root zone, increment TTL, server for 
TTL(something else)

When time-out of TTL(something else) occurs, or when a change to the 
root zone content is needed (including any new DS on child zone(s)), go 
to (a).

> let someone else try to push that boulder up the mountain this time 

Perhaps this could be handled for volunteer clients, via extra rules on 
the front-end load balancers on one or more root zone instances.
It is also conceivable that load balancers could look at D0 and choose 
root server back-end instances based on whether or not DNSSEC versions 
of the root zone make sense.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Aug 2008 13:32:34 -0400 (EDT)

> intermediate zones with forged signature on child zone with forged

Oh I see. DNSSEC is broken because we cannot trust RSA, DSA, SHA256,
DiffieHellman, and perhaps eliptic curve.... Ok, let's go for your
solution that does not depend on any of these :P

> It means that there is no MitM attack on PODS.

Since I am not at "many places at once", how does PODS have no
mitm? My laptop stores info about 1 billion domain names? It's
first hop is a router you don't own.....

So your solution 1) scales, 2) no intermediaries whatsoever (on a packet
based internet no less), 3) does not use weak untrusted worldwide used
ciphers and public key systems.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 21 Aug 2008 13:32:34 -0400 (EDT)

Paul

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 11:10:26 -0700

Francis,

On Aug 21, 2008, at 8:42 AM, Francis Dupont wrote:
> it seems the three problems are more from EDNS0 than from

Yes and no.

Yes: if the root is signed, the existence of DO=1 in a request will  
trigger a response from the root that is substantively larger than if  
DO=0 (actual size difference obviously depends on a variety of factors  
that have not yet been determined). I'd agree this is mostly and EDNS0  
thing.

No: a DO=1 response will also contain different stuff (DNSSEC-related  
RRs).  Didn't mention this in my previous message, but it is may also  
be a consideration.

It would've been nice to limit the impact of signing the root to only  
those folks who had explicitly configured that they care about the  
root being signed, but that's not what was implemented.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 11:10:26 -0700

Francis,

Yes and no.

Regards,
-drc

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 21 Aug 2008 15:30:25 -0300

> be a DOS on the delegation.  I might try to demonstrate this by running

Even knowing that this will probably ruin our deprive of your company
for the following week I'll point you out to carefully read 4035
sections 3.1.4, 4 and 5.

If the child is signed the DS is mandatory with the referrals, if it's
not signed the NSEC that proofs it's inexistence is mandatory. So
you'll still need to make the RRSIG for the NSEC, and AFAIK you'll
need access to the parents private key to make it happen.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 21 Aug 2008 15:30:25 -0300

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 21 Aug 2008 15:43:23 -0300

On Thu, Aug 21, 2008 at 09:47:38AM -0700, David Conrad wrote:
...
> back a response that isn't signed, wouldn't that be treated as a  

Yes. This behavior is actually very clear, the dns tree will vanish
for theses validating caching resolvers.

You have the option of doing this smoothly by revoking the key (5011)
but it'll not bring any value to the deployment effort as you'll need
to re-anchor again.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 21 Aug 2008 15:43:23 -0300

Fred

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 08:21:40 +1000

> of time, e.g. From [email-masked]  Thu Aug 21 15:22:33 2008
Date: Fri, 22 Aug 2008 08:21:40 +1000

> of time, e.g. onone refresh interval,

	It won't work.

	You have no control over when the clients make queries.

	Mark

e refresh interval,
> Just thinking outside the box, out loud...

	It won't work.

	You have no control over when the clients make queries.

	Mark

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Aug 2008 07:50:08 +0900

> DiffieHellman, and perhaps eliptic curve....

That is certainly a valid argument.

However, it has nothingn to do with the MitM case above because
forged signature from a compromized zone is cryptographically valid.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 22 Aug 2008 07:50:08 +0900

Masataka Ohta

---

From: Matt Larson <[email-masked]>
Date: Thu, 21 Aug 2008 19:43:08 -0400

> let someone else try to push that boulder up the mountain this time  

I think a separate test infrastructure is a not just a "good way to
go" but absolutely essential to properly test DNSSEC in the root.  The
root zone is the most important one and any idea that we'd just sign
the root zone and hope for the best is madness and reckless.  The
discussion in this thread regarding DO makes this point better than I
ever could.

I don't believe the politics of a separate infrastructure in which to
deploy a signed root that would generate enough traffic to get a feel
for a signed root's impact are insurmountable and I am not only happy
to start pushing boulder, I've already begun.

Matt

---

From: Matt Larson <[email-masked]>
Date: Thu, 21 Aug 2008 19:43:08 -0400

Matt

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 16:53:31 -0700

*plonk*

---

From: David Conrad <[email-masked]>
Date: Thu, 21 Aug 2008 16:53:31 -0700

*plonk*

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 10:25:25 +1000

> discussion in this thread regarding DO makes this point better than I

	I'm not hoping for the best.  I'm confident that there won't
	be major issues.  Some lookups will slow down as due to the
	need to recover from broken bits of middleware.

	Is there any issue in David's list that SE or BR won't have
	encountered?  Are SE and BR falling off the Internet?

	Yes change is scary.

	Every machine that is setting DO is asserting that it can
	handle the responses the roots will generate.  These are
	the same sorts of response the servers for SE and BR are
	sending.

	The only real difference between SE/BR and the root is that
	everyone talks to the root.

	If one really wants to test larger responses one can hack
	the servers to add a EDNS option which pads out the UDP
	response to the advertised size.  It should be ignored by
	the receivers.  :-)

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Aug 2008 10:25:25 +1000

Yes change is scary.

---

From: Matt Larson <[email-masked]>
Date: Fri, 22 Aug 2008 09:41:21 -0400

> 	the same sorts of response the servers for SE and BR are

I'm not (just) concerned about individual resolvers.  I'm concerned
about the system as a whole, end to end.  We all know that .SE's
rollout wasn't completely smooth.  It wasn't IIS's fault: they did
everything they could for the variables under their control.  It was
the other stuff--such as the infamous SOHO router that didn't like
AD--that caused problems.

Now, there's no question that that SOHO router was broken and needs to
be fixed.  But magnify this situation to the entire Internet and
imagine the issues.  My point is that any course of action for DNSSEC
deployment in the root that doesn't include a lot of due diligence,
including large-scale testing, is reckless and irresponsible.  Signing
the root will be the single largest change ever undertaken to the root
zone and, arguably, to the DNS as a whole.

Please don't mistake any of my comments as a lack of support for
DNSSEC.  We do need to get the root signed, and I and the rest of
VeriSign are totally supportive.  VeriSign has had a root zone testbed
running for several months, in which we've been signing the root using
the same infrastructure aFrom [email-masked]  Fri Aug 22 06:42:14 2008
Date: Fri, 22 Aug 2008 09:41:21 -0400
From: Matt Larson <[email-masked]>
To: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

> 	the same sorts of response the servers for SE and BR are

I'm not (just) concerned about individual resolvers.  I'm concerned
about the system as a whole, end to end.  We all know that .SE's
rollout wasn't completely smooth.  It wasn't IIS's fault: they did
everything they could for the variables under their control.  It was
the other stuff--such as the infamous SOHO router that didn't like
AD--that caused problems.

Now, there's no question that that SOHO router was broken and needs to
be fixed.  But magnify this situation to the entire Internet and
imagine the issues.  My point is that any course of action for DNSSEC
deployment in the root that doesn't include a lot of due diligence,
including large-scale testing, is reckless and irresponsible.  Signing
the root will be the single largest change ever undertaken to the root
zone and, arguably, to the DNS as a whole.

Please don't mistake any of my comments as a lack of support for
DNSSEC.  We do need to get the root signed, and I and the rest of
VeriSign are totally supportive.  VeriSign has had a root zone testbed
running for several months, in which we've been signing the root using
the same infrastructure andnd policies used for our CA operations.  (See
http://webroot.verisignlabs.com.)  And in our role as root zone
editor, we're ready to sign the production root when asked.

What disturbs me is that I detect a disturbing drumbeat of "We must
sign the root now--now now NOW!" in discussions in various venues.
Such talk doesn't show prudence but panic.

Let's sign the root.  But let's do it diligently, always keeping in
mind how important the infrastructure is.

Matt

 policies used for our CA operations.  (See
http://webroot.verisignlabs.com.)  And in our role as root zone
editor, we're ready to sign the production root when asked.

What disturbs me is that I detect a disturbing drumbeat of "We must
sign the root now--now now NOW!" in discussions in various venues.
Such talk doesn't show prudence but panic.

Let's sign the root.  But let's do it diligently, always keeping in
mind how important the infrastructure is.

Matt

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 22 Aug 2008 11:07:57 -0300

Matt,

In general I agree with you that due diligence is required and I would
not expect anything different from that, remember how long it take us
to include AAAA glues at the root.

> AD--that caused problems.

This is news for me in the case of .SE. So far our deployment is
completely smooth, besides one SMTP implementation that doesn't
support EDNS0, we've seeing no complain from a very large Broad Band
installed in base of users.

> zone and, arguably, to the DNS as a whole.

We need that to document and push vendors of this products in the
right direction but I would stop here. We can't even argue that it's
not advisable to deploy new technology because there is a something
out there that don't support a specification almost 10 years old.

> the same infrastructure and policies used for our CA operations.  (See

You have all the baggage to take this and know that even if "every
one" is saying "sign now now now..." with all the techno-bureocracy
that we have at the root this is not something that would be feasible
in less than..... let me guess, 24 months from the time L9 issues are
sorted out.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 22 Aug 2008 11:07:57 -0300

Matt,

Fred

---

From: Dean Anderson <[email-masked]>
Date: Fri, 22 Aug 2008 10:23:16 -0400 (EDT)

> need access to the parents private key to make it happen.

Sigh. Above is precisely the sort of non-critical analysis that causes
these things to have so many problems.

It is manadatory in the _proper_ response.  Of course, the _forged_
response can have anything the bad guy wants.  If the bad guy decides
not to follow 4035 (gasp! we never thought the bad guys might not follow
RFCs!), and instead responds with a forged response that doesn't have
the DS RR, and the delegation and glue records are normally unsigned,
then the resolver will conclude the zone is unsigned, and place 
undeserved trust in the referral.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 22 Aug 2008 10:23:16 -0400 (EDT)

--Dean

---

From: Peter Koch <[email-masked]>
Date: Fri, 22 Aug 2008 16:38:36 +0200

> i answered this on namedroppers, where the thread actually belongs.

at the risk of splitting hairs, the three different proposals did not all
strive to change the protocol.  Also, this started out from the observation
that ANY queries might be routinely used where they probably shouldn't.
Short of deprectaing QTYPE=* altogether, giving guidance to application
programmers when and (most likely mostly) when not to use ANY might still
be a good thing.

QCLASS=* or ANY is already recommended against in RFC 1123, section 6.1.2.2
and penalized by RFC 1034, section 3.7.1 (must not set AA).

-Peter

---

From: Peter Koch <[email-masked]>
Date: Fri, 22 Aug 2008 16:38:36 +0200

-Peter

---

From: Dean Anderson <[email-masked]>
Date: Fri, 22 Aug 2008 10:50:35 -0400 (EDT)

Both of Ohta-san's points are entirely valid. 

On Ohta-san's first point: DJB is convinced that 1024bit RSA is
crackable with a botnet. And if 1024 isn't crackable now, it probably
will be shortly. So it is probably possible or soon will be possible to
crack keys and then forge many DNSSEC signatures, given enough
determination.  Using larger (2048bit) signatures creates more work to
verify signatures, and larger responses. [Note: increasing key size has
a corresponding impact on the crypto-overload DOS attack that I
(Anderson)  previously described, and also makes worse the forged query
DDOS attack that I described.]

On Ohta-san's second point: If the zone is compromised, (which means the
attacker has obtained the private key), then the attacker can construct
new signatures at will, and being a MitM, can inject these responses at
will, also.  The response that one gets (or seems to get) from a cache
or authority server is not necesarilly the response from an authority
server.  This can result in a number of problems for DNSSEC, and it is
the common factor in several different attacks described by Ohta-san and
myself.

		--Dean

On Thu, 21 Aug 2008, David Conrad wrote:

> > However, From [email-masked]  Fri Aug 22 07:50:40 2008
Date: Fri, 22 Aug 2008 10:50:35 -0400 (EDT)

Both of Ohta-san's points are entirely valid. 

On Ohta-san's first point: DJB is convinced that 1024bit RSA is
crackable with a botnet. And if 1024 isn't crackable now, it probably
will be shortly. So it is probably possible or soon will be possible to
crack keys and then forge many DNSSEC signatures, given enough
determination.  Using larger (2048bit) signatures creates more work to
verify signatures, and larger responses. [Note: increasing key size has
a corresponding impact on the crypto-overload DOS attack that I
(Anderson)  previously described, and also makes worse the forged query
DDOS attack that I described.]

On Ohta-san's second point: If the zone is compromised, (which means the
attacker has obtained the private key), then the attacker can construct
new signatures at will, and being a MitM, can inject these responses at
will, also.  The response that one gets (or seems to get) from a cache
or authority server is not necesarilly the response from an authority
server.  This can result in a number of problems for DNSSEC, and it is
the common factor in several different attacks described by Ohta-san and
myself.

		--Dean

On Thu, 21 Aug 2008, David Conrad wrote:

> > Howeverit has nothingn to do with the MitM case above because

, it has nothingn to do with the MitM case above because

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 10:52:46 -0700

> mind how important the infrastructure is.

To put it another way, if we create a new root that is the DNSSEC  
root, and it is capable of handling the same traffic that the current  
root handles, then we can do a staged transition to the new root.    
Not being a serious DNS geek, I'm sure that there are dragons waiting  
in this approach, but don't know what they are.

Nevertheless, this is the way to do a switchover if it's possible.    
That way people who care migrate and learn.   There is no flag day,  
and the people who are most willing to deal with trouble go first,  
saving trouble for the rest.  Eventually you can get to the point  
where you can say "look, we'reFrom [email-masked]  Fri Aug 22 10:53:02 2008
From: Ted Lemon <[email-masked]>
To: Matt Larson <[email-masked]>
Date: Fri, 22 Aug 2008 10:52:46 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

> mind how important the infrastructure is.

To put it another way, if we create a new root that is the DNSSEC  
root, and it is capable of handling the same traffic that the current  
root handles, then we can do a staged transition to the new root.    
Not being a serious DNS geek, I'm sure that there are dragons waiting  
in this approach, but don't know what they are.

Nevertheless, this is the way to do a switchover if it's possible.    
That way people who care migrate and learn.   There is no flag day,  
and the people who are most willing to deal with trouble go first,  
saving trouble for the rest.  Eventually you can get to the point  
where you can say "look, we' going to power the old infrastructure  
off in two years, please start migrating now."

But as I say, I'm not sure this is possible, at any layer.

re going to power the old infrastructure  
off in two years, please start migrating now."

But as I say, I'm not sure this is possible, at any layer.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 11:03:36 -0700

> these things to have so many problems.

Instead of making fun of other peoples' lack of critical thinking, you  
might want to take responsibility for your own thinking and let others  
take responsibility for theirs.

The problem with your reasoning is that the resolver is configured  
with a trust anchor, and the zone with the missing DS records is below  
that trust anchor.   So the resolver is required to validate the  
entire trust chain up to the trust anchor.   When it does this, it  
will discover a problem.

Suppose this is a host in .SE, and you have a trust anchor configured  
for .SE.   And the name you're looking up is avalon.fugue.se.   So you  
go to .SE, and it tells you that fugue is unsigned, because your  
attacker has forged the response.   The signature doesn't verify.   So  
you discard the response from the fake .SE, and try again.   If the  
attacker has complete control of your path, the lookup will neFrom [email-masked]  Fri Aug 22 11:04:27 2008
From: Ted Lemon <[email-masked]>
To: Dean Anderson <[email-masked]>
Date: Fri, 22 Aug 2008 11:03:36 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> these things to have so many problems.

Instead of making fun of other peoples' lack of critical thinking, you  
might want to take responsibility for your own thinking and let others  
take responsibility for theirs.

The problem with your reasoning is that the resolver is configured  
with a trust anchor, and the zone with the missing DS records is below  
that trust anchor.   So the resolver is required to validate the  
entire trust chain up to the trust anchor.   When it does this, it  
will discover a problem.

Suppose this is a host in .SE, and you have a trust anchor configured  
for .SE.   And the name you're looking up is avalon.fugue.se.   So you  
go to .SE, and it tells you that fugue is unsigned, because your  
attacker has forged the response.   The signature doesn't verify.   So  
you discard the response from the fake .SE, and try again.   If the  
attacker has complete control of your path, the lookup will nevever  
succeed, which is the desired result.   If the attacker is doing a  
scattershot attack, the next response that comes back will probably be  
the correct one, and you'll be back in business.

Suppose the response from .SE is correct, but the response from fugue  
is modified to remove the DS records.   .SE says fugue is signed.   So  
you discard the forged response from fugue, and the same thing happens.

Is there some avenue of attack I've missed here?   Do I fail to  
correctly understand how the protocol works in some subtle way that  
makes your argument correct, and mine mistaken?

r  
succeed, which is the desired result.   If the attacker is doing a  
scattershot attack, the next response that comes back will probably be  
the correct one, and you'll be back in business.

Suppose the response from .SE is correct, but the response from fugue  
is modified to remove the DS records.   .SE says fugue is signed.   So  
you discard the forged response from fugue, and the same thing happens.

Is there some avenue of attack I've missed here?   Do I fail to  
correctly understand how the protocol works in some subtle way that  
makes your argument correct, and mine mistaken?

---

From: David Conrad <[email-masked]>
Date: Fri, 22 Aug 2008 11:53:02 -0700

Ted,

On Aug 22, 2008, at 10:52 AM, Ted Lemon wrote:
> root, and it is capable of handling the same traffic that the  
> current root handles, then we can do a staged transition to the new  
> root.

Yes.  This has been proposed at least 3 different times that I'm aware  
of.  I've attached a PDF of the (unfinished and never submitted) draft  
Joao Damas and I were putting together when tried to take a crack at  
it back in July 2007 or so.  It is a bit dated as it was originally  
written before the IPv6 glue was added to the roots.  If there is  
interest in pursuing this, I could take a stab at another revision.

> Not being a serious DNS geek, I'm sure that there are dragons  
> waiting in this approach, but don't know what they are.

If you ensure the namespace and authorities are identical between the  
two infrastructures, there are no technical issues (at least that I've  
heard about).

In my experience, all the issues blocking forward motion on this have  
been political.  Specifically, one of the concerns has been that a  
separate infrastructure would in some way promote alternate root name  
spaces.  Another concern has been that unless the existing root server  
operators are chosen to provide the infrastructure (and some of those  
operatorsFrom [email-masked]  Fri Aug 22 11:53:04 2008
From: David Conrad <[email-masked]>
To: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 11:53:02 -0700
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] A different question
Sender: [email-masked]

Ted,

On Aug 22, 2008, at 10:52 AM, Ted Lemon wrote:
> root, and it is capable of handling the same traffic that the  
> current root handles, then we can do a staged transition to the new  
> root.

Yes.  This has been proposed at least 3 different times that I'm aware  
of.  I've attached a PDF of the (unfinished and never submitted) draft  
Joao Damas and I were putting together when tried to take a crack at  
it back in July 2007 or so.  It is a bit dated as it was originally  
written before the IPv6 glue was added to the roots.  If there is  
interest in pursuing this, I could take a stab at another revision.

> Not being a serious DNS geek, I'm sure that there are dragons  
> waiting in this approach, but don't know what they are.

If you ensure the namespace and authorities are identical between the  
two infrastructures, there are no technical issues (at least that I've  
heard about).

In my experience, all the issues blocking forward motion on this have  
been political.  Specifically, one of the concerns has been that a  
separate infrastructure would in some way promote alternate root name  
spaces.  Another concern has been that unless the existing root server  
operators are chosen to provide the infrastructure (and some of those  
operators h have indicated little interest in eating the cost of  
building yet another root DNS infrastructure), it would lessen the  
role of the root server operators.  And then you get into the more  
entertaining questions of who would be the signer of the separate  
infrastructure, who would be the distributor, and whether or not there  
would be a requirement for some agreement that defined the terms of  
the separate infrastructure (e.g., the conditions when the separate  
infrastructure would go away, the content and source of the name  
space, etc.) and if such an agreement were necessary, who it would be  
with.

The push back I got when trying to pursue this, being fundamentally  
non-technical, was quite frustrating.  Perhaps things have changed.

Regards,
-drc
(speaking for myself only, of course)

Content-Transfer-EncodOFTzAHlTNHYLLtr/5B/xf+z/0F/on+8f58
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 12:05:42 -0700

On Aug 22, 2008, at 11:53 AM, David Conrad wrote:
> Specifically, one of the concerns has been that a
> spaces.

It seems to me that the way to avoid this problem is for the  
incumbents to step up to the plate.

> Another concern has been that unless the existing root server
> operators have indicated little interest in eating the cost of
> role of the root server operators.

It seems to me that it would not be a terribly large challenge to run  
both roots on the same physical hardware, particularly for the root  
zone, where query volume is the only major technical issue.   Running  
two authoritative name server instances for root, one signed and one  
not, each answering on a different IP address, would not be all that  
hard.

I know that ANS will do this (in fact, you can just run different  
views for each IP address, rather than running two instances), and  
BIND will do this.   So it seems to me that the technology exists to  
solve this problem.   And perhaps now the will exists as well, or  
could be more easily cajoled into existence.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Aug 2008 12:05:42 -0700

---

From: Peter Koch <[email-masked]>
Date: Fri, 22 Aug 2008 23:37:47 +0200

> sessions going to the root.

assumed that it's reasonable to focus on referrals and NXDOMAIN responses
only, we'd usually see a DS and RRSIG(DS) or an NSEC plus RRSIG(NSEC) for
the former and two NSECs plus two RRSIG(NSEC) for the latter.
As per RFC 3226 (or 4035, section 6), the resolver sending DO is expected
to support at least 1220 octet responses.
Hard data on the advertized sizes for both DO and "EDNS, but not DO" would
be helpful.

> response to be dropped (for a variety of reasons).

Since, as Mark has pointed out, EDNS is used in many queries today, resulting
in referral responses larger than 512, this problem should have been faced
even without DNSSEC (or DO inparticular) involved.  Again, measurement data
showing the response size distributions for root name servers would be helpful.

> disallow DNS over TCP), those middle boxes will likely drop the larger  

Much of this has already been initiated by resolvers using EDNS (with sizes
> 512 octets) and either large referrals or AAAA RRs in priming responses.
The remaining risk is that DNSSEC responses would increase the size above
some critical value that doesn't regularily appear today.

> configured DNSSEC awareness) is that folks who are blissfully unaware  

DO can only signal from the resolver to the server, but for responses to
reach the resolver, anything in the way must also leave "larger packets"
alone.
One other issue around DO is that it was introduced to signal "understanding"
of DNSSEC as per RFC 2535.  The reaction of hypothetical 2535 only
resolvers to DNSSECbis responses is to be explored.  I vaguely remember that
we've had this discussion of versioning the DO "bit".

-Peter

---

From: Peter Koch <[email-masked]>
Date: Fri, 22 Aug 2008 23:37:47 +0200

-Peter

---

From: Dean Anderson <[email-masked]>
Date: Fri, 22 Aug 2008 18:27:01 -0400 (EDT)

> take responsibility for theirs.

I didn't make fun of anyone. The lack of critical analysis is no
laughing matter. 

None of the promoters seems to ever make an effort to consider how
things might break. There is far too much cheerleading and far too
little of how it could break.

> that trust anchor.   

There is no problem with my reasoning. Let me spell it out in more
detail:

The NSEC/NSEC3 issue has already been explained, but you didn't get the
implications.  The NSEC/NSEC3 opt-out records just signal that an
unsigned zone exists (or could exist)

>From RFC5155:

   The presence of Opt-Out in a zone means that some additions or
   delegations of names will not require changes to the NSEC3 RRs in a
   zone.

   o  When removing a delegation RRSet, if that delegation does not have
      a matching NSEC3 RR, then it was opted out.  In this case, nothing
      further needs to be done.

   o  When adding a delegation RRSet, if the "next closer" name of the
      delegation is covered by an existing Opt-Out NSEC3 RR, then the
      delegation MAY be added without modifying the NSEC3 RRs in the
      zone.

And the delegation records are unsigned; the resolver has no way to know
if they are correct;  The delegation was picked so that NSEC3 RR's
didn't change with the addition, and so the NSEC3 RRs verify correctly.
The bad guy just uses those NSEC3 records 'as-is'.

So one can use poison on a validating DNSSEC resolver to achieve false
resolution for any "new"  unsigned zone.  Put another way, the bad guy
can create new delegations under opt-out NSEC3 records.

One can also do this exact same thing on signed delegations provided you
have an earlier copy of a covering NSEC3 record signed with the same
key. [So operators have to rekey anytime they create a new delegation.]  

In fact, it seems that rekeying has to be done on any change, else the 
old NSEC records can be used to poison caches.

--  The assertion that validating DNSSEC caches can't be poisoned is 
false.  

-- This attack works on non-validating caches as well.

-- Also, non-validating DNSSEC-aware caches are trivially poisonable to
obtain a DOS attack.

-- Key rollover is a much more frequent issue than has been described by 
promotors of DNSSEC.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 22 Aug 2008 18:27:01 -0400 (EDT)

--Dean

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 22 Aug 2008 20:07:06 -0400

> and penalized by RFC 1034, section 3.7.1 (must not set AA).
QTYPE=* and QCLASS=* aren't really comparable, in terms of use cases and 
practical value.

Non-IN classes have pretty much become extinct since 1034/1035 were 
published, yet the range of RR types has grown significantly, thus 
making QTYPE=* potentially *more* useful than before (caseFrom [email-masked]  Fri Aug 22 17:07:06 2008
Date: Fri, 22 Aug 2008 20:07:06 -0400
From: Kevin Darcy <[email-masked]>
To: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
Sender: [email-masked]

> and penalized by RFC 1034, section 3.7.1 (must not set AA).
QTYPE=* and QCLASS=* aren't really comparable, in terms of use cases and 
practical value.

Non-IN classes have pretty much become extinct since 1034/1035 were 
published, yet the range of RR types has grown significantly, thus 
making QTYPE=* potentially *more* useful than before (ca in point, 
obtaining A and AAAA records in a single query).

There are still nagging problems concerning the cache 
consistency/coherency of QTYPE=* queries, though (e.g. if one of the 
RRsets expires before the others, is the whole QTYPE=* cached RRset 
"group" now to be considered invalid?), and those would need to be 
clarified or worked around before QTYPE=* could see regular use.

- Kevin

se in point, 
obtaining A and AAAA records in a single query).

There are still nagging problems concerning the cache 
consistency/coherency of QTYPE=* queries, though (e.g. if one of the 
RRsets expires before the others, is the whole QTYPE=* cached RRset 
"group" now to be considered invalid?), and those would need to be 
clarified or worked around before QTYPE=* could see regular use.

- Kevin

---

From: "Blacka, David" <[email-masked]>
Date: Fri, 22 Aug 2008 21:12:10 -0400

> little of how it could break.

If you had actually followed any of the discussions about DNSSEC over  
that last 13 years, you would know that this is false.  Thinking about  
how it could break is what the vast majority of work on this topic has  
been about.

> unsigned zone exists (or could exist)

Unsigned delegations, not zones.

>      delegation is cFrom [email-masked]  Fri Aug 22 18:12:15 2008
From: "Blacka, David" <[email-masked]>
To: "[email-masked] WG" <[email-masked]>
Date: Fri, 22 Aug 2008 21:12:10 -0400
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> little of how it could break.

If you had actually followed any of the discussions about DNSSEC over  
that last 13 years, you would know that this is false.  Thinking about  
how it could break is what the vast majority of work on this topic has  
been about.

> unsigned zone exists (or could exist)

Unsigned delegations, not zones.

>      delegation isovered by an existing Opt-Out NSEC3 RR, then the

In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are  
unsigned.  This is not a problem because, if the delegation is secure  
(i.e., has a DS RRset), the referred-to zone MUST have a DNSKEY that  
matches one of the DS records.  If not, then the response is  
considered bogus and (normally) thrown away.

> can create new delegations under opt-out NSEC3 records.

This fact is specifically mentioned in the Security Considerations  
section of RFC 5155, so, true.

> key. [So operators have to rekey anytime they create a new  

No, you don't.  This old NSEC3 (or NSEC) RRset isn't valid forever.

> old NSEC records can be used to poison caches.

No, this is why RRSIG records have expiration times.

It is well understood that you are vulnerable to a replay attack while  
the old RRSIGs are still valid.  Which argues for short signature  
durations, not rekeying.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

 covered by an existing Opt-Out NSEC3 RR, then the
> The bad guy just uses those NSEC3 records 'as-is'.

In all forms of DNSSEC (NSEC3 or NSEC) the delegation records are  
unsigned.  This is not a problem because, if the delegation is secure  
(i.e., has a DS RRset), the referred-to zone MUST have a DNSKEY that  
matches one of the DS records.  If not, then the response is  
considered bogus and (normally) thrown away.

> can create new delegations under opt-out NSEC3 records.

This fact is specifically mentioned in the Security Considerations  
section of RFC 5155, so, true.

> key. [So operators have to rekey anytime they create a new  

No, you don't.  This old NSEC3 (or NSEC) RRset isn't valid forever.

> old NSEC records can be used to poison caches.

No, this is why RRSIG records have expiration times.

It is well understood that you are vulnerable to a replay attack while  
the old RRSIGs are still valid.  Which argues for short signature  
durations, not rekeying.

--
David Blacka                          <[email-masked]>
Sr. Engineer                   Platform Product Development

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Aug 2008 12:56:05 +1000

> we've had this discussion of versioning the DO "bit".

	It's not a issue with BIND 9.1 or BIND 9.2.  They will just
	ignore the DNSSEC-4035 records.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Sat, 23 Aug 2008 12:56:05 +1000

Mark

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 23 Aug 2008 17:43:33 +0900

Dean Anderson wrote:

> [Note: increasing key size has

It should be noted that new factoring algorithm may make even
64KB keys crackable.

Elliptic cryptography, which is less seriously attacked, is
even less secure.

> will, also.

Compromized zone almost automatically means compromized authoritative
servers.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 23 Aug 2008 17:43:33 +0900

Masataka Ohta

---

From: Peter Koch <[email-masked]>
Date: Sat, 23 Aug 2008 13:09:32 +0200

> two infrastructures, there are no technical issues (at least that I've  

{diving into a detail - the ARPA zone shares its NS RRSet with the root zone
 (only one exception), which needs special consideration when you change the
 root NS RRSet or the corresponding A/AAAA records.}

{Another detail: the root zone at ns.iana.org announces two root name
 servers: ns.iana.org and pch-test.iana.org; however, a resolver can't
 successfully be primed from these sources because a respnse to ". NS"
 lacks the addresses of both servers -- which is strange because they also
 serve ARPA in that version and should only therefore have glue records in
 the root zoen (better yet, they'd be stealth servers for iana.org).}

It looks like part of your propsal has been overtaken by events given that
the AAAA introduction for the root name servers went smoothly. Of course that
alone doesn't guarantee the next change will work as well.

How to avoid leakage between the plain and the DNSSEC signed root?
What is the back out strategy?
Actually, there is some practical experience with this from the "AAAA in the root"
experiment, that indeed used a modified "hints" file.

Most importantly: How do you make sure thatFrom [email-masked]  Sat Aug 23 04:10:54 2008
Date: Sat, 23 Aug 2008 13:09:32 +0200
From: Peter Koch <[email-masked]>
To: IETF DNSOP WG <[email-masked]>
Subject: [DNSOP] signed root on a separate infrastructure [Re: A different
	question]
Sender: [email-masked]

> two infrastructures, there are no technical issues (at least that I've  

{diving into a detail - the ARPA zone shares its NS RRSet with the root zone
 (only one exception), which needs special consideration when you change the
 root NS RRSet or the corresponding A/AAAA records.}

{Another detail: the root zone at ns.iana.org announces two root name
 servers: ns.iana.org and pch-test.iana.org; however, a resolver can't
 successfully be primed from these sources because a respnse to ". NS"
 lacks the addresses of both servers -- which is strange because they also
 serve ARPA in that version and should only therefore have glue records in
 the root zoen (better yet, they'd be stealth servers for iana.org).}

It looks like part of your propsal has been overtaken by events given that
the AAAA introduction for the root name servers went smoothly. Of course that
alone doesn't guarantee the next change will work as well.

How to avoid leakage between the plain and the DNSSEC signed root?
What is the back out strategy?
Actually, there is some practical experience with this from the "AAAA in the root"
experiment, that indeed used a modified "hints" file.

Most importantly: How do you make sure th the most representative subset
of resolvers do actually opt-in?  Since we do not have good models for the
swarm behaviour of the resolver population, both in terms of software
anomalies and query patterns, it is hard to tell that or when you have
reached enough breadth (diversity) in your user community.

Also, it is reasonable to assume that

o the participants would be on the informed side, using well known and
  recent software
o for anybody with an "interesting" query volume or pattern, it would
  most likely mean switching a production system

> separate infrastructure would in some way promote alternate root name  

And I'd say this is a serious concern.  Also, an experiment is much different
from a migration for technical/operational and layer 9 reasons.  The operational
beeing that you'd essentially have to move all the DNSSEC unaware resolvers,
as well - at least in the long run.

-Peter (no hats)

at the most representative subset
of resolvers do actually opt-in?  Since we do not have good models for the
swarm behaviour of the resolver population, both in terms of software
anomalies and query patterns, it is hard to tell that or when you have
reached enough breadth (diversity) in your user community.

Also, it is reasonable to assume that

o the participants would be on the informed side, using well known and
  recent software
o for anybody with an "interesting" query volume or pattern, it would
  most likely mean switching a production system

> separate infrastructure would in some way promote alternate root name  

And I'd say this is a serious concern.  Also, an experiment is much different
from a migration for technical/operational and layer 9 reasons.  The operational
beeing that you'd essentially have to move all the DNSSEC unaware resolvers,
as well - at least in the long run.

-Peter (no hats)

---

From: "Larson, Matt" <[email-masked]>
Date: Sat, 23 Aug 2008 08:52:51 -0400

> section of RFC 5155, so, true.

And I should note that in the case of .com and .net zones signed with
NSEC3, rather than going to the trouble of spoofing a domain into
existence, a bad guy with ~USD 10 could just buy the domain.

Matt

---

From: "Larson, Matt" <[email-masked]>
Date: Sat, 23 Aug 2008 08:52:51 -0400

Matt

---

From: Jim Reid <[email-masked]>
Date: Sat, 23 Aug 2008 14:01:04 +0100

> existence, a bad guy with ~USD 10 could just buy the domain.

Or give it back with 5 days and get the 10 bucks refunded. :-)
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Jim Reid <[email-masked]>
Date: Sat, 23 Aug 2008 14:01:04 +0100

---

From: Dean Anderson <[email-masked]>
Date: Sun, 24 Aug 2008 18:18:47 -0400 (EDT)

> how it could break is what the vast majority of work on this topic has

I have paid attention to many of these discussions, and have recently
reviewed some of the ones I didn't pay attention to. And indeed, there
hasn't been a thorough analysis. Instead, critics (such as myself and
Dr. Bernstein, perhaps others) were silenced. It appears that only
Bernstein and myself were noisy about being silenced. Most people would
just go away quietly, as many people expected myself and Bernstein to
do, and some have even told me as much.

Evidence of the lack of critical analysis is found in the several
serious flaws identified so far.  More evidence of a lack of analysis is
found in the repeated cycles of going back to the drawing board and then
reporting "I think we have it this time", only to 'not have it', still.
The tri fecta is found in the acts silencing critics. These acts
conclusively discredit the claims that DNSSEC people were genuinely
concerned with critical analysis of problems. Yet, despite all these
contrary facts, Blacka still asserts DNSSEC advocates were somehow
genuinely interested in solving security problem, rather than some other
objective.  There seems to be an irreconcilable difference of opinion
here. Perhaps another example might shed light on the credibility of
their approach:

I recently read David Blacka's blog entry on Anycast, where Blacka
asserted that Anycast had to be proven UNstable before anyone shoFrom [email-masked]  Sun Aug 24 15:18:58 2008
Date: Sun, 24 Aug 2008 18:18:47 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: "Blacka, David" <[email-masked]>
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> how it could break is what the vast majority of work on this topic has

I have paid attention to many of these discussions, and have recently
reviewed some of the ones I didn't pay attention to. And indeed, there
hasn't been a thorough analysis. Instead, critics (such as myself and
Dr. Bernstein, perhaps others) were silenced. It appears that only
Bernstein and myself were noisy about being silenced. Most people would
just go away quietly, as many people expected myself and Bernstein to
do, and some have even told me as much.

Evidence of the lack of critical analysis is found in the several
serious flaws identified so far.  More evidence of a lack of analysis is
found in the repeated cycles of going back to the drawing board and then
reporting "I think we have it this time", only to 'not have it', still.
The tri fecta is found in the acts silencing critics. These acts
conclusively discredit the claims that DNSSEC people were genuinely
concerned with critical analysis of problems. Yet, despite all these
contrary facts, Blacka still asserts DNSSEC advocates were somehow
genuinely interested in solving security problem, rather than some other
objective.  There seems to be an irreconcilable difference of opinion
here. Perhaps another example might shed light on the credibility of
their approach:

I recently read David Blacka's blog entry on Anycast, where Blacka
asserted that Anycast had to be proven UNstable before anyone suld
consider stability questions. Blacka suggests that non-root operators
had no experience or data to prove these things unstable--which is true
and root operators aren't sharing their data.  Hold on!  Why should
non-root operators have prove Anycast root operations are unstable using
root-operations data?  Why should anyone ASSUME a new, untested service
will be stable?  I think most people would agree that high stability
operations must have some proof of stability BEFORE deployment of a new
service.  And once again, we see the same 'assume stability and deploy
without extensive testing' as before.

And after they asserted that TCP is stable for Anycast, they now want to
deprecate TCP for DNS.  (RFC 1546, analysis, and testing show TCP
Anycast isn't stable)

This is a lesson to be applied to DNSSEC deployment plans as well.
"Deploy untested and hope for the best" is really not a credible
operations strategy.

> > And the delegation records are unsigned; the resolver has no way to
> > know if they are correct;  The delegation was picked so that NSEC3
> > RR's didn't change with the addition, and so the NSEC3 RRs verify
> > correctly. The bad guy just uses those NSEC3 records 'as-is'.
> 
> unsigned.  

I noticed.

> This is not a problem because, if the delegation is secure  

It is only 'not a problem' in the ideal case where no one is trying to
trick the resolver. But when one is trying to trick the resolver, they
can succeed as I described.  This is just exactly what is meant by
'non-critcial analysis'. You only considered the ideal case.

> > One can also do this exact same thing on signed delegations provided
> > you have an earlier copy of a covering NSEC3 record signed with the
> > same key. [So operators have to rekey anytime they create a new
> > delegation.]
> 

The old record valid until its signature expires. As I noted, to avoid
the attack, one must rekey everytime a change is made.

> the old RRSIGs are still valid.  Which argues for short signature  

Ok.  But when you resign using arbitrary data controlled by the
attacker, the private key can be obtained. [There is a crypto attack on
rekeying] OOPS!!.  Rekeying is out of the question for, say, .com, .net,
etc.  I guess you didn't know that.

		--Dean

hould
consider stability questions. Blacka suggests that non-root operators
had no experience or data to prove these things unstable--which is true
and root operators aren't sharing their data.  Hold on!  Why should
non-root operators have prove Anycast root operations are unstable using
root-operations data?  Why should anyone ASSUME a new, untested service
will be stable?  I think most people would agree that high stability
operations must have some proof of stability BEFORE deployment of a new
service.  And once again, we see the same 'assume stability and deploy
without extensive testing' as before.

And after they asserted that TCP is stable for Anycast, they now want to
deprecate TCP for DNS.  (RFC 1546, analysis, and testing show TCP
Anycast isn't stable)

This is a lesson to be applied to DNSSEC deployment plans as well.
"Deploy untested and hope for the best" is really not a credible
operations strategy.

> > And the delegation records are unsigned; the resolver has no way to
> > know if they are correct;  The delegation was picked so that NSEC3
> > RR's didn't change with the addition, and so the NSEC3 RRs verify
> > correctly. The bad guy just uses those NSEC3 records 'as-is'.
> 
> unsigned.  

I noticed.

> This is not a problem because, if the delegation is secure  

It is only 'not a problem' in the ideal case where no one is trying to
trick the resolver. But when one is trying to trick the resolver, they
can succeed as I described.  This is just exactly what is meant by
'non-critcial analysis'. You only considered the ideal case.

> > One can also do this exact same thing on signed delegations provided
> > you have an earlier copy of a covering NSEC3 record signed with the
> > same key. [So operators have to rekey anytime they create a new
> > delegation.]
> 

The old record valid until its signature expires. As I noted, to avoid
the attack, one must rekey everytime a change is made.

> the old RRSIGs are still valid.  Which argues for short signature  

Ok.  But when you resign using arbitrary data controlled by the
attacker, the private key can be obtained. [There is a crypto attack on
rekeying] OOPS!!.  Rekeying is out of the question for, say, .com, .net,
etc.  I guess you didn't know that.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 24 Aug 2008 18:33:36 -0400 (EDT)

> etc.  I guess you didn't know that.

Correction: The above should say there is a crypto attack on re-SIGNing.  
ReKEYing is fine. Apologies for the confusion I just created.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 24 Aug 2008 18:33:36 -0400 (EDT)

--Dean

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Aug 2008 19:05:50 -0400

> ReKEYing is fine. Apologies for the confusion I just created.

You say there is a crypto attack on re-signing.

One using arbitrary data provided by the attacker - what is the 
"arbitrary" data, as opposed to some other kind of data?

(e.g. If the data being signed were limited to valid public key data 
that might, for example, be possible to itself be validated before signing)?

Can you provide a reference to back up this assertion?

Thanks,

Brian

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Aug 2008 19:05:50 -0400

Thanks,

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Aug 2008 21:30:17 +0900

> You say there is a crypto attack on re-signing.

Do you know something about recent re-signing attack against Red
Hat Linux distributions?

> "arbitrary" data, as opposed to some other kind of data?

"Arbitrary" forged data with forged, but, seemingly valid, signature
on them, which is possible by attackers, including but not limited to
those who knows the private key, having access to signature generation
mechanisms.

DNSSEC is not cryptographically secure against MitM attacks on
intermediate entities of zones.

PKI is not cryptographically secure against MitM attacks on
intermediate entities of CAs.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Aug 2008 21:30:17 +0900

Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Aug 2008 21:56:58 +0900

Dean Anderson wrote:

> asserted that Anycast had to be proven UNstable before anyone should
> and root operators aren't sharing their data.

As the, seemingly, only expert on anycast in the world, anycast
is stable as long as unicast routing is stable.

It should be noted that unicast TCP is unstable if unicast routing
is unstable.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 25 Aug 2008 21:56:58 +0900

Masataka Ohta

---

From: Ralf Weber <[email-masked]>
Date: Mon, 25 Aug 2008 16:51:21 +0200

Moin!

> is stable as long as unicast routing is stable.
While that is true, there are situations where unicast reachabilty is  
working but anycast reachabilty is not.

> It should be noted that unicast TCP is unstable if unicast routing
Yes, but TCP usually adapts to the problem while anycast can't, as it  
may reach another target. As someone who has deployed anycast DNS  
within a carrier network there are some things to consider , e.g don't  
put anycast routes in fast converging routing protocols and be careful  
with multi links for similar destinations. But if you follow the rules  
it can be deployed and also works with tcp transport for DNS....at  
least for me.

So long
-Ralf
---
Ralf Weber

---

From: Ralf Weber <[email-masked]>
Date: Mon, 25 Aug 2008 16:51:21 +0200

Moin!

So long
-Ralf
---
Ralf Weber

---

From: Joe Abley <[email-masked]>
Date: Mon, 25 Aug 2008 12:46:32 -0400

On 19 Aug 2008, at 22:32, Dean Anderson wrote:

> TCP doesn't work with Anycast, as was stated in RFC1546.

I just returned from a week with no Internet, living in a tent on the  
Bruce Peninsular, and the lack of connectivity seems to have resulted  
in a temporal anomaly! Threads that were long since buried with the  
hard-tamped dirt of PR actions and BCP publications live once more!

I conclude that disconnecting from the Internet for a week has serious  
consequences, and strongly advise against anybody else here trying  
such a foolhardy experiment.

Joe

---

From: Joe Abley <[email-masked]>
Date: Mon, 25 Aug 2008 12:46:32 -0400

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Aug 2008 09:15:22 +0900

Ralf Weber wrote:

> may reach another target.

That unicast TCP fails in unusual cases means we, anyway, need
retry mechanisms, which helps anycast TCP.

> As someone who has deployed anycast DNS  

Could you elaborate on how fast converging routing protocols can
be a problem?

Anycast TCP fails only when route changes upon a link failure or
recovery. So, anycast TCP should fail regardless of how quickly
or slowly the route changes, shouldn't it?

I can understand that, with multi links, packet-wise load balancers
disturbing packet ordering within TCP streams are, of course, harmful
to anycast TCP.

							Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 26 Aug 2008 09:15:22 +0900

Masataka Ohta

---

From: Ralf Weber <[email-masked]>
Date: Tue, 26 Aug 2008 08:58:22 +0200

Moin!

> Could you elaborate on how fast converging routing protocols can
Well I believe it was in our case as we did observe some strange  
behaviour when starting to test with anycast DNS.

> or slowly the route changes, shouldn't it?
A link failure always is the root of all evil, but we observed  
different behaviour of anycast and unicast tcp with it. Let me tell  
you what we observed. In one of our initial test setups the anycast  
addresses where announced with our internal routing protocol on the  
router that connected the anycast server. Now the link had duplex  
mismatch between the router and the server and thus the link flipped  
several times per second. While we could reach the box on it's unicast  
address with tcp (ssh) and got some answers over udp, we couldn't do a  
tcp connection to the anycast address on it no matter how hard we tried.

We then changed the design so that the server itself announces the  
anycast addresses via an external routing protcol (BGP) and didn't  
have the problem above even on a deliberately duplex mismatched link.

So long
-Ralf
---
Ralf Weber
Platform Infrastructure Manager
Colt Telecom GmbH
Herriotstrasse 4
60528 FrankFrom [email-masked]  Mon Aug 25 23:58:29 2008
From: Ralf Weber <[email-masked]>
To: Masataka Ohta <[email-masked]>
Date: Tue, 26 Aug 2008 08:58:22 +0200
Cc: "Blacka, David" <[email-masked]>, "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

Moin!

> Could you elaborate on how fast converging routing protocols can
Well I believe it was in our case as we did observe some strange  
behaviour when starting to test with anycast DNS.

> or slowly the route changes, shouldn't it?
A link failure always is the root of all evil, but we observed  
different behaviour of anycast and unicast tcp with it. Let me tell  
you what we observed. In one of our initial test setups the anycast  
addresses where announced with our internal routing protocol on the  
router that connected the anycast server. Now the link had duplex  
mismatch between the router and the server and thus the link flipped  
several times per second. While we could reach the box on it's unicast  
address with tcp (ssh) and got some answers over udp, we couldn't do a  
tcp connection to the anycast address on it no matter how hard we tried.

We then changed the design so that the server itself announces the  
anycast addresses via an external routing protcol (BGP) and didn't  
have the problem above even on a deliberately duplex mismatched link.

So long
-Ralf
---
Ralf Weber
60528 Frankfufurt

rt
Germany

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Aug 2008 14:14:36 +0200

On Thu, Aug 21, 2008 at 01:17:21AM +0200,
 Francis Dupont <[email-masked]> wrote 
 a message of 14 lines which said:

> it seems T/TCP is dead because of some security issues.

Correct (RFC 4614, section 5) but, unfortunately, these issues were
apparently never properly documented (no "T/TCP deprecated" RFC) and
it is hard to find a reference to a description of these security
problems.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Aug 2008 14:14:36 +0200

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Aug 2008 14:41:55 +0200

> it is hard to find a reference to a description of these security

I think it's CERT VU#464113, a TCP implementation problem.  Fixing
that (or rather, stopping its use) had the unfortunate side effect of
killing TCP outright.  This wasn't considered to be a problem at that
time because API support for T/TCP just wasn't there (and certainly
the situation hasn't changed favorably to T/TCP since then).

Anyway, I think it's possible to run DNS over TCP in a
mostly-stateless fashion if only one wishes to do so.  Only the
initiator needs to keep state:

  I: sends SYN

  R: sends SYN+ACK with cookie (no state is created)
  
  I: sends ACK, with query   -- or --    I: sends ACK
                                         I: sends query

                         -- but not --   I: sends ACK
                                         I: sends length of query
                                         I: sends query

              (preventing this requires support from the initiator)

  R: validates cookie, sends ACK with response
  R: ... continues to send response (possibly ignoring the window size,
     which requires cooperation from the initiator)
  R: sends FIN, kill the socket (no state has been created so far)

  I: receives response and the FIN, kills the socket

There's no conceptual problem with running TCP over DNS.  The problem
is that at least one implementor claims not to support TCP well enough
to take the load if it is overused, not that TCP is unsuitable for
short-term connections (the HTTP experience kind of refutes that
anyway).

---

From: Florian Weimer <[email-masked]>
Date: Tue, 26 Aug 2008 14:41:55 +0200

I: sends SYN

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Aug 2008 15:21:07 +0200

On Tue, Aug 26, 2008 at 02:41:55PM +0200,
 Florian Weimer <[email-masked]> wrote 
 a message of 50 lines which said:

> I think it's CERT VU#464113,

Other references I've found on T/TCP (in)security:

http://www.mid-way.org/doc/ttcp-sec.txt
http://seclists.org/bugtraq/1998/Apr/0034.html
http://ttcplinux.sourceforge.net/theses/ETTCP.pdf
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Aug 2008 15:21:07 +0200

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 14:22:43 -0400 (EDT)

On Mon, 25 Aug 2008, Masataka Ohta wrote:

> > consider stability questions. Blacka suggests that non-root
> > operators had no experience or data to prove these things
> > unstable--which is true and root operators aren't sharing their
> > data.
> 
> As the, seemingly, only expert on anycast in the world, anycast is
> stable as long as unicast routing is stable.
> 
> It should be noted that unicast TCP is unstable if unicast routing is
> unstable.

That is not so.  'Unicast routing' is, by definition, "stable" if
routing complies with RFC1812 and delivers every unicast packet to the
correct unicast host.  RFC1812 allows load-splitting, and load-splitting
was the first obvious flaw in the 'anycast stable if unicast routing
stable' assertion, many years ago.  Some people have asserted, without
justification, that load-splitting is somehow pathological.  However,
load-splitting is not necessary to observe Anycast instablity. 

Most routers expire FIB entries every 60 seconds. All routers eventually
expire FIB entries, usually in a similar timeframe. When the FIB entry
is replaced, a different, equal cost path may be installed. This FIB
could come from the interior (e.g. ospf, is-is) or the exterior(e.g.
BGP).  The unicast routing system is stable because RFC1812 is
fullfulled and all unicast packets are delivered to the correct unicast
host.  However, subsequent Anycast pFrom [email-masked]  Tue Aug 26 11:22:57 2008
Date: Tue, 26 Aug 2008 14:22:43 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: "Blacka, David" <[email-masked]>, "[email-masked] WG" <[email-masked]>
Subject: [DNSOP] Anycast TCP DNS stability was Re: Cache poisoning on DNSSEC
Sender: [email-masked]

On Mon, 25 Aug 2008, Masataka Ohta wrote:

> > consider stability questions. Blacka suggests that non-root
> > operators had no experience or data to prove these things
> > unstable--which is true and root operators aren't sharing their
> > data.
> 
> As the, seemingly, only expert on anycast in the world, anycast is
> stable as long as unicast routing is stable.
> 
> It should be noted that unicast TCP is unstable if unicast routing is
> unstable.

That is not so.  'Unicast routing' is, by definition, "stable" if
routing complies with RFC1812 and delivers every unicast packet to the
correct unicast host.  RFC1812 allows load-splitting, and load-splitting
was the first obvious flaw in the 'anycast stable if unicast routing
stable' assertion, many years ago.  Some people have asserted, without
justification, that load-splitting is somehow pathological.  However,
load-splitting is not necessary to observe Anycast instablity. 

Most routers expire FIB entries every 60 seconds. All routers eventually
expire FIB entries, usually in a similar timeframe. When the FIB entry
is replaced, a different, equal cost path may be installed. This FIB
could come from the interior (e.g. ospf, is-is) or the exterior(e.g.
BGP).  The unicast routing system is stable because RFC1812 is
fullfulled and all unicast packets are delivered to the correct unicast
host.  However, subsequent Anycastackets can be delivered to different
Anycast hosts; Anycast TCP is not stable.  This instability was
explicitly stated by RFC1546.  One need only send packets delayed by 60
seconds to see Anycast instability.  TCP can delay packets for a long
time. Keep-alives are sent every 2 minutes, well outside the FIB
expiration time.  This behavior has been experimentally observed.

		--Dean

 packets can be delivered to different
Anycast hosts; Anycast TCP is not stable.  This instability was
explicitly stated by RFC1546.  One need only send packets delayed by 60
seconds to see Anycast instability.  TCP can delay packets for a long
time. Keep-alives are sent every 2 minutes, well outside the FIB
expiration time.  This behavior has been experimentally observed.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 14:44:08 -0400 (EDT)

> "arbitrary" data, as opposed to some other kind of data?

I don't think I can give the exact correct mathematics without using a
book--and I don't have my crypto library right now--so I'll try to
armwave a bit:

Basically, if the attacker can pick a known-plaintext that corresponds
to a large-prime, they can use the result and the public key to obtain
the private key. This is consequence of modular arithmetic.  I'm not
entirely certain from memory if the plaintext has to be prime or if it
can be a multiple of a prime.  

> Can you provide a reference to back up this assertion?

I think there is a description of this in Schier's book, or other books
that describe security and insecurity of PKI depending on modular
arithmetic, like RSA.  If you still can't find it, let me know and I'll
send you detailed reference tomorrow.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 14:44:08 -0400 (EDT)

--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 15:02:07 -0400 (EDT)

> may reach another target. 

Large UDP packets (think EDNSO DNSSEC as a good example of large UDP
packets almost certain to be fragmented) suffer the same problem, as
they can be fragmented by PMTU discovery. The server (operating system)
has to maintain UDP state for PMTUD to work.  If the ICMP fragmentation
needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are
fatal to the UDP transaction.

> As someone who has deployed anycast DNS within a carrier network there
> are some things to consider , e.g don't put anycast routes in fast
> converging routing protocols and be careful with multi links for
> similar destinations.

FIB entries change at every hop. The more hops away, the more often the 
paths can change.   What works close by, might not work far away, and 
vice versa. 

> But if you follow the rules it can be deployed and also works with tcp
> transport for DNS....at least for me.

But the question is not whether your DNS works for you; The question is
whether it works for everyone else.  While you may be satisified with
your own DNS operations, you may not care if they work for everyone.
Different requirements apply to Root and TLD services. Everyone,
everywhere has to be able to use Root and TLD DNS services reliably.

This is precisely the 'deploy and hope for the best' attitude at its
worst: "It worked for me in a very limited scenario, and I don't From [email-masked]  Tue Aug 26 12:03:22 2008
Date: Tue, 26 Aug 2008 15:02:07 -0400 (EDT)
From: Dean Anderson <[email-masked]>
To: Ralf Weber <[email-masked]>
Cc: "Blacka, David" <[email-masked]>, "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> may reach another target. 

Large UDP packets (think EDNSO DNSSEC as a good example of large UDP
packets almost certain to be fragmented) suffer the same problem, as
they can be fragmented by PMTU discovery. The server (operating system)
has to maintain UDP state for PMTUD to work.  If the ICMP fragmentation
needed is lost due to Anycast, PMTUD will fail. Lost UDP fragments are
fatal to the UDP transaction.

> As someone who has deployed anycast DNS within a carrier network there
> are some things to consider , e.g don't put anycast routes in fast
> converging routing protocols and be careful with multi links for
> similar destinations.

FIB entries change at every hop. The more hops away, the more often the 
paths can change.   What works close by, might not work far away, and 
vice versa. 

> But if you follow the rules it can be deployed and also works with tcp
> transport for DNS....at least for me.

But the question is not whether your DNS works for you; The question is
whether it works for everyone else.  While you may be satisified with
your own DNS operations, you may not care if they work for everyone.
Different requirements apply to Root and TLD services. Everyone,
everywhere has to be able to use Root and TLD DNS services reliably.

This is precisely the 'deploy and hope for the best' attitude at its
worst: "It worked for me in a very limited scenario, and I don'worry
about theory or about what works everyone".

		--Dean

t worry
about theory or about what works everyone".

		--Dean

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 26 Aug 2008 15:08:39 -0400

> book--and I don't have my crypto library right now--so I'll try to

If you're claiming that, after 10 years and review unto death, people
with significant profile in the crypto community got the math wrong, I
don't think you're going to get a warm reception.  I think you need to
demonstrate that there is an actual problem.  Certainly, we'll need an
argument somewhat stronger than, "The math could be wrong somewhere."

I seem to remember you were going to spend this week producing a
demonstration of an actual attack.  It's early days yet; DNSSEC is not
widely deployed.  If you have such an attack, it would be a really
significant service to all DNS operators to demonstrate it.  To be
clear, I'm not being even a little bit sarcastic: if you have such an
attack, and it's not something that is already well-understood about
the protocol, I believe that everyone wants to see it as soon as
possible.  I encourage you to perform your demonstration.

A

-- 
Andrew Sullivan
[email-masked]
+1 503 667 4564 x104
http://www.commandprompt.com/
_______________________________________________
DNSOP mailFrom [email-masked]  Tue Aug 26 12:08:54 2008
Date: Tue, 26 Aug 2008 15:08:39 -0400
From: Andrew Sullivan <[email-masked]>
To: [email-masked]
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> book--and I don't have my crypto library right now--so I'll try to

If you're claiming that, after 10 years and review unto death, people
with significant profile in the crypto community got the math wrong, I
don't think you're going to get a warm reception.  I think you need to
demonstrate that there is an actual problem.  Certainly, we'll need an
argument somewhat stronger than, "The math could be wrong somewhere."

I seem to remember you were going to spend this week producing a
demonstration of an actual attack.  It's early days yet; DNSSEC is not
widely deployed.  If you have such an attack, it would be a really
significant service to all DNS operators to demonstrate it.  To be
clear, I'm not being even a little bit sarcastic: if you have such an
attack, and it's not something that is already well-understood about
the protocol, I believe that everyone wants to see it as soon as
possible.  I encourage you to perform your demonstration.

A

DNSOP mailining list

g list
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 26 Aug 2008 12:53:32 -0700

Peter,

On Aug 23, 2008, at 4:09 AM, Peter Koch wrote:
> the AAAA introduction for the root name servers went smoothly.

Yep.  As I mentioned, it was unfinished, unpublished, and outdated.

> How to avoid leakage between the plain and the DNSSEC signed root?

What sort of leakage are you concerned about?

> What is the back out strategy?

I would presume that it would be made very clear that the separate  
infrastructure would simply be terminated at some point in the future  
following the deployment of the live signed root.

> Most importantly: How do you make sure that the most representative  
> subset
> of resolvers do actually opt-in?

I suppose we could look at the major sources of traffic at the roots  
and then contact the administrators of those sources to see if they'd  
be willing to participate in the separate infrastructure.

> o the participants would be on the informed side, using well known and

Or, we could do a statistical sample of sources of root traffic and  
try to get a significant portion to play along.

>  most likely mean switching a production system

Yes.  The separate infrastructure woulFrom [email-masked]  Tue Aug 26 12:53:40 2008
From: David Conrad <[email-masked]>
To: Peter Koch <[email-masked]>
Date: Tue, 26 Aug 2008 12:53:32 -0700
Cc: IETF DNSOP WG <[email-masked]>
Subject: Re: [DNSOP] signed root on a separate infrastructure [Re: A
	different question]
Sender: [email-masked]

Peter,

On Aug 23, 2008, at 4:09 AM, Peter Koch wrote:
> the AAAA introduction for the root name servers went smoothly.

Yep.  As I mentioned, it was unfinished, unpublished, and outdated.

> How to avoid leakage between the plain and the DNSSEC signed root?

What sort of leakage are you concerned about?

> What is the back out strategy?

I would presume that it would be made very clear that the separate  
infrastructure would simply be terminated at some point in the future  
following the deployment of the live signed root.

> Most importantly: How do you make sure that the most representative  
> subset
> of resolvers do actually opt-in?

I suppose we could look at the major sources of traffic at the roots  
and then contact the administrators of those sources to see if they'd  
be willing to participate in the separate infrastructure.

> o the participants would be on the informed side, using well known and

Or, we could do a statistical sample of sources of root traffic and  
try to get a significant portion to play along.

>  most likely mean switching a production system

Yes.  The separate infrastructure would d need to be production-quality  
and you'd need to convince folks that they could trust that  
infrastructure.

> And I'd say this is a serious concern.

Why?  The namespace and the infrastructure supporting that namespace  
are entirely different things.  There is nothing magical about the  
existing root servers other than the fact that they are listed in the  
root hints file.

The existence and use of ORSN hasn't appeared to have driven anyone to  
create alternative name spaces to my knowledge.

> Also, an experiment is much different
> from a migration for technical/operational and layer 9 reasons.

I suspect it depends on what you're trying to discover in the  
experiment.

> The operational

For an experiment to see what if anything breaks if you sign the root?

Regards,
-drc

need to be production-quality  
and you'd need to convince folks that they could trust that  
infrastructure.

> And I'd say this is a serious concern.

Why?  The namespace and the infrastructure supporting that namespace  
are entirely different things.  There is nothing magical about the  
existing root servers other than the fact that they are listed in the  
root hints file.

The existence and use of ORSN hasn't appeared to have driven anyone to  
create alternative name spaces to my knowledge.

> Also, an experiment is much different
> from a migration for technical/operational and layer 9 reasons.

I suspect it depends on what you're trying to discover in the  
experiment.

> The operational

For an experiment to see what if anything breaks if you sign the root?

Regards,
-drc

---

From: Ralf Weber <[email-masked]>
Date: Tue, 26 Aug 2008 22:13:52 +0200

Moin!

> fatal to the UDP transaction.
Ack that's the reason why the MTUs in todays networks get bigger and  
bigger.

> paths can change.   What works close by, might not work far away, and
FIB and path changes only matter when the final IP destination  
changes, again not a problem in todays network where IP is just one  
overlay transport of an underlying label switched network. And thus  
the path changes, but the final (anycasted) destination does not.

> whether it works for everyone else.
While I get paid for that it does work four our customers, so this  
obviously this is my first concern.

> While you may be satisified with
Well we are doing DNS anycasting for recursive resolvers and I know at  
least of three other carriers that do exactly the same and where it  
also works.

> everywhere has to be able to use Root and TLD DNS services reliably.
True, and I haven't spoken about that as I don't have experience  
there, I guess Peter Koch or Anand Buddhdev are some of the persons I  
would talk to about this, as they are doing it. As a consumer of  
anycast TLD dns services I so far haven't encountered a problem,  
despite that we are using tcp as fallback mechanism for suspected  
spoofing. And as external BGP routing usually is a lot more stable  
than internal routing service I would think that problems are less  
than in one ASes network.

> worst: "It worked for me in a very limited scenario, and I don't worry
Well we did test, discovered some problems, worked around them and now  
are happy deploying it. That's what engineers are for. There may be  
theoretically cases, but unless they can be proved in a lab and there  
is no way around it I don't care to much.

So long
-Ralf
---
Ralf Weber

---

From: Ralf Weber <[email-masked]>
Date: Tue, 26 Aug 2008 22:13:52 +0200

Moin!

So long
-Ralf
---
Ralf Weber

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 17:25:44 -0400 (EDT)

On Tue, 26 Aug 2008, Andrew Sullivan wrote:

> with significant profile in the crypto community got the math wrong, 

The text of mine that you quote was an explanation of how a chosen
plaintext attack works on PKI like RSA.  All that I said is that I can't
quote the exact math of how the attack works.

However, If you mean to suggest that DNSSEC has been checked over for 10
years by crypto experts without finding flaws, I think your drawing the
wrong conclusion from DNSSEC history, as well as who has certified its
security.  DNSSEC work has proceeded in fits and starts for 15 years.
Prior DNSSEC work has been almost completely abandoned by RFC4033-35.  
Not completely replaced, since there are new typecodes are needed to
continue with incompatible use of SIG, KEY, and NXT records from prior
(failed) attempts at obtaining secure and workable DNSSEC.

> I don't think you're going to get a warm reception.  I think you need
> to demonstrate that there is an actual problem.  Certainly, we'll need
> an argument somewhat stronger than, "The math could be wrong
> somewhere."

I never said 'the math could be wrong somewhere'.

I said there is a PKI(RSA) chosen plaintext attack through which one can
obtain the private key used to sign DNSSEC records. There is no
ambiguity about the existance of that attack, but I will provide an
authoritative reference tomorrow.

> demonstration of an actual attack.

An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty
trivial; the code demonstrating the kaminsky poisoning will work with
some DNSSEC changes. I won't be able to start on that until probably
thurs or fri. I first have to find a non-verifying DNSSEC cache. I think
BIND may work, but will have to check. If anyone has suggestions for a
non-verifying cache, that would be appreciated.  Or if some BIND experts
have suggestions for making BIND not verify, that would save me some
time. If someone wants to volunteer a non-verifying server that is
otherwise "in the wild" for use, that would help. Contact me offlist.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 26 Aug 2008 17:25:44 -0400 (EDT)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Aug 2008 10:48:15 +1000

> fatal to the UDP transaction.

	Actually you just turn off PMTUD on replies.  This is
	recommended for *all* nameservers.  It's pointless for
	authoritative nameservers to maintain PMTU state and may
	infact be a DoS vector if they do.

	IPv4 - Don't set FD.
	IPv6 - Fragment at the server at network MTU.

	The socket option IPV6_USE_MIN_MTU was a direct consequence
	of DNS operators looking at this issue over 10 years ago.

	http://www3.tools.ietf.org/html/draft-ietf-ipngwg-bsd-frag-01

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 Aug 2008 10:48:15 +1000

IPv4 - Don't set FD.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Aug 2008 10:27:24 -0400

> An actual poisoning of a non-verifing DNSSEC cache, yes. This is pretty

Wait a minute.  You're proposing to show that "a DNSSEC cache" that
doesn't actually do DNSSEC (whatever that would mean) can be poisoned?
I'm not sure I see the reasoning.  I don't think that a positive
result would be very big news at all -- in my view, a DNSSEC cache
that doesn't validate responses is, well, not a DNSSEC cache at all.

Is your concern that a DNSSEC-aware recursing resolver, with
validation turned off, can be poisoned even though it correctly
handles all the DNSSEC-requesting questions from a stub resolver, and
correctly handles the data from a DNSSEC-offering server, in the case
where Mallory can win the race and answer the non-validating
DNSSEC-aware resolver before the legitimate server?

A

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 27 Aug 2008 10:27:24 -0400

A

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Aug 2008 20:48:13 +0200

=> draft-agl-tcpm-sadata-01.txt section 9:

9.  Comparison to T/TCP

   The idea of including data in frames which also carry a SYN flag
   isn't new: it was included in the experimental T/TCP RFCs 1379
   [RFC1379] and 1644 [RFC1644].  T/TCP suffered because it broke the
   assumption that the source address of a new connection from a
   passive-open socket had been verified by a 3-way handshake.  This was
   a critical security issue for applications like RSH which often used
   source address whitelists.

Note for DNS poisoning cache issue it is more the destination address
but the same argument applies...

Regards

---

From: Francis Dupont <[email-masked]>
Date: Wed, 27 Aug 2008 20:48:13 +0200

9.  Comparison to T/TCP

Regards

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Aug 2008 18:54:53 -0400 (EDT)

I suggest you review the past emails and the RFC's to find out what is
meant by a 'non-verifying DNSSEC cache'.

A DNSSEC-aware cache need not verify the responses it caches. It can
leave that task to the stub-resolver. By having the stub resolvers
perform the crypto checks, the crypto computation resources scale.  Of
course, if the cache doesn't verify, it can't tell its been poisoned,
and so ordinary poisoning will work.  But if the cache does verify, then
it has to perform a complex signature check, for which there are only
limited computational resources available to perform the check. DNSSEC
caches are cursed, either way.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Aug 2008 18:54:53 -0400 (EDT)

--Dean

---

From: Brian Dickson <[email-masked]>
Date: Thu, 28 Aug 2008 00:04:15 -0400

> can be a multiple of a prime.  

What Dean describes is a general "attack" on PKI math, not on 
(re-)signing as DNSSEC (RFC4034) specifies for RRSIG.

His theory is, if the attacker can arrange for the thing being signed to 
be a prime (or possibly even the product of two known primes),
then it may be possible to recover the key used for signing, based on 
the signature.

The question is, is it possible for an attacker to arrange for the thing 
being signed to be a prime, or some arbitrary value?

No.

There is no way to deterministically cause a known value to be used for 
what gets signed.

Here's why:

signature = sign(RRSIG_RDATA | RR(1) | RR(2)... )

But: RRSIG_RDATA includes the expiry and incept date - chosen by the 
signer, not the attacker.

Even worse, the contents of RR(1) are a DS record, which is itself a 
digest of a DNSKEY record.
The DNSKEY record includes a few fields which are mostly 0's (7/8, 7/8, 
6/8 on three octets).
The DS may be provided by the operator of the subordinate zone, or built 
by the parent operator,
most likely the latter.

So, there are 20 bits of zeros which get used in a digest, and 64 bits 
not under the attackers control,
plus 16 bits of fixed value (Type Covered), an 8-bit fixed value field 
(Labels),  plus the Signer's
Name is also a fixed value. That's way more than 88 bits of data not 
under the control of the attacker.

For perspective, 2^88 is the number of seconds in the age of the 
universe, estimated. To suggest that
appending a digest value to that, and having the result be a prime, does 
not strike me as a serious
threat to key recovery by an attacker.

So, I would say that in all likelihood, re-signing with the *same* key 
is perfectly safe.

(The inclusion of the signature's own timestamp values in the data being 
signed was, IMHO, genius.)

Brian

P.S. This does not, however, mean that there does not exist some other 
key recovery risk; if anyone knows of one, please detail it or give a 
reference.
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Brian Dickson <[email-masked]>
Date: Thu, 28 Aug 2008 00:04:15 -0400

No.

Here's why:

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 28 Aug 2008 00:56:09 -0400

[email-masked] wrote:
> On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
>   
> 	thats an interesting premise.  
> 	why do you think this will be the case?
> 	
> 	(I would posit that the folks generating the DNSKEY will also 
> 	want to generate the DS hash on their known, trusted signing tools
> 	instead of trusting the parent w/ the DNSKEY materials)
>   

Well, here's why:

- The DS is a deterministic function
- Having DS sent to the parent, rather than calculated locally by the 
parent, introduces a host of human and/or process risks/requirements
- The DS only needs to be built when the DNSKEY changes (key rollover)
- The parent is already trusted with DNSSEC tools, since the parent is 
signing the parent's zone (including the DS record!)
- Nothing in the DNSKEY, or in the building of the DS, involves private 
keys, only public keys - so there is no trust issue with the materials.
- The DNSKEY is already published, so the parent can trivially get it, 
in a way that is not subject to poisoning (the NS glue is hardcoded in 
the parent zone, after all)

It isn't something that seemed obvious until I looked at the signing 
stuff. If the DS is deterministic, why create an avenue for expoiting?

Brian
_______________________________________From [email-masked]  Wed Aug 27 21:56:09 2008
Date: Thu, 28 Aug 2008 00:56:09 -0400
From: Brian Dickson <[email-masked]>
To: [email-masked]
Cc: "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

[email-masked] wrote:
> On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote:
>   
> 	thats an interesting premise.  
> 	why do you think this will be the case?
> 	
> 	(I would posit that the folks generating the DNSKEY will also 
> 	want to generate the DS hash on their known, trusted signing tools
> 	instead of trusting the parent w/ the DNSKEY materials)
>   

Well, here's why:

- The DS is a deterministic function
- Having DS sent to the parent, rather than calculated locally by the 
parent, introduces a host of human and/or process risks/requirements
- The DS only needs to be built when the DNSKEY changes (key rollover)
- The parent is already trusted with DNSSEC tools, since the parent is 
signing the parent's zone (including the DS record!)
- Nothing in the DNSKEY, or in the building of the DS, involves private 
keys, only public keys - so there is no trust issue with the materials.
- The DNSKEY is already published, so the parent can trivially get it, 
in a way that is not subject to poisoning (the NS glue is hardcoded in 
the parent zone, after all)

It isn't something that seemed obvious until I looked at the signing 
stuff. If the DS is deterministic, why create an avenue for expoiting?

Brian

______
DNSOP mailing list
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 28 Aug 2008 10:16:49 -0400

> meant by a 'non-verifying DNSSEC cache'.

I have a passing familiarity with the RFCs, and the phrase
"non-verifying DNSSEC cache", and even "non-verifying", appears
nowhere in RFC 4033, RFC 4034, or RFC 4035, as near as I or grep can
tell.

I think you have some terms confused, which is why I asked.  In particular,
 
> A DNSSEC-aware cache need not verify the responses it caches. 

I think that the word you want here is "validate", not "verify".  The
terminology is defined in RFC 4033 in particular.  There are places in
the documents where other terms -- "authenticate" is also used -- turn
up, but for the purposes of this discussion, I think it's best that we
stick to the strictly defined terms so that we don't get confused.
Usually, I think it preferable to say that individual signatures are
verified, and responses are validated.  There is a subtle difference
between these two notions, and understanding the difference is going
to be crucial in evaluating some of the claims you are making.  This
is why I'm trying to be precise.

So let me outline the cases I think there are, and you can say whether
I've captured all the cases you think are relevant, and where you
think the vulnerabilities are.  In each case, let's assume we are
asking for a name that has been signed so that we don't have to worry
about cases that we know can't be secured.

Case 0: security-oblivious stub resolver, security-oblivious recursive
resolver, security-oblivious server.  [Note: this case is effectively
impossible under our assumption, since the server can't really serve a
domain that's been signed.  I have it here for completeness, but a
deployment like this is already broken in operation.  I'll skip
cataloguing the other variants of "security-oblivious server" on these
grounds.]

Case 1: security-oblivious stub resolver, security-oblivious recursive
resolver, security-aware server.

Case 2: security-oblivious stub resolver, security-aware recursive
resolver with a local policy of "no DNSSEC", security-aware server.

Case 3: security-oblivious stub resolver, security-aware recursive
resolver with a local policy of "DNSSEC", security-aware server.

Case 4: security-aware stub resolver that does not set the CD bit,
security-aware recursive resolver, security-aware server.

Case 5: security-aware stub resolver that does set the CD
bit. security-aware recursive resolver, security-aware server.

Case 6: security-aware stub resolver that does not set the CD bit,
security-oblivious recursive resolver, security-aware server.

Case 7: security-aware stub resolver that does set the CD bit,
security-obvlious recursive resolver, security-aware server.

Have I missed something?  Which of these are the cases where you think
(a) cache poisoning is possible at the recursive resolver and (b) the
stub resolver can be fooled by Mallory?

Best,

A

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 28 Aug 2008 10:16:49 -0400

Best,

A

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Aug 2008 16:30:02 +0200

On Fri, Aug 22, 2008 at 11:53:02AM -0700,
 David Conrad <[email-masked]> wrote 
 a message of 1187 lines which said:

> It is a bit dated as it was originally written 
> before the IPv6 glue was added to the roots.  If there is interest in 
> pursuing this, I could take a stab at another revision.

If you do so, I suggest a few changes:

> Obviously, glue modifications to the existing root servers must not
> affect the glue associated the new technology servers. This would be
> the only exception to the root data replication procedures. 

Well, adding DNSKEY and DS records, for instance, would also be a
change to the data replicated.

At another place, you say that the parroot will not "change the
namespace" which seems a better description than to say it will not
change the "data replicated".

> While not an absolute requirement, maintaining coherency and
> reducing the possibilities for fragmentation are goals that are
> likely best achieved if the new technology root servers were to be
> operated by the current root server operators (or a subset of those
> operators)

It seems quite questionable. First, I do not know how many of them
want to participate. Second, parroot could be an interesting way to
test new potential root name server operators (it is hard to believe
that the set of root name server operators must be immutable for the
next centuries).
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Aug 2008 16:30:02 +0200

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Aug 2008 12:57:43 -0400 (EDT)

> parent, introduces a host of human and/or process risks/requirements

How does the parent know it is not getting spoofed, assuming this is the
first time a DS record is created for the sub domain?

> keys, only public keys - so there is no trust issue with the materials.

Getting the wrong public key in the DS record is a trust issue.

> - The DNSKEY is already published, so the parent can trivially get it,

Really? Getting it securely is not that trivial.

> the parent zone, after all)

IP spoofing is possible.

See RFC5011 ?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Thu, 28 Aug 2008 12:57:43 -0400 (EDT)

IP spoofing is possible.

See RFC5011 ?

Paul

---

From: [email-masked]
Date: Thu, 28 Aug 2008 05:08:04 +0000

> - The DS is a deterministic function

	no arguement there

> parent, introduces a host of human and/or process risks/requirements

	as opposed to sending the DNSKEY?

> - The DS only needs to be built when the DNSKEY changes (key rollover)

	yes - and the child rolls the DNSKEY, not the parent.

> signing the parent's zone (including the DS record!)

	assuming facts not in evidence. there is active discussion 
	about having unsigned zones w/ DS records included.

> keys, only public keys - so there is no trust From [email-masked]  Thu Aug 28 14:46:00 2008
Date: Thu, 28 Aug 2008 05:08:04 +0000
From: [email-masked]
To: Brian Dickson <[email-masked]>
Cc: [email-masked], "[email-masked] WG" <[email-masked]>
Subject: Re: [DNSOP] Cache poisoning on DNSSEC
Sender: [email-masked]

> - The DS is a deterministic function

	no arguement there

> parent, introduces a host of human and/or process risks/requirements

	as opposed to sending the DNSKEY?

> - The DS only needs to be built when the DNSKEY changes (key rollover)

	yes - and the child rolls the DNSKEY, not the parent.

> signing the parent's zone (including the DS record!)

	assuming facts not in evidence. there is active discussion 
	about having unsigned zones w/ DS records included.

> keys, only public keys - so there is no trust isissue with the materials.

	well... lets agree to disagree here.

> the parent zone, after all)

	and the NSset comes from the child.... like the DNSKEY and (in my case)
	the DS rr.  The rational for the child creating the DS is matching key
	validity periods with the TTLs at the child.  

> stuff. If the DS is deterministic, why create an avenue for expoiting?

	see above. :)
> Brian

	YMMV - my current policy is to create my DS rrs and send them to the parents.
	just like sending the paretn the right NSsset.

--bill

sue with the materials.

	well... lets agree to disagree here.

> the parent zone, after all)

	and the NSset comes from the child.... like the DNSKEY and (in my case)
	the DS rr.  The rational for the child creating the DS is matching key
	validity periods with the TTLs at the child.  

> stuff. If the DS is deterministic, why create an avenue for expoiting?

	see above. :)
> Brian

	YMMV - my current policy is to create my DS rrs and send them to the parents.
	just like sending the paretn the right NSsset.

--bill

---

From: [email-masked]
Date: Thu, 28 Aug 2008 04:36:43 +0000

--bill

---

From: [email-masked]
Date: Thu, 28 Aug 2008 04:36:43 +0000

--bill

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 09:40:08 +1000

> first time a DS record is created for the sub domain?

DS/DNSKEYs need to be supplied to the parent over the same channel
that NS updates are supplied over.  If you are not already applying
anti-spoof techniques to NS updates you can't trus DS/DNSKEY updates.

> Getting the wrong public key in the DS record is a trust issue.

So's getting the wrong NS RRSet or getting bad glue A and AAAA records.

> Really? Getting it securely is not that trivial.

It doesn't need to be secure it should just be for conformation of
the existing information over the existing channel.

> > the parent zone, after all)

DNSSEC really does not change the level of security parents should
be applying to delegation updates.  If the parent is using a third
party then that third party for delegation updates also needs to
apply similar proceedures for DS/DNSKEY as for NS, A and AAAA.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 09:40:08 +1000

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 10:19:41 +1000

> 	instead of trusting the parent w/ the DNSKEY materials)

	The parents can seen the public side of the DNSKEY materials
	which the DS identifies.
 
> > Brian

	The problem is that *only* the child knows which DNSKEYs
	need DS records and which ones don't.

	The child may even want to have DS's published in advance
	of the associcated DNSKEY being published to reduce DNSKEY
	RRset size at KSK rollover by using a replacement strategy
	for the KSK.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 10:19:41 +1000

Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 10:23:53 +1000

> 	about having unsigned zones w/ DS records included.

	Well you are not talking about DNSSEC 4035 then.  Such DS
	records are just noise to DNSSEC 4035.

> > the parent zone, after all)

	May be published.
 
	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 10:23:53 +1000

May be published.
 
	Mark

---

From: [email-masked]
Date: Fri, 29 Aug 2008 00:33:10 +0000

> 	records are just noise to DNSSEC 4035.

	Well, i never said I was talking abt DNSSEC 4035. (what is that
	anyway?  DNSSEC as defiend by RFC 4035?)  I was talking about 
	who generates DS rr's.  Brian postualates the parent is always
	ready and willing to do so, I disagree, based on empirical 
	evidence.

--bill

---

From: [email-masked]
Date: Fri, 29 Aug 2008 00:33:10 +0000

--bill

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 11:06:48 +1000

> 	anyway?  DNSSEC as defiend by RFC 4035?)

	Yes.  

>  	I was talking about 

	So do I.  See my other posts.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 Aug 2008 11:06:48 +1000

Yes.  

	Mark

---

From: Dean Anderson <[email-masked]>
Date: Sat, 30 Aug 2008 16:48:29 -0400 (EDT)

On Tue, 26 Aug 2008, Ralf Weber wrote:

> > they can be fragmented by PMTU discovery. The server (operating
> > system) has to maintain UDP state for PMTUD to work.  If the ICMP
> > fragmentation needed is lost due to Anycast, PMTUD will fail. Lost
> > UDP fragments are fatal to the UDP transaction.

> Ack that's the reason why the MTUs in todays networks get bigger and  

Possibly. But MTU size should properly be a matter of latency vs
overhead.  Only one packet can be transmitted at once. The larger the
packet, the greater the latency before a higher priority packet can be
transmitted. Smaller packet have lower latency, but are less efficient
due to repeated overhead of mac addrs, ip addrs, etc.  Adjusting MTU to 
prevent fragmentation is sometimes possible, but a bad idea.

> > FIB entries change at every hop. The more hops away, the more often
> > the paths can change.  What works close by, might not work far away,
> > and vice versa.

> the path changes, but the final (anycasted) destination does not.

The FIB entries can change at *any* router, and a FIB change *anywhere*
_can_ result in a different exit from an intermediate network; a
different exit also means there may be a different entry into the final
destination network, which usually changes the anycast host.  FIB
changes always matter.

> obviously this is my first concern.

I doubt that many of your customers use TCP DNS. You only *think* it
works, because you didn't do adequate testing to see it doesn't work.  
That isn't the same as 'works for our customers'.

Are your resolvers public?  Would it be OK if I test them?

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sat, 30 Aug 2008 16:48:29 -0400 (EDT)

--Dean