Subject: Additional filtering of responses

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 07 Aug 2008 13:00:51 +0200

Hi,

A new version of my resolver (Unbound) with additional filtering of
responses to counter the recently disclosed vulnerability at blackhat
was just released. This filtering is in addition to the bailiwick
checking. I would like to say what I did, here, because this is easy to
do, and effective against certain types of 'the Kaminsky attack'.

1) Stuff in the additional section. RFC2181. Understand why Masataka and
Paul think it is very important, and worth bickering over. Just mentioning.

2) CNAME chains.  The first CNAME, that starts with the query name, is
OK. Everything after that, especially if in-bailiwick and giving nice
hints about www.example.com and so on is ignored from incoming messages.
Instead, the target of the CNAME is queried again. I think BIND already
does this.

3) DNAMEs. Unvalidated DNAMEs are not used from the cache. I believe
BIND also does this already.  Thus, a new request is done for every
query under a (not DNSSEC validated) DNAME, receiving a new redirection
for that one query.

So, only stuff that exactly matches the query is left in the answer
section.  The rest is ignored (basically, I delete it immediately).

This simply rejects a couple of loopholes without great additional
complexity or bother. It does not protect fully against 'The Kaminsky
Attack', only some variations are stopped.

The best solution is of course DNSSEC. Crypto signatures instead of
randomisation games. Enable DNSSEC validation now.

Best regards,
~   Wouter

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

---

From: bert hubert <[email-masked]>
Date: Thu, 7 Aug 2008 15:42:37 +0200

> randomisation games. Enable DNSSEC validation now.

Not specifically aimed at you Wouter, but it appears the most vocal people
in the DNS world are starting to suffer from "groupthink". 

http://en.wikipedia.org/wiki/Groupthink

"A mode of thinking that people engage in when they are deeply involved in a
 cohesive in-group, when the members' strivings for unanimity override their
 motivation to realistically appraise alternative courses of action"

"Groupthink tends to occur on committees and in large organizations. 
 [..]"

For a fine compendium of the kind of statements I mean, please see
http://www.dnssec-deployment.org/news/dnssecthismonth/current/

	DNSSEC cited as "only full solution" to recent DNS vulnerability

	"DNSSEC is the only full solution."

	"We at ISC hope that this issue will draw attention to DNSSEC, which
	in the end will only be the real solution"

And this can't be good - it is leading us to make statements which are
patently untrue, like "turn on DNSSEC to be safe".

Or 79 page presentations called "DNSSEC in six minutes" - giving people 4.6
seconds per page. It is just not real.
http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf 

Or asking people repeatedly to remove the phrase "under development" when
DNSSEC is referred to as a solution under development - which it patently
is. 

If the goal is to deploy DNSSEC quickly, roll out the tools surrounding it,
invent the protocols for getting your keying material upstream, widen the
registry-registrar protocols to fit these records, create the emergency key
rollover procedures (and don't hide the need for them), implement 'auto-sign
yes;' etc etc etc. The only way DNSSEC will ever work if it is only slightly
harder to operate than DNS.

But if you care about DNSSEC, please stop pretending DNSSEC is ready to
deploy and just waiting for people to get around to it.

If you care about DNSSEC, don't hide that it might in itself have security
implications.

If you care about DNSSEC, please also stop pretending it is not far harder
to operate than DNS itself. DNS is already considered to be difficult, and
operators mess it up all the time. It is not like adding an 's' to
'http://'.

All these things will come back to haunt you when people actually do follow
the advice to turn on DNSSEC now, and discover they've either done something
that doesn't help (signing without getting the trust anchor used), or have
actually caused their domains to go down, because they did not
institutionalize the key rollover procedures.

("You mean this goes down if I don't re-sign in time? Wow!").

The reason I rant on about this is that I care deeply about DNS, and that
DNS is *currently* under attack. While DNSSEC is agressively branded as a
fine solution, at best, it will be a solution in a few years.

Additionally, given things I've said before, I personally don't think DNSSEC
will ever see wide usage in the real world, so I feel very strongly that not
only do we need to improve DNS in the short term, the short term solution
also needs to be the long term solution.

But no matter what I feel - please everybody take a minute to read the
symptoms of groupthink, and wonder if we are still doing the best job we can
to improve DNS in the real world. 

Because that is our goal. I hope. 

	Bert

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

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 00:43:10 +1000

> http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf 

I've seen this document in the past and it actually turned me and others
completely off the idea of DNSSEC, which in part was what led to me
playing with encryption funnily enough, because it seems to me most are
promoting 30 day TTLs on the sigs, which means 30 days of replay attacks
potentially, not to mention the whole re-signing every 30 days.

Who ever thought that does not live in the real world, people
administering servers with X.509 certs that expire yearly is bad enough,
but every 30 days or less???

That alone is going to be a show stopped for most if not all admins with
too many things to do and not enough time to do everything.

-- 

Best regards,
 Duane

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2008 15:22:32 +0000

> Paul think it is very important, and worth bickering over. Just mentioning.

first, we should not send, or if we receive, we should not cache or forward,
anything in the additional section that could be found using a new query.
this rules out all records except those referred to by NS RRs in an authority
or answer section, whose target names are at-or-below the NS RR owner name.

second, use these "glue" records only when trying to reach these nameservers,
or when answering questions or sending referrals about these nameservers.  do
not use them in answer sections, nor as additional data for MX or SRV or any
other purpose.  if needed for such "other purpose", go fetch them normally.

the small technical differences that masataka and i were bickering over have
to do with implicit antialiasing, and circular nonreachability.  i'll explain
for the gallery, even though i do not think that masataka will hear me.  if
the following responses are heard:

	authority	foo.org		NS     ns1.a.foo.org
	additional	ns1.a.foo.org	A      10.0.0.51

	authority	a.foo.org	NS     ns1.a.foo.org
	additional	ns1.a.foo.org	A      10.0.0.71

then there is a configuration error which crosses zone boundaries and is not
subject to normally operational fixits.  since both glue records are necessary
for reaching the nameserver, an RDNS has a difficult decision to make.
masataka recommends one choice, i recommend the other.  in masataka's design
the RDNS would contextualize the values of ns1.a.foo.org and use each one at
different times, depending on which NS RR was being followed.  in my design
there would never be more than one value for the glue in the rdns cache, and
it would be the deepest one (so, the one matching the most labels with the
zone whose delegation it was given for.)

then there's circular nonreachability.  in the following configuration:

	foo.org		NS	ns1.bar.net

	bar.net		NS	ns2.foo.org

my design says that neither zone is reachable, since no glue given by the
foo.org or .org servers for the ns1.bar.net nameserver would be believed,
and no glue given by the bar.net or .net servers for ns1.foo.org would be
believed.  in masataka's design, this glue can be sent, and heard, and then
used contextually, and both zones would be reachable.

these issues are now moot, since the baliwick rules of glue transmission
and reception are now enshrined in most operating nameservers as well as
several RFCs, and are "house rules" in terms of the DNSSEC design, which
contemplates baliwick issues more deeply than pre-SEC DNS did.  we can go
on bickering, and we could reopen these settled standards questions, but
we should stop treating them as open or unsettled questions.

i remain troubled and saddened by my inability to communicate effectively
with masataka, he is a brilliant and passionate dns engineer who among other
things came up with a better design for Secure DNS than any of the ones we
have standardized, and anyone who studies his work can learn a lot.  however,
our far flung rough and tumble community demands proper decorum and not just
technical excellence, and for my own self esteem i have to draw the line
someplace.

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

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2008 15:54:17 +0000

> From: Duane <[email-masked]>
> 
> bert hubert wrote:
> completely off the idea of DNSSEC, ...

you are both missing the point of that document.  it's not a six minute
presentation.  but after you sit through that presentation, you can get
dnssec running in six minutes.  (we've measured.)  which is not to say
that dnssec is easy -- i know that at ISC we're thinking seriously of
dedicating the whole BIND 9.7 release to dnssec tools and usability.

> ... which in part was what led to me playing with encryption funnily
> enough, because it seems to me most are promoting 30 day TTLs on the
> sigs, which means 30 days of replay attacks potentially, not to mention
> the whole re-signing every 30 days.

you can use whatever TTL you want.  but more importantly, are you saying
we should discard a protocol because of the quality of early implementations
especially in terms of usability?  because if that were true i'm pretty
sure TCP/IP should have been shot dead back in 1985 or so.  likewise X11,
BSD, Linux, Windows, and MAC/OS.

> too many things to do and not enough time to do everything.

duane, i understand why bert's a dnssec denier.  but i urge you to study
the historical debates and the threat models document and think carefully
before you climb on that bandwagon.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2008 16:00:05 +0000

> From: bert hubert <[email-masked]>
> ...

"turn on DNSSEC so that some day we can stop fighting endless brushfires."

> deploy and just waiting for people to get around to it.

dnssec (the protocol) is ready to deploy.  the usability of the tools is
a bit low at the moment but that's expected in early days.

> ("You mean this goes down if I don't re-sign in time? Wow!").

BIND 9.6 will have online re-signing.  presumably others will also do this.

> symptoms of groupthink, and wonder if we are still doing the best job we
> can to improve DNS in the real world.
> 

i'd like to avoid re-debating the need for dnssec every few weeks.  it's
been a decade and a half.  these debates are just distractions.  anyone
whose vision or business plan or past representations to customers or code
base is just not adaptable to dnssec, please simply indulge those of us
who can see a need for it and who think we know how to make it happen.

---

From: Jesper G. Høy <[email-masked]>
Date: Thu, 7 Aug 2008 18:16:20 +0200

Hear hear !!

Jesper

> -----Original Message-----
> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of bert hubert
> Sent: Thursday, August 07, 2008 3:43 PM
> To: Namedroppers
> Subject: OFFTOPIC: DNSSEC groupthink versus improving DNS
>

---

From: "Roy Arends" <[email-masked]>
Date: Thu, 7 Aug 2008 18:32:35 +0200

Paul Vixie wrote on 08/07/2008 05:22:32 PM:

> Re: Additional filtering of responses
> 

What does the scripture say about the following, very small (see * below) 
response:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;010a.example.          IN      A

;; ANSWER SECTION:
010a.example.           86400   IN      A       192.0.2.9

;; AUTHORITY SECTION:
example.                86400   IN      NS      010a.example.

;; Query time: 3 msec
;; SERVER: 192.0.2.10#53(192.0.2.10)

No glue. No additional section. 

Is the address record in the answer section cached? 
When cached, is 192.0.2.9 considered authoritative now for future lookups 
under example? 
Will that NS record ever expire if a query is send once a day ?

With all scrubbing and additional filtering of responses, will this 
response cause a successful cache-(over)write of example NS records?

No criticism about scrubbers and filters, just curious of what 
implementations do and what the protocol dictates.

Roy Arends
Nominet.

(*) The wireformat of this DNS message is just 60 octets due to the use of 
compression pointers.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2008 16:46:44 +0000

From: "Roy Arends" <[email-masked]>
> What does the scripture say about the following, very small (see * below) 

what am i, your prophet?  to hell with the scriptures, here's my take on it.

> Is the address record in the answer section cached? 

yes, since it matches the qname and it's in the zone you were querying.

> When cached, is 192.0.2.9 considered authoritative now for future lookups 

yes, since it was received as an answer, it's presumed to be the same as
the answer one would get by discarding it and re-asking for it.  (that's
what's different about this case vs. the additional data case.)

> Will that NS record ever expire if a query is send once a day ?

your example shows an authoritative response.  your question here is about
expiry and therefore caching.  the TTL would tick down, and on the seventh
day it would expire, and a subsequent query would cause us to go back to
the root zone for a new delegation response.

> response cause a successful cache-(over)write of example NS records?

yes.

> implementations do and what the protocol dictates.

the protocol is horribly weak in terms of datapath protection.  the whole
thing is laboratory-grade.  the only true fix for any of this is dnssec.

> Roy Arends
> Nominet.
> 
> (*) The wireformat of this DNS message is just 60 octets due to the use
> of compression pointers.

i think DW (DNS-OARC) has a wiki where stuff like this can be shared, fwiw.

note that RTT banding, to make more random the RDNS' selection of an ADNS,
is another terrible idea (similar to dns-0x20 in its terribleness but also
in the ability to deploy it without a forklift of the whole infrastructure),
which would make it little bit harder to spoof .COM delegation responses.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 07 Aug 2008 12:57:00 -0400

While doing some free-associating around the Kaminsky presentation, I 
began pondering wildcards.

Specifically, what could we do, using wildcards, to nip the 
$RANDOM.example.com problem in the bud?

Here's the beginnings of a meme on this concept...

If:
Authority server for example.com has a wildcard which means to 
communicate that anything matching the wildcard should get NXDOMAIN answers;
And:
A recursive resolver, upon getting an NXDOMAIN for a *specific* 
subdomain query, such as foo000001.example.com, do a query for the "*" 
literal;
Then:
The recursive resolver could cache the wildcard NXDOMAIN for $TTL, and 
immediately answer queries for all such garbage subdomains.

Then, anyone wanting to protect their domain would be able to add in the 
wildcard NXDOMAIN.

Or, plan B (which does not require any work on the part of domain 
administrators, only modified code on resolvers and authority servers):

If:
An authority server, upon receiving a query for wildcard literal "*", if 
it does not find a match, returns in the Additional section, an 
enumerated list of delegated subdomains.
And:
(same as "And" clause above)
Then:
Additional responses get cached for positive enumerated answers, and an 
additional wildcard literal "*" gets synthesized for NXDOMAIN on all 
other subdomains.

Both of these appear, at first blush, to remove the non-TTL basis for 
triggering new windows for birthday attacks, and thus can significantly 
improve the resilience to forgery attacks of the new Kaminsky vector 
variants.

Thoughts?

Brian Dickson

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2008 17:18:28 +0000

> $RANDOM.example.com problem in the bud?

any solution requiring cooperative action/change by both the RDNS and ADNS
has a cost that's equivilent to "deploy DNSSEC".  the thing that's good
about UDP port randomization, or DNS-0x20, is that it only requires change
in one place (the RDNS in those cases, but an ADNS-only solution would also
be cheaper than "deploy DNSSEC".)

for solutions involving "upgrade all nodes", the first term of the expression
of deployment cost is in touching all those nodes, and the actual complexity
or difficulty of the new protocol is a distant second term, easily managed
through normal and inevitable capitalistic incentives.

for all solutions having the same cost as "deploy DNSSEC", compare the
expected benefits.  the DNS datapath is long and twisty and involves both
on-wire and off-wire transport.  zone storage on primary and secondary
servers, zone transfer between those servers, zone content generation from
databases, responses from ADNS to RDNS, responses from RDNS to stub, and
application to stub API, are all corruptible elements of the DNS datapath.

> Brian Dickson

among all same-cost solutions, which one protects the largest amount of
the DNS datapath?  hint: it's not based on wildcards.

i would love to hear more ideas that involve only one point of action/change,
like UDP port randomization or DNS-0x20.

paul

---

From: "Roy Arends" <[email-masked]>
Date: Thu, 7 Aug 2008 19:22:44 +0200

> what am i, your prophet?  to hell with the scriptures, here's my take on 
it.

I was trying to address the group in general, you happened to be on the 
recipient list. Forgot to scrub that ;-)

> i think DW (DNS-OARC) has a wiki where stuff like this can be shared, 
fwiw.

Thanks for the pointer. I'll ping DW.

> which would make it little bit harder to spoof .COM delegation 
responses.

Agree

Roy

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Aug 2008 18:29:58 +0100

> other purpose.  if needed for such "other purpose", go fetch them normally.

Also, these glue records (both authority and additional) should be ignored
if they are already in the cache.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
CROMARTY FORTH TYNE: NORTHERLY 5 OR 6, BECOMING VARIABLE 3 OR 4 LATER.
MODERATE OR ROUGH. RAIN OR SHOWERS THEN MAINLY FAIR. MODERATE OR GOOD,
OCCASIONALLY POOR AT FIRST.

---

From: bert hubert <[email-masked]>
Date: Thu, 7 Aug 2008 19:38:19 +0200

> has a cost that's equivilent to "deploy DNSSEC".  the thing that's good

That's simply not true - DNSSEC does not function automatically even if both
ADNS and RDNS support it. 

DNSSEC needs a change to:
	ADNS,
	RDNS, 
	the zone, 
	the registry, 
	the registrar,
	and even the operational procedures of domain owner.
	(the stub, the application - if you want to give the end-user a
	choice)

EDNS PING or other entropy enhancing solutions provide benefit to anybody
deploying them, without further work, and require only ADNS and RDNS work.

DNSSEC provides lots of other things beyond entropy of course. 

	Bert

---

From: Brian Dickson <[email-masked]>
Date: Thu, 07 Aug 2008 13:49:47 -0400

> 	(the stub, the application - if you want to give the end-user a

Paul's point was that there are orders (many) of magnitude more systems 
enumerated in the sets { ADNS } and { RDNS } than in all the rest of the 
items.

And, if you are talking about touching them, you may as well touch them 
in a way that facilitates DNSSEC - possibly in addition to other things.

Furthermore:
"the zone" and "the registry" are often under the same administrative 
control, and in the case of TLDs, (a) there are very few currently, and 
(b) there are choices of TLD once there exists one TLD that does DNSSEC.

And, technically, it only requires a change to ONE registrar, to enable 
DNSSEC, since it is possible to change registrars, if one wants DNSSEC.

So, the bare minimum for DNSSEC deployment is:
ADNS, RDNS, *one* zone + registry, *one* registrar, and the ops 
procedures and tools for the domain owner - which may be further 
facilitated by the outsourcing of some aspects of domain maintenance to 
a DNS hosting provider that "does" DNSSEC.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Aug 2008 13:44:34 -0400

>;; SERVER: 192.0.2.10#53(192.0.2.10)

What bothers me about this is that the SERVER: address is not in the 
list (of 1) addresses authoritative for the zone owning the QNAME. 
(That is, 192.0.2.10 is not 192.0.2.9.)

I would probably reject this as an inappropriate setting of the AA 
bit - or chalk it up to an old BIND recursive server giving me a copy 
back of what it had just gotten from an authoritative server.

If I were paranoid, reject.  If I were paranoid but trying to be 
flexible, i would try to determine the vintage of what was at 
192.0.2.10 and then decide on rejection.  Otherwise, it seems like a 
valid answer.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 7 Aug 2008 21:02:42 +0200

Bert,

Imagine a person that has spend considerable amount of time, money and  
energy in implementing DNSSEC in servers, tools and libraries; has  
'evanginered' DNSSEC for years in a consistently balanced way,  
recognizing that implementing DNSSEC is far from easy; and has  
provided multiple pieces of documentation. In other words a person who  
has put the money where the mouth is.

How would such person defend against being assessed to suffer from  
groupthink or tunnelvission?

Every word such a person would utter in defense would be to responded  
to as "That person has a vetted interest and is part of the  
groupthinking tunnelvisionaires".

These sort of remarks are not very helpful for constructive  
engineering and don't help to get the core of your message across:  
"Keep an open mind in alternative interim(?) approaches and work on  
making DNSSEC easier to operate"

--Olaf

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Aug 2008 20:03:38 +0100

On Thu, 7 Aug 2008, Edward Lewis wrote:

> What bothers me about this is that the SERVER: address is not in the list (of
> 1) addresses authoritative for the zone owning the QNAME. (That is, 192.0.2.10
> is not 192.0.2.9.)

dig's server is the rDNS, not the aDNS.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SHANNON ROCKALL: NORTHERLY BACKING SOUTHERLY 5 OR 6, OCCASIONALLY 7 LATER.
MODERATE OR ROUGH. SHOWERS. MAINLY GOOD.

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Aug 2008 13:12:09 -0700

Bert,

> in the DNS world are starting to suffer from "groupthink".

If constructive discussion is desirable, I suspect it would probably  
be best to avoid labeling.

> fine solution, at best, it will be a solution in a few years.

This isn't quite accurate.  DNSSEC is an incrementally deployable  
solution.  It can fully protect zones that take the trouble to sign  
today if caching server operators take the trouble to configure trust  
anchors for those zones.  I have some skepticism DNSSEC will be a  
fully deployed solution in the foreseeable future, however that does  
not mean that there isn't potential benefit from its use.

And I say this as someone who hates DNSSEC with the passion of a  
thousands suns of passionate hate.

> also needs to be the long term solution.

The short term solutions proposed to date are protecting the data  
_channel_, not the actual data itself.  Fundamentally, this is a  
flawed approach because as long as the data in the response is  
vulnerable, there will be ways to abuse it.  Perfect source port/128  
bit XQID randomization, query/response TTL windowing, whatever is  
meaningless if you have write access to the path over which the query  
or response travels.  Those hacks are treating the symptom and are a  
holding action whereas DNSSEC, like aggressive chemotherapy, treats  
the disease.  One can reasonably argue that the side effects of  
treating the disease may be worse than the disease, but my view is  
that is simply a "small matter of programming" that will be addressed  
over time.

> to improve DNS in the real world.

I will admit that this feels sort of like someone from the petroleum  
industry accusing folks at the IPCC of "groupthink".

In the end, rants on either side don't actually matter all that much.   
There is a problem for which DNSSEC is proposed as a solution.  There  
are implementations that both do and do not support DNSSEC.  There are  
costs, benefits, and risks on which individual organizations will have  
to base their decisions to deploy DNSSEC or not. As such, I can't get  
too worked up on this topic -- I suspect the market will decide.

Regards,
-drc

---

From: bert hubert <[email-masked]>
Date: Thu, 7 Aug 2008 22:47:08 +0200

> has put the money where the mouth is.

Olaf - I can imagine only too well. Around 7 years ago I attended a talk by
you where you publicly wondered out loud which problem DNSSEC would solve,
and how it could actually be implemented. I was impressed by your
open-mindedness.

Over the years, I've seen the open mindedness disappear from the community.

As a decade passed away and DNSSEC stil hadn't caught on, self-doubt has
been replaced by the mantra that DNSSEC will soon be deployed, and that it
is ready - when there is much still up in the air.

> groupthink or tunnelvission?

That is very valid criticism, and I spent quite some time tonight figuring
out what I'm actually hoping to achieve - besides what is described very
well on http://xkcd.com/386/ . 

The main thing I hope is that we won't forget the pre-DNSSEC world. In short
this means committing towards finding a solution in short order that will
address remaining spoofing dangers - 64% chance of success within 24 hours
using reasonable resources. Success in these terms might be "effectively
taking over the root for 100000 people".

I've already seen influential WG members state that we'll have only one
chance to seriously change DNS in the coming decade. And furthermore, that
we should use this one chance for implementing DNSSEC.

In addition, it has been reasoned that implementing DNSSEC is just as hard
or easy as implementing entropy additions.

The upshot of this all is that people are effectively saying they will not
be supporting anything *but* DNSSEC.

And that would be sad, if not dangerous, especially since quite a number of
wise people agree DNSSEC rollout will take years. We don't have years to
address the 64% chance.

> making DNSSEC easier to operate"

I'd love to be able to put it less bluntly. What is also not helpful is the
near-religious mantra that DNSSEC is the only solution, a mantra which is
part of an astoundingly large part of recent postings and literature.

So - I apologise for accusing people of something it is hard to defend
against. 

But I sincerely hope we won't let the dream of large-scale DNSSEC deployment
over time stand in the way of doing something now.

	Bert

---

From: Edward Lewis <[email-masked]>
Date: Thu, 7 Aug 2008 16:44:05 -0400

>dig's server is the rDNS, not the aDNS.

Ok, but still, the aa bit would then make me do some more sanity 
checking if I were paranoid.

Is(n't) it true that BIND 9 no longer sets AA bit on answers a'coming 
through the cache?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Federico Lucifredi <[email-masked]>
Date: Thu, 07 Aug 2008 17:06:15 -0400

I have read Hubert-DNSSEC-groupthink and support its adoption as a WG 
document :-)

  -F

-- 

_________________________________________
-- "'Problem' is a bleak word for challenge" - Richard Fish
(Federico L. Lucifredi) - [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 07 Aug 2008 22:54:56 +0000

> Is(n't) it true that BIND 9 no longer sets AA bit on answers a'coming

yes.  everything is cached and regenerated.  bind9 RDNS never sets AA.

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 10:53:14 +1000

> dedicating the whole BIND 9.7 release to dnssec tools and usability.

I never mentioned anything about the time of the presentation or time to
set it up, my comment was how convoluted and complicated the process is
caused me to to instantly dislike it due to that reason.

> you can use whatever TTL you want.  but more importantly, are you saying

I realise this, but I was under the mistaken assumption, before Bert
corrected me that sigs were generated on the fly and were only valid for
a small window.

> BSD, Linux, Windows, and MAC/OS.

Ummm a good 'security' model in this sense would be to look at the
credit card industry, unless payment gateways are down merchants are
instantly notified of problems with credit cards, not 30 days later.

> before you climb on that bandwagon.

Oh please give me a little credit here and drop the 'denier' nonsense
right now, that term is often used as an emotive response that has no
basis in logic or reason where the underlying argument is weak in order
to silence criticisms.

-- 

Best regards,
 Duane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 10:52:22 +1000

> potentially,

	and the alterative is arbitary data insertion.

	You could have online keys and sign every response with a
	ttl + clock skew based window.  This requires that the
	private key is on all slaves.  The crypto hardware guys
	will love you :-)

	Note this is a implementation / deployment trade off.  The
	protocol supports either senario.

> not to mention the whole re-signing every 30 days.

	Which can be completely automated.  Has already been in
	some senarios.  I havn't re-signed my zones for months
	despite using a 30 day expiry period on the signatures.

	It is set and forget.  More and more of the process will
	become "set and forget" as the tools develop.

> but every 30 days or less???

	Well if you know that the data will be stable for a year
	you can sign once a year.
 
> too many things to do and not enough time to do everything.

	The tools today can take a signed zone and re-sign it as
	well as incrementing the SOA serial in the process.  Re-signing
	then reloading can be run from cron on a weekly basis.

	Note the tools will only get better so the costs will
	continue to go down.  They have gone down enormously from
	the original design costs.

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

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 11:03:04 +1000

Olaf Kolkman wrote:

> recognizing that implementing DNSSEC is far from easy; and has provided
> multiple pieces of documentation. In other words a person who has put
> the money where the mouth is.

You summed it up so nicely, they have put so much time and effort into
this that they can't see if there are other options because they are
blinded by the blinkers they have on, to go forward no matter what the
cost or no matter what other solutions could solve the same problem.

> groupthink or tunnelvission?

All I've heard lately is shouts of enable DNSSEC now, or die, frankly
I'm not very moved by them nor anyone else I know, it's 2008 and DNSSEC
is using a model even X.509 threw out years ago and has been trying to
fix every since.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 11:10:19 +1000

> 	private key is on all slaves.  The crypto hardware guys

I'm working on it, I'm fighting 2 issues at present, one to standardise
attributes on OpenPGP keys for server purposes, and once that's sorted
and all the hubbub about DNS has died down the 2nd issue is using
encryption to provide both confidentiality and effectively remove the
need for signing at all.

Thanks to feed back from people in this group I've improve the draft
considerably but yea, the idea now is to setup a AES session key that is
good for X hours using an initial RSA encrypted request from the client.

> 	protocol supports either senario.

It's 2008 and hardware is cheap it's silly to think of 1960's credit
card processing models are even valid 10 years ago let alone now.

> 	despite using a 30 day expiry period on the signatures.

Shows how much DNSSEC is used by you then, otherwise you would be
rejecting your own DNS replies.

> 	become "set and forget" as the tools develop.

You miss the point, that presentation outlined what is now, not what
will be when someone can be bothered to.

> 	you can sign once a year.

At the vest least natural disasters don't stick to time tables last time
I checked.

> 	then reloading can be run from cron on a weekly basis.

That's a nice 'hack'

> 	the original design costs.

Again, I can only comment on what is, not what will be.

-- 

Best regards,
 Duane

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Aug 2008 01:38:18 +0000

duane, if your point is that dnssec is horrid misshapen pig that even
its mother could not love, then you will find noone (anywhere) willing
to argue otherwise.  it's late, it's ugly, it's fragile, it's a pig,
and that's the universal view of it, there are no dissenters.

but having ridden the whole ride and having seen victory declared several
times, i am in the "it can be made to work in its present form without any
more flag days" camp.  call that groupthink if you must, say what you want
about me, but say also that i hate dnssec but plan to deploy it anyway.

--paul

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Aug 2008 01:51:01 +0000

> cost or no matter what other solutions could solve the same problem.

as a possible proposed "they" in that example, i wonder what other option
will allow arbitrary end users to be sure that an NXDOMAIN has not been
remapped by their ISP or by their RDNS?  or that a secondary name service
provider (or a primary name service provider for that matter) hasn't added
a wildcard to catch typo's in their customer domains and send them to an
advertising server?  in other words, what other options provide end-to-end
data integrity for DNS?  if all you've got is hop-by-hop, i'm uninterested.

amit klein and dan kaminsky have showed us some off-path attacks, to which
dan bernstein and amit klein and david dagon have shown us some RDNS-only
defenses.  but provider-in-the-middle and more generally man-in-the-middle
attacks are on-path not off-path.  i want protection against on-path
attacks, as well as against all possible future off-path attacks.  you're
right that i'm dismissing proposals that do not address those requirements.
now you know exactly why.

> is using a model even X.509 threw out years ago and has been trying to

after watching masataka's superior approach get railroaded into a ditch
back in 1996 or 1997 or so, i can no longer get bogged down in how ugly
the protocol is or how ugly was the process that begat that protocol.  my
pragmatic concerns are only, is it end-to-end, and can it be made to work?

show me an option that's end-to-end and can be made to work and i'll pay
close attention and if it's real i'll say "dnssec or this other thing are
the only real solutions."

but show me a hop-by-hop solution and i'll say "this isn't complete" and if
it requires a replacement or upgrade of both RDNS and ADNS nodes then i'll
say "at that price i'd prefer end-to-end data integrity, please."

let's stop talking personalities and focus on the engineering economics.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 12:01:37 +1000

> rejecting your own DNS replies.

	I missed the "by hand" part.

	I havn't re-signed my zones, by hand, for months despite
	using a 30 day expiry period on the signatures. 

	Completely automated re-signing.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 12:17:46 +1000

> Is(n't) it true that BIND 9 no longer sets AA bit on answers a'coming 

	It *never* set AA on answers from the cache.  All remote answers
	go through the cache.

	AA is only set on answers from zone data.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 12:37:11 +1000

> instantly notified of problems with credit cards, not 30 days later.

	Well we could stop caching any DNS data.  That's the only
	way to make it match the credit card industry model where
	changes are instantly available.

	Mark

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 12:54:52 +1000

> and that's the universal view of it, there are no dissenters.

No arguments here.

> about me, but say also that i hate dnssec but plan to deploy it anyway.

I most sincerely apologise if I made any person comment to or about you
that most certainly was not my intention. I like everyone else want a
solution to this and other problems with DNS but for a number of reasons
I don't like the form it's taken in DNSSEC.

I'm trying to stick to the non-political factual reasons for my concerns
over it, however it wouldn't be terribly difficult to figure out other
concerns I have with it.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 13:05:20 +1000

> data integrity for DNS?  if all you've got is hop-by-hop, i'm uninterested.

I maybe late to this party but I tried to engage you in this in previous
email correspondences, suffice to say I don't think either of us have
all the answers but dismissing alternative opinions on how this could be
solved out of hand isn't going to help either.

> now you know exactly why.

You just pointed out the solution, and I'm pretty sure you or others
have mentioned this before, but as far as end to end solutions go the
only solution is to run the resolving DNS caching at the end points.

While this negates some of the benefits of caching by say ISPs, it's
more than obvious the ISPs can no longer be trusted on that front in any
case and end user directly requesting to authoritative DNS servers is
the only option.

After all, do we allow ISPs to cache SSL connections, why should DNS be
any different?

> pragmatic concerns are only, is it end-to-end, and can it be made to work?

How much enthusiasm has been garnered for DNSSEC since well ever except
by those evangelising it?

If you can't sell it to people like me purely on its merits it's already
a forgone conclusion, I'm not trying to be facetious here or
antagonistic but pointing out a reality of the way the world is, not the
way we'd like the world to be.

> say "at that price i'd prefer end-to-end data integrity, please."

You've already outlined numerous corner cases where DNSSEC will fail in
end to end data integrity, so obviously it's not solving the issue in
all cases either.

My hop-by-hop approach wasn't the end game, merely a stepping stone
until something better could occur at the end points, my approach is
simply trying to go the path of least resistance and work up from there.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 13:14:36 +1000

> 	changes are instantly available.

Anyone have any idea how many credit card transactions per second occur?

Seems to me they are very similar in topology, so even if you only
cached information for a small amount of time that would mitigate most
attacks people seem to be so concerned about at present.

Since the window of opportunity for these sort of attacks would be
greatly reduced, the cost to commit these types of attacks would greatly
increase if not be virtually impossible to commit on any kind of scale
worth doing, so problem solved.

-- 

Best regards,
 Duane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 13:32:36 +1000

> worth doing, so problem solved.

	Except it wouldn't solve NXDOMAIN re-writing and other
	on-path attacks which modify the returned data such that
	it is believed.

	Mark

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 13:41:07 +1000

> 	on-path attacks which modify the returned data such that

Others have pointed out other cases where DNSSEC won't either. Reducing
the caching time only requires changes at the resolver end, unlike
DNSSEC which if Bert's list is accurate is quite long and involved code
wise.

-- 

Best regards,
 Duane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 13:42:49 +1000

> only solution is to run the resolving DNS caching at the end points.

I don't think anyone would disagree with you.  Preferably validation
should be done in the application.  If that is not supported by the
application then on the local machine.

Validation in off machine caches is only there for the legacy machines.

> case and end user directly requesting to authoritative DNS servers is

Only if the ISP's don't supply clean path.  DNSSEC allows you to
detect when the path has been compromised.

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 13:45:30 +1000

> Validation in off machine caches is only there for the legacy machines.

That's always going to be an issue unless you can get all parties to
implement something better.

> detect when the path has been compromised.

Only if you already know DNSSEC mechanisms exist and they haven't been
filtered.

-- 

Best regards,
 Duane

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 14:09:14 +1000

> implement something better.

Well every PC owner can do this today.  It is not that hard to setup
a on machine validating caching server and to configure the PC to use
it.

It's only administative inertia that stops people doing it today.

Mark

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 14:17:54 +1000

> a on machine validating caching server and to configure the PC to use

Ok so you're saying these people that get suckered by internet/email
scams would be capable of setting this up properly?

> It's only administative inertia that stops people doing it today.

No, there is a lot more to it than that, most people don't understand
internet security, you know it's bad when most people get warm fuzzy
feelings over actions taken to make them feel secure, when the reality
is so far from the truth it's not funny.

-- 

Best regards,
 Duane

---

From: Brian Dickson <[email-masked]>
Date: Fri, 08 Aug 2008 00:44:13 -0400

> DNSSEC which if Bert's list is accurate is quite long and involved code

I don't recall any specific cases being pointed out.

If you wouldn't mind, could you give some kind of reference (e.g. who, 
or what case, or ideally, a URL pointing into the archives)?

To clarify - what DNSSEC does (or at least claims to do) is make it 
possible to validate answers to queries, against a chain of trust to 
some trust anchor.

This means one of three results occurs - a valid answer is confirmed, an 
unverified answer exists due to lack of signature (where the lack of 
signature itself is able to be validated), or tampering occurs and is 
detected.

So, it won't *prevent* tampering, but does make the data itself 
tamper-evident.

Tampering is only slightly worse than a blind DoS attack, and has the 
same results in a DNSSEC-protected world. The only incremental benefit 
of hop-by-hop crypto security would be to  make the data opaque, which 
while in theory seems better, in practice is irrelevant. If you can't 
tamper with the data, it doesn't matter whether you can see it. And 
hop-by-hop data encryption is a bigger cost than validation via 
signatures, particularly in the increase in state, and in the asymmetric 
cost model. Signatures scale very well, especially in an one-to-many 
world, which DNS is.

> Only if you already know DNSSEC mechanisms exist and they haven't been

??

You can't filter DNSSEC mechanisms without that filtration being 
detected (on a validating resolver).

This includes the ability to determine whether DNSSEC mechanisms exist.

(The above is predicated on some configured trust anchor, either a 
signed root or via locally configured trust anchors, or DLV.)

If you believe these aren't correct statements, I encourage you to 
provide something more than a mere assertion, e.g. example, reference, 
proof, counter-example, or anything else that you think will support 
your position.

BTW - critical analysis of DNSSEC and alternatives is by no means 
discouraged, and I think any time anyone brings fresh eyes to the 
problem, only good things can come of it - if polite, reasoned discourse 
is the result.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 Aug 2008 14:52:04 +1000

> scams would be capable of setting this up properly?

People setup caching servers everyday today.  Setting up one to
also do validation is not that much extra.  

> is so far from the truth it's not funny.

And education is the solution to that.
 
People aren't as stupid as we often portray then as.  Give them
good information and they will use it.  Do best practice from the
start.

Mark

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 15:11:10 +1000

> I don't recall any specific cases being pointed out.

http://ops.ietf.org/lists/namedroppers/namedroppers.2008/msg01264.html

> signed root or via locally configured trust anchors, or DLV.)

That was my point, you have to know about it already one way or another
for it to work, otherwise it can simply be ignored by upstream caching
servers.

> problem, only good things can come of it - if polite, reasoned discourse

Again I apologise if I've said anything that unduly offended anyone, I'm
merely expressing my opinions based on what I know about certain topics
and I may have made incorrect assumptions and I'm only too happy to be
corrected so I don't make the same mistakes in future.

-- 

Best regards,
 Duane

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 15:16:54 +1000

> also do validation is not that much extra.  

Most people don't, the ones that do can probably do as you suggest, but
in reality the ones that would most benefit are those that rely on ISPs
or their routers/modems to do it all for them.

> And education is the solution to that.

That only works if people are interested in the learning you are trying
to impart to them. Most people will be complacent about such matters
until it really really matters to them personally. Such as loosing money
to an internet scam.

> good information and they will use it.  Do best practice from the

I'm not commenting on people's intelligence, I should have made my point
clearer I suppose, a general apathy plus some ignorance of the
mechanisms of how computers work and people don't care to learn beyond
that, until they have to and well by then it's usually too late the
horse has already bolted and they do the whole talk show scene trying to
get everyone to learn from their mistakes, which for the most part most
people don't.

-- 

Best regards,
 Duane

---

From: Brian Dickson <[email-masked]>
Date: Fri, 08 Aug 2008 02:00:47 -0400

> Anyone have any idea how many credit card transactions per second occur?

Ballpark figure - 6.5 B people, 10 transactions per day average, gives ~ 
1M/s worldwide.

There are about 1.5M unique hosts seen at the root and TLD servers per 
day, most are caching resolvers.

If the rates were comparable, each resolver would process ~ 1 
query/second. Off by several orders of magnitude.

> attacks people seem to be so concerned about at present.

Sorry, the details on the attack methods and vectors means you would 
throw away good answers more often
than you would throw away bad answers (from the cache), but an empty 
cache for a given domain is an extra vector.

Long TTLs are your friend. That those happen to benefit scaling is a 
bonus, not an assumption.

Here's a clue - credit card transactions are in effect only signed in 
real-time, not processed per se.
The actual transactions are still batch processed much later.
This is in part to avoid data leakage through the authentication process 
itself.

So, DNSSEC is already pretty similar to CC's, just with better scaling 
properties and less overhead.

> worth doing, so problem solved.
Not.

Brian

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 08 Aug 2008 15:13:15 +0900

Wouter Wijngaards wrote:

> checking.

No.

If you properly handle additional glue As to be tagged by query,
glue As does not need any bailiwick checking.

As answer non-glue additional information needs exact matching with
query, the information needs no bailiwick checking.

"Bailiwick" was considered to be a valid concept for non-glue
information but is never a valid concept for glue-As.

No WG consensus can override scientific nature of the DNS referral
mechanism.

> The best solution is of course DNSSEC.

A better solution, a lot more easier to deploy than DNSSEC, is to
use TCP, deployment of which is, of course, still hard.

However, it is only as hard as updating all the install bases,
including those on various types of NAT boxed, of DNS so that
they can treat glue and other information properly.

> Crypto signatures instead of randomisation games. Enable DNSSEC
> validation now.

Because of complexity of DNSSEC caused by poor combination of DNS
and public key cryptography, there are a several subtle hacking,
which are not present in PODS (plain old DNS), performed to make
it work.

With such additional subtlities, it is practically impossible to
be sure that DNSSEC is more secure than PODS.

Remember that even PODS has a lot of unexpected security
holes.

							Masataka Ohta

---

From: Duane <[email-masked]>
Date: Fri, 08 Aug 2008 16:27:09 +1000

> query/second. Off by several orders of magnitude.

So you are stating there is more CC authorisations per second for CC's
than DNS, and if that system works so well (most of the time) why can't
DNS follow that approach too?

> cache for a given domain is an extra vector.

Very few ISPs cache websites any more even though there is tangible
benefits in doing so still, but due to a variety of reasons many stopped
doing caching because it was more hassle then it was worth, at present
for me and others DNSSEC is more hassle then it's worth.

In short web pages could be cached rather than 'throw' away good answers
but they don't, why should caching DNS be given any more consideration
in this respect?

-- 

Best regards,
 Duane

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 08 Aug 2008 15:50:57 +0900

> When cached, is 192.0.2.9 considered authoritative now for future lookups 

It seems to me that referral NSes should also be cached tagged by
the query domain, which means 010a.example will be authoritative
for future lookups on 010a.example but nothing else.

						Masataka Ohta

---

From: "Roy Arends" <[email-masked]>
Date: Fri, 8 Aug 2008 09:04:18 +0200

Masataka Ohta <[email-masked]> wrote on 08/08/2008 

> for future lookups on 010a.example but nothing else.

Okay.

Where does the resolver get the address to go for lookups (other than 
010a.example) under example ?

Thanks

Roy

---

From: Ralf Weber <[email-masked]>
Date: Fri, 8 Aug 2008 09:05:04 +0200

Moin!

> in the DNS world are starting to suffer from "groupthink".
Ok so let me state my opinion as someone who argued against DNSSEC  
until last year hopefully does not fall into the "groupthink" theory.

The reason it changed is that we, or to be more precise a customer was  
hit by cache poisoning, and I had show up at there board and explain  
it to them.

So there question was and I raise it to the WG here:
Is there a technology that can prove that the answer I am getting from  
my DNS resolver is correct?
To my limited knowledge the only answer to the above question is:
Yes DNSSEC can do this.
But please tell me if you know another solution.

All other solutions proposed here so far only lower the chance of an  
attacker to poison the cache. But still with a 0.0001% chance the  
attacker might just have that lucky packet and poison your cache. So  
why I think it is good to do countermeasures none of them can assure  
me that I won't be hit by cache poisoning.

Also as stated elsewhere here, if someone today wanted to secure DNS  
between him and his business partners he could do it today without  
involving anyone else but him and the business partners (and this is  
happening).

Now having played around with DNSSEC for a year now I also must say  
that it does it's job, but with the current software and tools  
available it's simply not ready for widespread adoption. But this is a  
problem that can be solved, there is IMHO nothing wrong with the  
protocol, it's the tools that don't offer a user friendly way to  
deploy it.

So people should focus on getting the tools right.

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: Masataka Ohta <[email-masked]>
Date: Fri, 08 Aug 2008 16:12:57 +0900

> 010a.example) under example ?

Root nameservers, I'm afraid.

							Masataka Ohta

---

From: Duane at e164 dot org <[email-masked]>
Date: Fri, 08 Aug 2008 17:24:56 +1000

Ralf Weber wrote:

> hit by cache poisoning, and I had show up at there board and explain it
> to them.

Thanks for proving my point, people won't do anything until something
happens to them personally.

> Is there a technology that can prove that the answer I am getting from my DNS resolver is correct? 

Don't use someone else's resolver for starters, then reduce the TTL to
almost nothing and the chance of being effected is greatly reduced, of
course DNSSEC won't solve this problem without critical mass either so
even if you deploy or utilise DNSSEC you could still be effected by
cache poisoning.

-- 

Best regards,
 Duane

---

From: Duane at e164 dot org <[email-masked]>
Date: Fri, 08 Aug 2008 17:37:40 +1000

> Root nameservers, I'm afraid.

Oh so this is what Verisign had in mind when they announced they were
ramping up DNS response capabilities by 10 or 100 fold.

-- 

Best regards,
 Duane

http://www.freeauth.org - Enterprise Two Factor Authentication
http://www.nodedb.com - Think globally, network locally
http://www.sydneywireless.com - Telecommunications Freedom
http://e164.org - Global Communication for the 21st Century

"In the long run the pessimist may be proved right,
    but the optimist has a better time on the trip."

---

From: Ralf Weber <[email-masked]>
Date: Fri, 8 Aug 2008 09:43:42 +0200

Moin!

> happens to them personally.
Well this might happen more often now when the hackers do code that  
utilises Dan Kaminskys findings. And it just need to happen to the  
"right" people, as we see with IPv6 now that which is at least getting  
some traction after governments endorsed it.

> Don't use someone else's resolver for starters,
Hmm shall I stop offering resolving service to our customers, so that  
they can have their own ;-).

> then reduce the TTL to
True, but if A and B agree on using it they can at least secure the  
resolving of A and Bs domains, and if C, D and E join them when a TLD  
operator offers DNSSEC domains they will be also secured. So it will  
get better the more people do it, and the of non DNSSEC servers to  
speak to DNSSEC servers is at least defined (unless IPv6).

So long
-Ralf
---
Ralf Weber

---

From: Alex Bligh <[email-masked]>
Date: Fri, 08 Aug 2008 08:55:18 +0100

> even if you deploy or utilise DNSSEC you could still be effected by

That just goes to prove Ralf's point.
a) DNSSEC may be an ugly pig, but it's the only technology available today
   that PROVES the answer is correct (rather than 'greatly reduces' the
   chance of it being wrong)
b) Like most security measures, both sides need to be using it. It does
   little in practice at the moment because it isn't deployed (no critical
   mass, as you put it). This is not an argument not to deploy it
   ("my gun does not work because it is not loaded, therefore do not load
   it because it does not work"); if anything, it's the opposite.

Alex

---

From: Duane at e164 dot org <[email-masked]>
Date: Fri, 08 Aug 2008 18:27:28 +1000

> some traction after governments endorsed it.

Either that or they all migrated to recursors that weren't affected and
so that would mitigate any migration to DNSSEC.

-- 

Best regards,
 Duane

---

From: Duane at e164 dot org <[email-masked]>
Date: Fri, 08 Aug 2008 18:25:32 +1000

Alex Bligh wrote:

Ignore the fact of what DNSSEC can do, ignore even what it can't do, the
bigger hurdle to getting most people to deploy it will be the ease at
which they can set it up, other external factors will occur that may
change the rate of deployment but why people aren't actively trying to
make the process as simple as possible is beyond me.

-- 

Best regards,
 Duane

---

From: [email-masked]
Date: Fri, 08 Aug 2008 10:49:57 +0200 (CEST)

> so that would mitigate any migration to DNSSEC.

Your "recursors that weren't affected" don't exist. Using more entropy
(by using query ID randomization, port randomzation etc) reduces the
probability of spoofing - but as has been pointed out many times here,
this is not a *solution*. It mitigates the problem, it doesn't solve
it.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: bert hubert <[email-masked]>
Date: Fri, 8 Aug 2008 10:54:30 +0200

> this is not a *solution*. It mitigates the problem, it doesn't solve

Mitigation to the point where it will take a million years is effectively a
solution against spoofing.

People with sufficiently powerful computers could also break DNSSEC
security. 

This is equally likely to take a million years, although I haven't studied
the effective keylenghts that fit in DNS.

I'll repeat the mantra that DNSSEC protects against more than spoofing.

	Bert

---

From: Duane at e164 dot org <[email-masked]>
Date: Fri, 08 Aug 2008 19:29:53 +1000

> People with sufficiently powerful computers could also break DNSSEC

Or knowledge to factor asymmetric keys in a way no one else has thought
of would be able to perpetrate a DNSSEC attack much easier again.

Currently it's assumed that quantum computing would be needed to solve
this problem, however people assumed md5/sha1 didn't suffer any flaws
until it came out they were vulnerable.

Brute force is merely the slowest way to break keys, not the only way.

As for CPU hours needed to brute force keys:

http://en.wikipedia.org/wiki/RSA_Factoring_Challenge

A tad less than a million ;)

-- 

Best regards,
 Duane

---

From: Peter Koch <[email-masked]>
Date: Fri, 8 Aug 2008 11:39:48 +0200

> ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

note: neither RD nor RA, so this is a response from an authoritative
server.

> No glue. No additional section. 

There's nothing to glue here anyway.

> When cached, is 192.0.2.9 considered authoritative now for future lookups 

The question is whether "recursive servers" should continue to believe
the NS RRSet in the authority section more than what they had learned
by referral.  Insofar your question has two parts:
1) should the NS RR in the authority section be used for further lookups
   within the example domain?
2) If "yes" or the referral already had the same data, should "192.0.2.9"
   be used as an address no matter what the referral had provided as
   additional information (and, this time, originating from glue)?

If you say "no" to the first question, given all the parent/child
inconsistencies, I'd be scared by the operational effects of such a paradigm
shift.

> Will that NS record ever expire if a query is send once a day ?

This question of "auth server lock in" has been brought up by Antoin a
couple of times and is probably independent of the current discussion.
We know it "should not happen".

-Peter

---

From: Duane at e164 dot org <[email-masked]>
Date: Fri, 08 Aug 2008 19:46:45 +1000

Ondřej Surý wrote:

> Did you imagined how would this impact root and tld servers (well and
> registrars and others) servers
> if everybody would do this?

I highly doubt everyone will do this, then again everyone keeps going on
about end to end verification and the end user talking directly to
authority name servers would get rid of the whole issue over cache
poisoning altogether, wouldn't mitigate ISP attacks, but then again Paul
Vixie wasn't looking to fight that battle in a previous email thread.

Web caches/proxies for the most part have gone away, site owners that do
large amounts of hits didn't bemoan how bad that was, why do we still
cling to the notion that we must at all cost use DNS caches?

-- 

Best regards,
 Duane

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 8 Aug 2008 08:55:59 -0400

Dear colleagues,

Speaking as the one who has the current moderation token on this list,
I'd like to ask that we stop this thread.

Irrespective of what you personally think about DNSSEC, the liklihood
of its future deployment, its utility, the chances of it solving the
problems we have in the DNS, &c., the fact is that the WG adopted it,
and the specification is available.  Proposals for clarification,
discussion of what additional tools are needed (to the extent those
require protocol work), and even opposition to continued work in this
area are all on-topic for this working group.  Claims that DNSSEC will
never be deployed or that it is currently unworkable are _not_ on
topic here, because those claims have nothing to do with the protocol
itself.

Moreover, arguments that individuals are suffering from group-think
runs perilously close to the line of _ad hominem_ attack.  We have had
problems with that sort of discussion in the past, and I want to
remind everyone that we will not tolerate such attacks.  If you have a
problem with the protocol, feel free to discuss it here.  If you
instead have a problem just with what other people believe, then this
is not the right forum for your discussion.

Best regards,

Andrew

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

---

From: Otmar Lendl <[email-masked]>
Date: Fri, 08 Aug 2008 16:02:42 +0200

Paul Vixie wrote:
>   which is not to say

This is a good idea.

We really need a single checkbox "Automatically sign all my zones" in the 
nameserver implementations.

That, and not the protocol itself is holding up DNSSEC deployment. IMHO and 
all that.

But back to the namedropper charter:

  * Are there any open protocol issues which make such a "single checkbox"
    deployment of DNSSEC impossible?

  * In order to facilitate this, we need automatic DS generation in the
    parent zone, and means to deal with lost keys and other
    "crypto-emergencies". Is this all defined?

What I really want is a Debian upgrade which just asks for my confirmation 
to enable DNSSEC on my box without any further interactions.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933 //

---

From: Matt Larson <[email-masked]>
Date: Fri, 8 Aug 2008 19:37:51 -0400

> is not the right forum for your discussion.

I wasn't going to jump into this thread, but I can't let this message
pass without comment.

Your message prompted me to re-read Bert's original "group-think"
message and I find nothing inappropriate about it.  It was certainly
not "perilously close to the line of _ad hominem_ attack", nor was it
an attack at all.  I'd argue it was even on-topic, in that it
questions if we're all doing the best engineering we can.

How big is the worldwide DNS protocol engineering community?
Certainly no more than hundreds of people.  We have been breathing our
own DNSSEC exhaust fumes for a long time.  Personally, I find it
refreshing for someone with demonstrated clue to come in and politely
question things.

I've seen several creative proposals to deal with the recently
described cache-poisoning attacks and the urgency will spur further
creative thinking.  A hop-by-hop solution of adding more entropy would
go a long way to addressing this attack.  The lack of will I have
perceived recently in this working group to pursue non-DNSSEC
solutions frustrates me.  A lot of us have a lot invested in DNSSEC,
but shame on us as engineers if this is the only hammer in our toolbox
and we use it to hit every nail.

So I join Bert in asking everyone to keep an open mind, think
critically and keep engineering.

Matt

---

From: David Conrad <[email-masked]>
Date: Fri, 8 Aug 2008 18:07:51 -0700

Matt,

> questions if we're all doing the best engineering we can.

There is a difference between questioning whether we're doing the best  
that we can and implicitly accusing some number of us of intellectual  
laziness (at best) or actual dishonesty (at worst).

As you may be aware, I am no fan of DNSSEC (to put it mildly) and have  
actively argued caution on spending resources on deploying DNSSEC in  
numerous venues because I felt the cost outweighed the benefits it  
would bring towards ameliorating the risks inherent in the DNS and  
felt those resources would be better applied to things like routing  
security.  I have since changed my mind.  The cost of deploying DNSSEC  
is high, however the risk is greater than I originally estimated,  
hence I believe the benefit is worth the cost.  I still feel  
significant work needs to be done to DNSSEC to make it an effective  
defense, but it is clear to me that it is the right direction to go  
and we should go that direction sooner rather than later.

Others may feel differently.  However, I would not label those  
individuals nor would I accuse them of engaging in some deprecatory  
psychobabble buzzword of the day.  Such labeling and accusations  
needlessly polarize discussions, which I feel does not contribute  
towards forward motion.

But maybe that's just me.

> A hop-by-hop solution of adding more entropy would
> go a long way to addressing this attack.

This particular instantiation of the attack, maybe (how do you protect  
against on-the-datapath spoofing with hop-by-hop entropy addition?).   
However, again, it is treating the symptoms, not the disease.  How  
many times does the DNS community have to be bitten by the same  
fundamental bug before we finally squash that bug?  Do you or Bert or  
any of his <aol>Me too!</aol> supporters think the problem is going to  
get better over time with computers (and hence zombies) and networks  
constantly getting better/faster/more numerous?

> The lack of will I have
> solutions frustrates me.

I'm sorry, what lack of will are you talking about?  I seem to recall  
a number of drafts being proposed and discussed that are not DNSSEC- 
related.  Forgery-resilience and dns-0x20 are two examples.  I have  
seen numerous people ask for solutions other than DNSSEC that address  
the fundamental weakness in the DNS. I myself would love to see an  
alternative to the bloated pig of a protocol, yet most of what I have  
seen appears to add even more fragility than DNSSEC and/or doesn't  
address the fundamental problem.

> critically and keep engineering.

Suggestions of keeping an open mind and thinking critically should  
also be applied to those who do not want to implement DNSSEC (for  
whatever reason).

Regards,
-drc

---

From: Ben Laurie <[email-masked]>
Date: Sun, 10 Aug 2008 03:07:00 +0100

> Anyone have any idea how many credit card transactions per second occur?

Far fewer than domain lookups.

-- 
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

---

From: [email-masked]
Date: Sun, 10 Aug 2008 04:21:36 +0000

> >>	changes are instantly available.

	these days, i am thinking Mark is just baiting trolls.
	caches are too useful to abandon outright, but i'm pretty sure
	rethinking them is a great idea.

--bill

---

From: Duane at e164 dot org <[email-masked]>
Date: Sun, 10 Aug 2008 16:24:54 +1000

> 	rethinking them is a great idea.

Caches seem to be the majority of concern in the last 3 to 4 weeks, I
doubt anyone would disagree they can be useful just like web caching can
be useful.

The question is does the pros outweigh the cons?

If shared caching at the ISP level is abandoned in favour of moving them
closer to the end user, either on their computer or on the LAN but isn't
accessible usually from beyond the LAN, would that not solve the
majority of concerns currently being expressed?

-- 

Best regards,
 Duane

---

From: Alex Bligh <[email-masked]>
Date: Sun, 10 Aug 2008 09:50:35 +0100

> majority of concerns currently being expressed?

I think ISP-level caching has only been targeted here because it's the most
obvious way to obtain maximum impact for a cache poisoning attack. However,
unfortunately, it's not the only way to use cache poisoning techniques.
Not using ISP-level caching means (aside from the increased load):

  1. Lookups would more often take place from behind a NAT. This can reduce
     entropy and make any given attack easier. Thus remember unlike many
     attack profiles, sticking a shared cache behind a NAT only serves
     to make things worse.

  2. For specifically targeted attacks (e.g. where what Mallory really
     wants to do is poison the DNS for a particular mail smarthost), it
     gets no more difficult.

Let's also remember that no intermediate caching at all means lots
of additional load and complexity on the end user device (as full caching
and recursion needs to be implemented there) and/or greater latency,
as the recursive element requires lookups from "." upwards go over
an end user link. Consider how, for instance, internet browsing on a mobile
phone would be affected by a total absence of intermediate caching servers.

To return to the original angels and pins discussion, when this group
was first busying itself designing just how the lipstick might be applied
to the DNSSEC pig, one of the original design criteria was that the security
worked in such a way that it was transparent to dumb caches between
authoritative server and end resolver. Solving integrity problems without
dumb caches being the ones providing the data (i.e. assuming resolver
could always talk directly to the authoritative server) would have been
far easier, and would no doubt have resulted in a far less ugly beast
of a protocol. If we were wrong to include caching as a design criterion
at all (i.e. if we can ditch it now), then yes, that is seems consistent
with your view of DNSSEC. I don't, however, think dropping caching is
a realistic option, either for vanilla DNS or for DNSSEC or any substitute
thereof.

Alex

---

From: Duane at e164 dot org <[email-masked]>
Date: Sun, 10 Aug 2008 19:07:25 +1000

>     attack profiles, sticking a shared cache behind a NAT only serves

I fail to see how this would apply, the reason for randomising the ports
was for publicly accessible caches, such that ISPs run, which can be
queried by the attacker and also for the attacker to send fake replies
at the same time.

If the attacker can't send requests and replies they would need to be in
the path to alter things.

-- 

Best regards,
 Duane

---

From: Florian Weimer <[email-masked]>
Date: Sun, 10 Aug 2008 11:16:57 +0200

> 	private key is on all slaves.  The crypto hardware guys

Crypto accelerators for RSA are dead.  You can buy four 64x64 -> 128 bit
multipliers supporting a rate of more than 0.5 billion multiplications
per second each for 150 EUR.

> 	become "set and forget" as the tools develop.

It's not just the tools.  It requires a change of minds, too.  For a
long time, DNSSEC operations were based not on classic DNS approaches,
but on the CA/PKI model (involving off-line keys, different registration
requirements, audit trails etc.).  However, for obvious reasons, hardly
anybody wanted to deploy it this way.

---

From: Alex Bligh <[email-masked]>
Date: Sun, 10 Aug 2008 10:22:27 +0100

--On 10 August 2008 19:07:25 +1000 Duane at e164 dot org <[email-masked]> 
wrote:

>>  1. Lookups would more often take place from behind a NAT. This can
>>  reduce entropy and make any given attack easier. Thus remember unlike
>>     many attack profiles, sticking a shared cache behind a NAT only
>>     serves to make things worse.
>

Some NATs (e.g.) have the behaviour of using a constant source port by
DNS, or a source port incrementing by 1 for each query (which is just
as bad). So, if the caching resolver is behind that NAT (or more
accurately NAPT) then simply spoof the NAT's external IP address and
guess the source port it used (using that as your destination port).
The NAT then helpfully rewrites this to the randomised source port
inside the NAT. Roy Arends has been doing a survey of NAT behaviour.
I'm not sure whether he's demonstrated poisoning through broken NAT
with a randomised source port cache in the lab, but I don't think it
should be hard; a NAPT which rewrites the source port to a constant
value effectively removes all the entropy given by the recent bind
patches. I mentioned this on namedroppers a while ago but I
was being somewhat cryptic as the nature of the attack itself wasn't
public then.

Alex

---

From: Alex Bligh <[email-masked]>
Date: Sun, 10 Aug 2008 10:31:41 +0100

--On 10 August 2008 10:22:27 +0100 Alex Bligh <[email-masked]> wrote:

> as bad).

I should have added that whilst non-broken NATs don't make things worse
(*), they also don't make things better.

* = though arguably anything that compresses the

> the path to alter things.

The data path being directly attacked is that from the caching server
(via the NAT) to the authoritative server (which is partly outside the NAT)
not between the stub resolver and the caching server (which is entirely
inside the NAT).

Alex

---

From: [email-masked]
Date: Sun, 10 Aug 2008 13:07:23 +0200 (CEST)

> queried by the attacker and also for the attacker to send fake replies

At least for the ISP *I* work for, our publicly accessible caches are
accessible for direct recursive queries only from IP addresses within
our own AS, not from the Internet at large.

There are of course lots ways an attacker can *indirectly* get queries
to be made from IPs within our AS (see for instance Dan Kaminsky's
presentation). On the other hand, we implement RPF checking for our
customers, so an attacker can *not* easily get our customers to spoof
addresses and thus participate in the poisoning part of the attack.

---

From: Ben Laurie <[email-masked]>
Date: Sun, 10 Aug 2008 12:30:10 +0100

> (*), they also don't make things better.

Not so, actually. If the NAT does random port assignment, then the 
resolver's assignment can be predictable.

---

From: Alex Bligh <[email-masked]>
Date: Sun, 10 Aug 2008 13:01:26 +0100

Ben,

> resolver's assignment can be predictable.

Yep quite possibly. My post was precaffeinated and I was referring to
resolvers that were fixed-up, i.e. unpredictable. In practice though, I
suspect (Roy will know better) that a NAT seeing traffic from a single
internal (src IP, src port) tuple will continue to map that to a single
external (src IP, src port) tuple because, unless it's doing deeper
inspection than normal, it doesn't know which packets form separable
conversations. So the improvement would only occur where the broken
resolver used a non-constant but predictable port, which is the minority of
cases.

My point was that one should not think one can just stick a caching
resolver behind a NAT device and suddenly achieve immunity from this
particular poisoning attack. I presume you agree with that?

Alex

---

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

> particular poisoning attack. I presume you agree with that?

Depends on your resolver, as you explained above.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Aug 2008 15:41:40 +0000

> From: [email-masked]

may i ask that you write an FYI RFC for dnsop explaining this policy with
special emphasis on (1) how you did it, (2) how easy it was to do it, and
(3) how beneficial it's been that you did it.  many of your coopetitors
across the industry are not yet following in these excellent footsteps.

(and it won't make you safe from spoofing if you have a dialup or enduser
population who can be infested with bots, or if you have SMTP servers who
can be triggered to make DNS requests for an attacker with very fine
timing, but this kind of network hygiene certainly limits the scope of
the problem.)

(if you also enforce BCP38 against your customers, you might mention this
in passing in your FYI RFC, again explaining how easy it was and how much
cost and/or benefit you get from it.)

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 10 Aug 2008 08:38:41 -0700

"Caching" is not the currently-discussed problem: it is a too-brief 
shorthand for the currently-discussed problem.

A better problem statement might be "caches (a) that can be easily 
poisoned and (b) from which data that will be trusted by compliant 
resolvers will be served". This WG seems to be trying to make (a) 
harder to make the attack harder.

We haven't spent much time analyzing how to fix (b), which might give 
us a much better fix. Assuming a poisoned cache, if either the poison 
is never emitted from the cache, or if resolvers stop believing 
emitted poison, the attack fails completely.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Mon, 11 Aug 2008 02:52:42 +0000

> majority of concerns currently being expressed?

	if your caching at all (near/far) your caching.
	if you keep zero state "...stop caching any DNS data... (Mark Andrews)"
	then you are not.

	my gentle assertion was that caching is valuable, should be kept/rethought.
	theevents of the day are only tangential to cache design.  -IF- caching is
	to be re-thought, then it should be carefully thought out, not a twitch
	reaction to a (perceived) threat.

--bill

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 12 Aug 2008 16:40:48 +0200 (CEST)

>   * Are there any open protocol issues which make such a
>     "single checkbox" deployment of DNSSEC impossible?

The need to communicate off-line or at least out-of-protocol with
the parent zone administrator when you need to change/roll-over your
KSKs -- this is probably what you meant by "automatic DS generation
in the parent" in your next item.  Although this might be seen as
similar to making changes to the NS RRset, the initiative is
triggered by a timer and not by administrator action, which is a
considerable change from previous operational practice.

There's also the issue of trust anchor maintenance, but that's being
worked on, as I understand it.

When reading some of the DNSSEC RFCs, I've sometimes come away with the
understanding that the authors think that "zone administrators needs to
sign the zone on an off-line machine to maintain a sufficiently high
level of security".  If I've understood correctly, that's completely at
odds with the goal of having a fully automated feature with a checkbox
for "maintain (generate and periodically roll) ZSKs and KSKs and sign
and re-sign all my zones automatically".  My guess is that only TLD and
root zone maintainers would care enough about their zones and keys to
bear the level of pain involved in implementing complete off-line
signing ("zone transfer via sneakernet").  For a simple leaf zone master
name server administrator, is there a good reason he needs to care more
about his DNS private keys than about the protection and host security
on the master name server (which might be "hidden", i.e. not in the NS
set)?  (OK, that probably wasn't a protocol issue...)

Then there's the aspect of having the root signed, which is really
needed in order to alleviate the pain of maintaining the trust
anchors, a pain which is to be felt on all the recursive name servers
who want to get the benefits of DNSSEC.  Even if it appears to be a
non-protocol issue does not make it any less important in the view of
deployment.

Best regards,

- Håvard

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Aug 2008 01:15:18 +1000

> considerable change from previous operational practice.

Which, in practice, may not be necessary though I would expect that
TLD's will continue to rollover keys

For end user zones the only key roll overs may be emergency key
rollovers.
 
> When reading some of the DNSSEC RFCs, I've sometimes come away with the=
> 
> understanding that the authors think that "zone administrators needs to=
> 
> level of security".  If I've understood correctly, that's completely at=
> 
> and re-sign all my zones automatically".  My guess is that only TLD and=
> 
> signing ("zone transfer via sneakernet").  For a simple leaf zone maste=
> r
> name server administrator, is there a good reason he needs to care more=
> 

The protocol had to support completely offline keys.   The actual
practice is up to the zone administrator.
 
> non-protocol issue does not make it any less important in the view of

But it's lack isn't a show stopper either.
 
> - H=E5vard

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 12 Aug 2008 18:02:35 +0200

Havard Eidnes wrote:
> in the parent" in your next item.

RFC 5011 offers a way to do key rollover without out-of-protocol 
interactions, as well as most other common trust anchor operations.

The intention of 5011 certainly wasn't "parent to child" but "island
to island" secure entry point management.

I'm in brainstorming mode, so: Why can't 5011 be used by TLDs instead of
extending the Registry/Registrar protocol? That change takes time
and puts the Registrar into the critical path for DNSSEC rollout.

Yes, this can be 100% automatic: a test-signing of a zone should not
automatically result in a signed DS in the parent, which could prove
fatal if the zone reverts to being unsigned. But couple it with an email
loop "We have detected your key, do you want us to include DS records in
the TLD zone? Please click YES or NO" to the domain owner this might
be "good enough".

> level of security". 

Correct, and that makes a lot of sense for TLDs and domains used for 
e-commerce.

 > If I've understood correctly, that's completely at

Just look at how people deal with SSL and ssh server keys. I guess less 
than 5% of the https: sites don't have the key (+passphrase, if any) on the 
webserver. (Back in my old job, when SSL was new, we had to enter the 
passphrase on server reboots/restarts. What a hassle. I strongly doubt this
is still done in most installations.)

ssh server keys? I have yet to see a server that doesn't store them on 
disk. (IIRC, the sshd server even regenerates temporary server keys every
few hours. This completely transparent to the admin and user.)

So no, I don't think that your average name server admin will care more
about his dnssec keys than the overall security of this servers.

For ssh, the "ask on first contact, store and YELL if it changes"-security 
model seems to be really popular. Phil Zimmerman's zPhone uses the same idea.

Can't the same principle work for DNSSEC child->parent provisioning?

> non-protocol issue does not make it any less important in the view of

Getting the root signed is, of course, the jackpot.

If we can get the registry/registrar interface and the registrar/customer 
interface out of the critical path, that might make getting TLDs 
DNSSEC-enabled a lot easier and thus faster. If TLDs get serious with 
DNSSEC, then the task of secure entry point management for resolvers 
becomes a *lot* easier.

Once again, from a pure protocol point of view, is 5011 enough to cut
out the registrar from the DNSSEC provisioning loop?

I'm sure there are pitfalls (e.g. how to handle emergency key rollovers).

/ol

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 12 Aug 2008 12:46:03 -0400

[no hat]

> and puts the Registrar into the critical path for DNSSEC rollout.

In at least some cases, two reasons:

1.  The EPP extension for DS management has been ready for ages.  So
there's very little work to do there anyway.  It's in RFC 4310.  (Of
course, some registries aren't using EPP, so it's not relevant to them.)

2.  Many TLDs aren't actually allowed to talk to the party that has
administrative control of the domain.  In the ICANN world, for
instance, registries may only speak to the registrar, and not the
registrant.  This is admittedly a policy and not a technical reason,
but it's a reason anyway.

A

---

From: Otmar Lendl <[email-masked]>
Date: Tue, 12 Aug 2008 23:03:39 +0200

> course, some registries aren't using EPP, so it's not relevant to them.)

It's not the protocol extension specification, which is the problem.
It's getting the registrars to actually implement it and support it in
their customer-facing interfaces. Bringing the registrar into the loop
also might means legal work: T&Cs, liability questions, ...

> but it's a reason anyway.

Acknowledged, but luckily that doesn't apply to .at.

/ol
-- 
// Otmar Lendl <[email-masked]>, T: +43 1 5056416 - 33, F: - 933
// nic.at Internet Verwaltungs- und Betriebsgesellschaft m.b.H
// http://www.nic.at/  LG Salzburg, FN 172568b, Sitz: Salzburg

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Aug 2008 09:26:57 +1000

> also might means legal work: T&Cs, liability questions, ...

	They are already in the loop.  They are already exposed.
	This happens the moment they attempt to change any record
	in the parent zone.  There is no difference between
	changing/adding a NS, A or AAAA records and DS records.

	You can do as much damage with any of them.

	Do the wrong thing and the zone is not visible or it is
	handed to a attacker.  DS records do not change that exposure
	in anyway.

	This is also a strength of DNSSEC.  It doesn't change the
	trust model.  The same person that is authorised to change
	the NS, A and AAAA records is also the same person that
	changes the DS records.

---

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

[no hat]

On Tue, Aug 12, 2008 at 12:46:03PM -0400, Andrew Sullivan wrote:

> registrant.  

Someone kindly reminded me that I should have been clearer about scope
here: the registries of which I'm speaking there are only the gTLDs.
Some ccTLDs have an agreement with ICANN but aren't subject to such
rules; also, of course, many (all?  I can't think of an exception at
the moment) sTLDs have a community arrangement that ensures the
registry and registrants have a direct relationship along side the
relationship between the registrant and registrar.

Sorry for any confusion,

A