Subject: Re: [dnsext] Re: Protecting caches?

From: Nicholas Weaver <[email-masked]>
Date: Wed, 1 Oct 2008 03:40:00 -0700

On Sep 30, 2008, at 9:21 PM, Danny Mayer wrote:
>
> I don't altogether agree with this. DNSSEC will only protect up to the
> resolver. What people keep forgetting about in this discussion is that
> what you are really trying to protect is the application, most  
> likely a
> browser, from receiving bad answers, and therefore preventing the DNS
> resolver from returning bad answers is not enough. The application is
> one or two hops away from the resolving DNS. Some systems like Windows
> uses a DNS cache to cache answers on top of everything else. As long  
> as
> getaddrinfo() and friends cannot request and receive a DNSSEC
> "certified" response you are dropped right back to the original
> problems. Worse than that, if you manage to poison the answers in the
> resolver, you also poison the on-system cache AND the application. How
> many applications request new answers once they have one?  
> getaddrinfo()
> and friends don't even tell you what the TTL on the answers you do get
> so you have no way of deciding when to re-request an answer in the  
> first
> place even if the address was originally valid.

The getaddrinfo() relies on the host's stub resolver.  If the host  
stub resolver respects DNSSEC, you do get protection up to  
getaddrinfo(), because I think most implementations will silently fail  
when DNSSEC fails.

This is generally regarded as a primary feature, the implementation  
"fails safe" but with no way to override unless a  
getaddrinfo_no_DNSSEC() function is added in the API.  This is also  
considered a primary bug when you talk to Eric Rescorla, as SSL/TLS  
had this behavior initially and it proved problematic: most "failures"  
were benign.

The fundamental problem with DNSSEC is how the application USES  
getaddrinfo():  it either trusts the name or it doesn't.

If its an end-to-end secure application, it never actually trusted the  
name, because the application doesn't trust the network, so DNSSEC  
bought nothing.  Zippo.  Zilch.  Nada.

If its not end-to-end secure, it trusts the name as well as the  
network.  This is a BIG problem if the resolver is poisoned by an out- 
of-path adversary (eg, blind cache poisoning, a corrupted recursive  
resolver, etc).

But it is not a big problem if the attacker is a man-in-the-middle:   
Yes, the attacker can MitM the DNS, but can also MitM the application  
in almost all cases, as the naming path and the data path are  
convergent in practice in almost all cases.

Thus from a cryptographic security viewpoint, DNSSEC is exactly  
backwards: the PRIMARY threat model addressed, a man-in-the-middle, is  
not addressable at the naming operation, but must be addressed at the  
application or application transport layer.  Period.

The secondary problem is one of deployment:  Both the stub resolvers  
(Microsoft, Apple) need to be updated to check DNSSEC, the recursive  
resolvers must pass the information unchanged or check DNSSEC, and the  
authoritative servers must provide DNSSEC, the latter being a big  
pain, in many ways due to trust anchor issues.  eg, see Clayton's rant  
on trying to set up a DNSSEC-supporting domain: http://www.lightbluetouchpaper.org/2008/09/29/root-of-trust/

This is why I believe that the problem with out-of-path adversaries  
(blind cache poisoning) needs to be addressed in the resolvers,  
without changing the protocol and without changing the authorities.   
And I believe there is a lot more than just "more entropy" which can  
be done.

--
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: Eric Rescorla <[email-masked]>
Date: Wed, 01 Oct 2008 11:15:57 -0700

At Wed, 1 Oct 2008 03:40:00 -0700,
> "fails safe" but with no way to override unless a  

And my Kiboizer alerts...

> had this behavior initially and it proved problematic: most "failures"  

To expand on this point a little bit wrt TLS: The original assumption
when SSL/TLS was designed was that validation failures (name
mismatches, expired certs, unknown CAs, etc.) should be treated as
hard failures. For instance, IE behaved this way.  However, it quickly
became apparent that a lot of such failures weren't attacks, but
rather self-signed certs, configuration errors, etc., and the vendors
were forced to put in the ability to override the checks.

It's not clear how this experience transfers to DNSSEC, of course,
since SSL/TLS provides benefits (confidentiality) against passive
attacks even if the server uses a self-signed cert, whereas DNSSEC
does not, so there's less incentive to deploy in a weak way. However,
that still leaves open a variety of misconfigurations: all of these
cryptographic techniques invert Postel's dictum about being liberal in
what you accept.  so if there is any reasonable base rate of
misconfigurations, e.g., signatures outside their validity windows,
then there's going to be a real issue in determining how to handle
verification failures, especially with the limited channel available
between the resolver and the user.

-Ekr

---

From: [email-masked]
Date: Wed, 1 Oct 2008 23:08:22 +0000

> between the resolver and the user.

	the other option is to "fail open" ... eg. things are 
	just like they are now.

--bill

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 01 Oct 2008 18:40:30 -0700

> 	the other option is to "fail open" ... eg. things are 

This seems plausible in some cases but not others. I.e., if the 
signature is expired, that's probably fine. However, if the
signature is totally broken, doesn't accepting it kind of obviate
the point of DNSSEC?

-Ekr

---

From: [email-masked]
Date: Thu, 2 Oct 2008 01:39:55 +0000

> signature is totally broken, doesn't accepting it kind of obviate

	well, i'd not accept it - I'd flag it as "not validatable" and
	proceed w/ resolution.  

	sure - but then we have dns working at the same level as
	today.  I'd rather have the DNS continue to work, for some
	level of work, than for it to fail and be dependent on someone
	else to correct the errors.  Granted, this might be a tuneable
	knob that some operational enclaves will want to set to fail closed,
	but a "least surprise" default seems to be to fail open.

	a default of servfail on validation failure seems like a nearly
	insurmountable hurdle for adoption.

--bill

---

From: [email-masked]
Date: Thu, 2 Oct 2008 12:37:33 +0000

> getaddrinfo(), because I think most implementations will silently fail  

	if this is the case, then DNSSEC is a non-starter.
	actually, i've yet to see a validator be stateless enough
	to be able to be wrapped into a system call.

	remember, resolution and validation are different things.
	getaddrinfo() is a resolution tool, an ephemeral system call
	that maintains no state.

	validation depends on resolution working - so as to be able to 
	get the data needed to perform the function.  and validation
	requires state and (to be effective) a cache.

> had this behavior initially and it proved problematic: most "failures"  

	regarded as a feature by whom? 

> getaddrinfo():  it either trusts the name or it doesn't.

	again, you are conflating resoultion w/ validation.
	getaddrinfo() returns data ...  w/o any warrantees on
	accuracy or integrity.   if you want that, then you have
	to involke a validator. the "trust" does not lie w/ the systemcall.

> bought nothing.  Zippo.  Zilch.  Nada.

	unless the application under discussion is DNS.
	and even then, DNSSEC doesn't care abt trusting the
	network or the intermediate nodes that might hold the
	data.

> application or application transport layer.  Period.

	i think i misunderstand your terms here:

	naming operation
	application
	
	DNSSEC protects the applicaiton DNS.  Trust is not transitive
	and can not be presumed to map to other applications. The best
	DNSSEC can do is assure the data received was received intact
	from a known source. what SSH or SMTP or NTP does with the
	data returned from a resolution request is up to that application,
	not the DNS.

> on trying to set up a DNSSEC-supporting domain: 
> http://www.lightbluetouchpaper.org/2008/09/29/root-of-trust/

	its not that hard - many folks are signing their data.
	i remain unconvinced that stub resolvers need to be updated.
	I belive validation can and should be done asyncronously from
	resolution.  And it is true that a validator API is sadly 
	lacking - although there have been several efforts over the 
	years to bring something forward.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 02 Oct 2008 15:47:35 +0200

Bill,

> 	years to bring something forward.  

Can you point us to some of these?

Too bad the IETF does not "do APIs". (Except when it does, of course.)

--
Shane

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 2 Oct 2008 08:10:02 -0700

> 	regarded as a feature by whom?

Discussions in this mailing list, I can't remember where.

> 	to involke a validator. the "trust" does not lie w/ the systemcall.

I don't get the distinction.

Pardon my ignorance, but the resolution process in DNSSEC should  
include validation.  Unless the recursive resolver is told otherwise,  
it validates DNSSEC signatures before returning a value.  Unless the  
stub resolver is misconfigured, it validates DNSSEC signatures before  
returning the value.

getaddrinfo() is a wrapper around a call to the local stub resolver.   
Thus if the stub resolver validates as part of the lookup process,  
getaddrinfo() validates as part of the lookup process.  ANd if you  
trust the operating system, you can trust the operating system's stub  
resolver to do this properly.

> 	network or the intermediate nodes that might hold the

How many end-host lookups are "DNS is the application"?  Almost none.   
DNS is a tool used by the end application to map a (usually human  
readable) name into a set of addresses, for communication with those  
addresses.  DNSSEC is a way for the end application to have assurance  
that the name to address mapping is legitimate.

> 	data returned from a resolution request is up to that application,

Actually, trust is transitive all the time.  Your application trusts  
the underlying operating system, for example.

The problem is that in 99.9999% of the cases, if the application  
transitively trusts the DNS name it gets from the host operating  
system, it also transitively trusts the network itself.  And if the  
application did not trust the DNS name, it does NOT trust the network.

> 	years to bring something forward.

Why should validation be done independently?  Why should separate  
validation be done at all?

In fact, I will argue that independent validation is EXACTLY the wrong  
answer for almost all applications:

If the application needs to independently validate the name, its not  
going to bother, and SHOULD NOT be changed to bother: its going to do  
a cryptographic validation directly to the address on the other side:  
TLS, IPSec, ssh, whatever, because such validation not only ensures  
that the name is correct, but that the transport is correct and has  
integrity.

For such an application, separate name validation is useless, and will  
not be done.

And if an application doesn't bother independently validating the  
name, its not going to bother doing end-to-end cryptography either, so  
it gets completely decimated by a MitM, and a Man-in-the-middle on the  
naming traffic is almost always on the same path as a man-in-the- 
middle on the data traffic.

In fact, the big use for DNSSEC, I believe, is NOT for securing DNS  
names against a man-in-the-middle (a useless endeavor), but as a "item  
respository with cryptographic integrity", where NON-naming  
information is stored.

Not because its a particularly good one (the size limits make it a  
particularly BAD one in fact), but because there is no other off the  
shelf existing secure distributed database code that is readily  
avaliable, unlike transport .

And for this, the API could just be a piece of resolver code as a  
library in the application or a standalone application, like TLS and  
ssh are today for anyone who uses it.  And would want to be this way,  
because the desired policies on failures etc should not be relying on  
the end host's stub resolver code anyway.

---

From: Danny Mayer <[email-masked]>
Date: Wed, 01 Oct 2008 00:20:48 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Andrew Sullivan wrote:
> No hat.
> 
> Dear colleagues,
> 
> In the discussion around forgery resilience so far, I've seen some
> discussion on how to detect cache poisoning attempts, and some
> discussion on how to foil the attack itself by reducing the ability of
> the attacker to send bad data to a resolver.  (I've also seen the
> observation, several times, that DNSSEC will solve these problems
> anyway, so we should concentrate on deploying that; that's an
> operational problem now, and not on-topic for this list.)

I don't altogether agree with this. DNSSEC will only protect up to the
resolver. What people keep forgetting about in this discussion is that
what you are really trying to protect is the application, most likely a
browser, from receiving bad answers, and therefore preventing the DNS
resolver from returning bad answers is not enough. The application is
one or two hops away from the resolving DNS. Some systems like Windows
uses a DNS cache to cache answers on top of everything else. As long as
getaddrinfo() and friends cannot request and receive a DNSSEC
"certified" response you are dropped right back to the original
problems. Worse than that, if you manage to poison the answers in the
resolver, you also poison the on-system cache AND the application. How
many applications request new answers once they have one? getaddrinfo()
and friends don't even tell you what the TTL on the answers you do get
so you have no way of deciding when to re-request an answer in the first
place even if the address was originally valid.

Danny

---

From: Edward Lewis <[email-masked]>
Date: Mon, 6 Oct 2008 11:08:02 -0400

>signature is totally broken, doesn't accepting it kind of obviate

Smoothing over bumps in security is a fine way to let operational 
issues fester unnoticed.  Absent proof of widespread, successful, 
attacks on DNS caches today (I am told there are many attacks that 
don't get air time), I bet that the majority of DNSSEC "positives" 
will be the result of misconfigurations.

A common one will be maladjusted clocks on verifiers, especially if a 
user machine attempts to take validation into it's own hands.  I base 
this on our experience in the early workshops before NTP was on all 
our machines (because we were so burned by time).  (I once had a 
machine that had the right time of day and month/day, but the year 
was off by one.  That took a lot of squinting at screens and paper 
before I noticed it.)

There are five entities involved in an canonical verification - user, 
ISP, root, TLD, enterprise.  While errors may be rare, I bet errors 
will still outpace attacks.  Especially after DNSSEC has been running 
for some time.

So failing open is probably a bad strategy, neglecting the security 
implications, for operational reasons much less obviating the point 
of DNSSEC.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Never confuse activity with progress.  Activity pays more.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 06 Oct 2008 20:55:50 -0700

At Mon, 6 Oct 2008 11:08:02 -0400,
> will be the result of misconfigurations.

I totally agree with this claim, but if your resolver 
accepts bogus signatures, then what's the point of having
signatures at all?

-Ekr

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Oct 2008 08:08:49 -0400

>accepts bogus signatures, then what's the point of having

Depends on the exact meaning of "accepts."  For normal use, a bogus 
signature should never be shrugged off or it is useless to invest the 
time in the entire franchise.  The only time data with a bogus 
signature should be "accepted" is in a diagnostic mode, testing to 
determine if the bogosity is the result of an operational error or 
indeed a malicious attack.  Accepted in the latter case means "is 
inspected."

I think the result of DNSSEC is binary to an application - got a 
response[0] or didn't.

[0] - includes NXDOMAIN and all other results.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Oct 2008 12:56:19 -0400

>accepts bogus signatures, then what's the point of having

Perhaps my "is a fine way" and "fester unnoticed" weren't taken 
sarcastically enough. ;)

If data accompanied by a signature that is proven to be invalid is 
accepted at all, then the effort is a waste.  And what I meant was, 
in addition, if you do you are enabling poor operational practices 
and other poor habits.

The only time a DNS verifier/iterator should pass on data that failed 
verification is within a debugging/reporting context.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 07 Oct 2008 13:11:53 -0700

At Tue, 7 Oct 2008 12:56:19 -0400,
> Perhaps my "is a fine way" and "fester unnoticed" weren't taken 

Either that or my IQ is low today. I was totally baffled by it.

> verification is within a debugging/reporting context.

I tend to agree with this, but isn't the consequence going to be a lot 
of hard failures due to otherwise innocuous misconfigurations? 

-Ekr

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Oct 2008 16:25:21 -0400

>of hard failures due to otherwise innocuous misconfigurations?

Yeah.

How do you decide between a bogus signature due to maliciousness and 
a bogus signature due to misconfiguration and a bogus signature due 
to a disagreement over policy, etc.?

(Perhaps I should add, if there's just one signature to consider then 
it's cut and dry.  If there are multiple signatures, if one works we 
are cool, if none work there's trouble.  That is one way around 
disagreement over policy/some misconfigurations, etc.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 16:51:42 -0400

> of hard failures due to otherwise innocuous misconfigurations? 

Only if poor operational practices are observed by folks running
authority servers and resolvers.

E.g. the notion of "fire and forget" as an acceptable method of making
changes to dnssec-critical systems.

If someone runs any dnssec component, they would be well advised to
stage changes with some kind of testing suite,
to verify that the proposed change doesn't break the thing they operate.

So,  I would categorize, respectively, "a lot", "hard failures", and
"otherwise innocuous" as "subjectively",
"for the incautious sorts", and "you mean careless". :-)

Seriously, though, the onus is on the operators of authority servers,
and to a slightly lesser degree, validating resolver operators,
to ensure that the bits they run, don't break when they start doing dnssec.

And, the end-user really, really should never be able to disable the
validation. Ever. For anyone. For any reason.

Brian

---

From: Edward Lewis <[email-masked]>
Date: Tue, 7 Oct 2008 17:14:01 -0400

>to ensure that the bits they run, don't break when they start doing dnssec.

I believe the reverse will be true.  When a web client user 
encounters an error due to a DNSSEC thumbs down, they call the ISP 
help desk (ie, "the Internet is down").  The ISP will "pay" when 
there are errors, therefore that's where the onus matters.

The authority servers (root, tld, enterprise) all have 
responsibilities to make sure the DNSSEC is set up right, true.  It 
is up to the ISP to make sure the validating cache server has the 
right keys and to have a help desk that can deal with the support 
calls.  Worse for the ISP, there are multiple authority servers were 
mistakes can be made for just one validation chain, as well as user 
(ISP customer) mistakes.

(One unwritten [until now] assumption is that the costs for help desk 
are considerable when the calls roll in.)

The onus isn't only on the authority servers, but they do need to do 
things right.

>validation. Ever. For anyone. For any reason.

I don't know about that.  If the problem is more likely to be due to 
an operational error then it is more likely not to be dangerous to 
turn off DNSSEC.

'Course, I am making a wild assumption that the incidence of "fat 
fingering" is greater than actual attacks.  This assumption is not 
supported by any facts.

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 7 Oct 2008 14:21:04 -0700

On Oct 7, 2008, at 2:14 PM, Edward Lewis wrote:

> (One unwritten [until now] assumption is that the costs for help  
> desk are considerable when the calls roll in.)
>

If this is a solution, NO ISP will install a validating DNSSEC  
resolver.  Most of the key-management F@ups are the fault of the  
authorities, not of the resolvers.  In fact, the whole idea of the  
root of trust is that beyond just making sure the CA-equivelent keys  
are OK, the resolver must be able to find everything out.

That alone is a huge incentive to be "last mover":  A good ISP can  
harden their resolver against out of path attacks to an effectively  
arbirtary level.  And against in-path attackers, the customer's  
traffic is also screwed, not just the naming.

So if DNSSEC results in more tech support calls because items don't  
resolve, through fault of the authorities and not the ISP's resolver,  
no ISP in its right mind would support it!  Or if support is mandated,  
it will be set to "well, fail open anyway so it doesn't matter, but we  
can say we support DNSSEC"

---

From: [email-masked]
Date: Tue, 7 Oct 2008 22:32:31 +0000

> there are errors, therefore that's where the onus matters.

	and this will work when voice is VoIP/SIP/ENUM - dependent on
	DNS lookups working?   can they still call anyone at that point?

--bill

---

From: Mark Andrews <[email-masked]>
Date: Wed, 08 Oct 2008 11:46:09 +1100

> 	DNS lookups working?   can they still call anyone at that point?

	Use a land line, use mobile, use the neibours phone.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 7 Oct 2008 19:06:42 -0700

On Oct 7, 2008, at 5:46 PM, Mark Andrews wrote:

>>>> to ensure that the bits they run, don't break when they start  
>>>> doing dnssec
>> .
>>>

Or use an ISP that doesn't turn on that F@#)* break-the-Internet  
Security crap...

This is a huge problem with DNSSEC:  Because it is before-the-user,  
you can't do the "Nag the user" fallback positions you can with TLS or  
SSH.  Thus you have either "accept" or "deny" on what are routine  
failures.

And you can't rely on apps to "accept and then check" in the gray  
cases, because almost any app which would check would just do end-to- 
end crypto so DNSSEC is irrelevant for those.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 07 Oct 2008 22:51:21 -0400

> Or use an ISP that doesn't turn on that F@#)* break-the-Internet

If DNS lookups fail, it will be towards zones that have dnssec
borkedness. Not to the whole f-ing world.

If the ISPs own resolvers break (badly enough) so that nothing resolves,
they should expect to lose customers.

If the ISP turns off security, their customers can (and should) choose
among:
- switch ISP
- run their own resolver
- use third-party resolver service

And, the DNS *of* vendors/providers of DNS software or services, should
not be one of the sites that breaks. :-)
(The proof is in the pudding, eating our own dog food, etc.)

> cases, because almost any app which would check would just do
> end-to-end crypto so DNSSEC is irrelevant for those.

Nothing prevents apps from embedding their own resolvers, with or
without DNSSEC including gray/grey cases. Many, in fact, already do
(have embedded (stub) resolvers).

So, the whole thing is a bit of a straw man.

Brian

---

From: "Griffiths, Chris" <[email-masked]>
Date: Tue, 7 Oct 2008 22:55:38 -0400

>end crypto so DNSSEC is irrelevant for those.

This certainly concerns all ISP's and other users running resolvers in
general.  As I read up on DNSSEC (both RFC's and documentation that most
of you wrote), the lack of a fallback as you mention becomes a serious
concern.  There is also the lack of a signed root and a severe anemia to
folks pushing real world testing forward so we can make sure edge cases
don't crop up. I am looking forward to having repositories for keys
which has been brought up, but that is a stop gap.  

We talk about VOIP/ENUM/SIP and frankly that scares me.  What also
scares me is broken keys for sites like Ebay, Facebook or Myspace if and
when they exist.  How are users going react when they can't get to these
from their Phone or mobile device or even - gasp at their home just
surfing the web.

We need to assume that at some point applications will utilize DNSSEC
responses either at an OS level or application level to confirm the
authenticity of sites (Think DNS Prefetching).  This will add even more
complexity to troubleshooting issues.  I am not convinced that this will
stay out in front of the user.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Oct 2008 07:36:41 -0400

At 14:21 -0700 10/7/08, Nicholas Weaver wrote:
>So if DNSSEC results in more tech support calls because items don't resolve,
>through fault of the authorities and not the ISP's resolver, no ISP in its
>right mind would support it!  Or if support is mandated, it will be set to
>"well, fail open anyway so it doesn't matter, but we can say we 
>support DNSSEC"

That's not a foregone conclusion though.  As much work as it is for 
an ISP and as much of a chance that there may be hard work to avoid 
problems, ISPs do have the incentive to make sure that the DNS 
servers they operate give accurate answers to their customers.

There are ISPs interested in DNSSEC.  ISPs in Sweden are using it. 
Recently this too: http://www.dnssec.comcast.net/.

And this relates a story about galve.se and an error.  In this case 
DNSSEC was on-off-on. 
http://www.aptld.org/taipeifebruary2008/20-dnssec_2008_APTLD.pdf. 
Unfortunately the slides are not numbered, the three pertinent slides 
are towards the end.  Just look for "galve.se".

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Oct 2008 10:17:39 -0400

>from their Phone or mobile device or even - gasp at their home just

I'm pretty confident that these dangers won't be realized.  (Of 
course, DNSSEC even with the current momentum it has might never be 
realized.)  Like everything else, before anything goes into 
mainstream production there will be a long trail of testing, 
documentation, process development, review (and all of that other 
boring stuff big companies do that open sourcers seem to hate) before 
it sees the light of day.  Getting to production is going to take 
work.  Getting DNSSEC to be relied upon is even more work.

I gave a talk last week.  I thought that the talk was fairly 
pessimistic about the future of DNSSEC because I presented a laundry 
list of the costs of deploying DNSSEC to just a ccTLD.  I spent very 
little time on the revenue potentials.  Afterwards someone commented 
that my talk was rather positive and encouraging.  I asked "in what 
way?"  They said that everything of value has a lot of costs in 
development, the cost element wasn't a scare to that level of 
management.

As far as combining voice and data on one network, my boss in the 
early 90's already expressed that concern.  Before any situation that 
requires putting eggs in baskets, you can bet there will be a lot of 
review.  On the other hand, remember what it was like when there was 
no data network, no cellular, all we had then were land lines?  It 
worked, via regulations and details.

One of the lines from my presentation last week was "don't let 
engineers confuse cost with budget."  What that meant was that often 
we have the tendency to look at a load of work and decide that it is 
too costly.  We don't look at the benefit of the work though.  DNSSEC 
might be another case. It's a lot of work to pull off, I mean all the 
elements working together.  But the safety it offers, or the value of 
the safety, is currently high (the value fluctuates like any other 
market) and folks who hold the budget see a net positive in it.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 8 Oct 2008 08:46:47 -0700

On Oct 8, 2008, at 7:17 AM, Edward Lewis wrote:
> boring stuff big companies do that open sourcers seem to hate)  
> before it sees the light of day.  Getting to production is going to  
> take work.  Getting DNSSEC to be relied upon is even more work.
>

Then again, a lot of things have cost without benefit.

The problem is defining the BENEFIT for DNSSEC in terms of AGGREGATE  
system security.  And the problem is, the benefit is very low:

1)  It SHOULD NOT provide a net increase in security over well  
constructed resolvers against out-of-path adversaries.

2)  It DOES provide a benefit in security if your ISP's resolver is  
corrupted.  Yet some such corruption (eg, NX-domain wildcarding,  
MitMing Google) may be caused by the ISP or separate DNS provider for  
their own economic benefit.

3)  It DOES NOT provide a net increase in security against an in-path  
(MitM) adversary under most conditions, because in such conditions, an  
in-path adversary can almost always also directly manipulate the data  
traffic.  And if the application is resistant to in-path adversaries,  
it never really relied on the DNS name as anything more than a  
mnemonic because it needs to establish a direct cryptographic channel  
with the other side.

Thus the only real BENEFIT is #4:

4)  An external third party (eg the US Government) REQUIRES deployment  
of DNSSEC.

or PERHAPS:

5)  It is used by end-applications as an integrity-assured object  
store to allow an application to fetch the remote system's key  
fingerprint based on the DNSSEC CA infrastructure (and it IS a CA  
infrastructure, really) rather than using a separate CA  
infrastructure.  But 5 won't occur until DNSSEC is widely used,  
because until it is widely used, the separate CA infrastructures are  
equally trustworthy and available today.  But for this use, the  
problem is that DNSSEC values are too small.  I'd want a nice,  
integrity assured, key->value database but I don't want values  
restricted to such small quantities of data.

Thus if I was in charge of a DNS infrastructure, I would:

a)  NOT deploy DNSSEC on my authorities unless there was an external  
mandate.  If there is an external mandate, I would deploy DNSSEC, and  
would contract with an external party to do continual validation of  
operation under the most strict acceptance policy, lest my DNSSEC  
deployment results in failures.

b)  NOT deploy DNSSEC checking on my resolvers unless there was an  
external mandate, but correctly forward DNSSEC records when queried  
(enabling end-systems to do their own checking if desired, eg, such as  
#5 which REQUIRES the end-application to check regardless of resolver  
behavior anyway).  If there is an external mandate to have the  
resolver check DNSSEC, I would use the least strict acceptance policy,  
to reduce the probability that my DNSSEC deployment results in failures.

And for those who advocate DNSSEC, this is a problem, because if you  
look at net SYSTEM benefit, you need to make arguments that the  
benefits are substantial.

Finally, what do you mean by "Rely" on DNSSEC.  No application that I  
know of can rely on DNSSEC to provide the name to address mapping yet  
trust the network.  The only thing I'd "rely" on DNSSEC for as a  
developer is as an object store for key/value mappings, not addressing.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2008 12:42:43 -0400

[no hat]

On Tue, Oct 07, 2008 at 04:25:21PM -0400, Edward Lewis wrote:

> How do you decide between a bogus signature due to maliciousness and a 
> bogus signature due to misconfiguration and a bogus signature due to a 
> disagreement over policy, etc.?

You don't, from the point of view of an application.  In my reading,
validation failure is validation failure, full stop.  This is related
to my belief that there are no levels of trust in DNSSEC, and that if
we want to add that gewgaw, we have some work to do.

A

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

---

From: [email-masked]
Date: Wed, 8 Oct 2008 17:32:33 +0000

On Wed, Oct 08, 2008 at 07:36:41AM -0400, Edward Lewis wrote:
> >resolve,

	indeed they do, since they are the folks holding the 
	liability. 

> Recently this too: http://www.dnssec.comcast.net/.

	all really good stuff.

> are towards the end.  Just look for "galve.se".

	so - back to my original point.  I think that for -now-
	having DNSSEC fail-open is a much more credible stance than
	taking a hardline - fail-closed - model.   Lets save fail-closed
	until after we get some more traction.

	what was that Postel credo?

--bill

---

From: [email-masked]
Date: Wed, 8 Oct 2008 17:39:27 +0000

> we want to add that gewgaw, we have some work to do.

	oh... we need to change your beliefs then :)

	sure, validation failure is validation failure... but when and
	from whom?  Ed leaves out transient network failure as areason
	for validation failure...  when validation fails, how often do
	you retry?

--bill

---

From: [email-masked]
Date: Wed, 8 Oct 2008 17:50:34 +0000

> will be the result of misconfigurations.

	I remember the first pass @ DNSSEC ... the primary drivers
	were from security folks looking for perfect security.
	And what we got was not operationally deployable.

	DNS - as it exists - is full of operational issues and yet
	it works well enough that it has become a serious core 
	technology.  

	I expect that - in this pass - we will also have many operational
	issues w/ DNSSEC deployment that will be smoothed over - if only
	to keep things working in/through transition.

	wrt yoru bet - i'll not take it. 

> was off by one.  That took a lot of squinting at screens and paper 

	Ah yes - DNS aquires a dependence on an external application.

> will still outpace attacks.  Especially after DNSSEC has been running 

	actually, I think there are only three entities in canonical validation.
	the validator, the publisher(s) e.g. authoritative and caching servers, and
	the zone key holder(s).

> implications, for operational reasons much less obviating the point 

	likely true, but it is better than any of the alternatives.

--bill

---

From: [email-masked]
Date: Wed, 8 Oct 2008 17:52:16 +0000

> verification is within a debugging/reporting context.

	I disagree...  but that kind of depends on what is ment
	by "reporting".

--bill

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Oct 2008 19:01:50 +0100

> 	for validation failure...  when validation fails, how often do

A SERVFAIL because of network breakage is not really a DNSSEC problem.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: NORTHWESTERLY 4 OR 5, INCREASING 6
FOR A TIME IN SOUTH UTSIRE, BACKING SOUTHERLY 5 TO 7 LATER. MODERATE OR ROUGH.
SHOWERS, RAIN LATER IN VIKING AND FORTIES. MODERATE OR GOOD, OCCASIONALLY POOR
LATER IN VIKING AND FORTIES.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Oct 2008 14:03:08 -0400

At 17:50 +0000 10/8/08, [email-masked] wrote:

>	the validator, the publisher(s) e.g. authoritative and caching servers,
>	and the zone key holder(s).

You are counting "publisher(s)" as one when you should be counting it 
as at least 3.  That's why you don't get a 5.  The root zone manager, 
the tld manager, and the enterprise are three independent 
organizations that may need to be consulted to see why a certain DS 
RR wasn't uploaded in a certain zone.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Oct 2008 13:59:02 -0400

>	until after we get some more traction.

I'm pessimistic about a plan that includes "later on, we tighten security."

We thought of this back in the day.  Lacking the ability to recall or 
disable older versions of software, the only way you can change a 
code base to support a new paradigm is to get users to upgrade. 
Upgrades only come when the user wants to upgrade. And who wants to 
get a new car because it has tighter seat belts?

Until the model is "fail closed" DNSSEC can't be relied upon.

With a fail open model letting sloppy operations habits fester 
unabated, we will never get to a mature state.  Fail open will only 
get us what 6Bone got IPv6 -  tools and software but not enough 
operational reality to get the technology deployed.  (For example, 
making use of tunnels deferred thought about IPv6 routing/forwarding 
table issues.)

>	what was that Postel credo?

(http://en.wikipedia.org/wiki/Postel's_law)

We aren't taking about robustness, we are talking about security.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Oct 2008 14:14:52 -0400

>	for validation failure...  when validation fails, how often do

If there is a transient network failure lasting longer than the 
maximum allowed time to answer a question - it's unlikely that it is 
DNSSEC validation that is the bottleneck.  If there is such a 
failure, you'd probably not get the answer either.  That's why I 
don't consider it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: [email-masked]
Date: Wed, 8 Oct 2008 18:36:25 +0000

> RR wasn't uploaded in a certain zone.

	kind of depends on where you get your TA's.
	I still say three.

--bill

---

From: [email-masked]
Date: Wed, 8 Oct 2008 18:33:25 +0000

> stub resolver is misconfigured, it validates DNSSEC signatures before  

	resolution != validation  your assertion that it should
	is based on fervant wish, not analytical review.

	a resolver is a series of system calls.  no state, totally ephemeral.

	a "full resolver" or "caching resolver"  is a DNS server sitting on 
	a resolver.  in this case, the DNS server has no authoritative data, 
	it just maintains cache.  And in that case, you -might- put a 
	validator with that DNS server - since you are already committed 
	to maintain cache/state.

	is the distinction clearer?

> resolver to do this properly.

	a stub resolver is, by definition, just the set of system calls.
	it can't validate, since there is no local cache.

> How many end-host lookups are "DNS is the application"?  Almost none.   

	actually - 100% of them.  the DNS application will 
	almost always pass the results of a lookup back to some
	other application.

> the underlying operating system, for example.

	let me run that by several of the Security Area directorate.
	last I checked, just because the DNS data has not been tampered
	with in transit, is no assurance that the target host is clean
	or any of the applications running thereon are safe.

> validation be done at all?

	why not?  doing validation independently of resolution may be
	required for a number of reasons - for example the endnodes may
	be constrained by power, number of transistors, etc for running 
	a userspace cache.  lightweight system calls may be all that fit.

> answer for almost all applications:

	thats a point of view.  not a universally held pov, but
	one you can hold.

[prognostications held forth]

> respository with cryptographic integrity", where NON-naming  

	thats not a new idea either - but fraught w/ transient trust
	problems.

> avaliable, unlike transport .

	Yowsa... put everything in the DNS 'cause thats all we got?

> the end host's stub resolver code anyway.

	not sure what this means.
	
--bill

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 11:41:44 -0700

>        what was that Postel credo?

I just tried ssh'ing to [email-masked].  Why didn't it accept
"opensesame" as the password?  Your server's not being very liberal in
what it accepts.  :-(

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 8 Oct 2008 11:52:18 -0700

> 	is the distinction clearer?

I'm afraid I just don't get it.

The whole point of DNSSEC is to insure that the object returned by a  
query has an integrity guarentee associated with it, not that you can  
do a separate integrity check.  I can't find anything that suggests  
otherwise.

> 	it can't validate, since there is no local cache.

Actually, this is incorrect.  Many MANY end system stub resolvers  
maintain cache state.  Try it out for yourself with a TCPdump and  
multiple invocations of ping.

getaddrinfo() is hardly stateless on most systems.

> 	almost always pass the results of a lookup back to some

Thats exactly my point.  DNS is not the application!

The final application is the application, DNS is simply a tool USED by  
the application to provide a convenient mapping of name -> address.

You can attack the final application by attacking the name -> address  
mapping or many other ways.  DNS only needs to not provide ADDITIONAL  
ways to attack the final application.

This is why I don't believe the MitM is the proper threat model for DNS.

> 	a userspace cache.  lightweight system calls may be all that fit.

If thats the case, why is the stub resolver not implementing this?

Separate validation is USELESS:  Apps either won't validate or they  
will.  If the app doesn't validate it, it gains no protection from  
DNSSEC.

If the app would have validated it, dollars to doughnuts says it  
doesn't actually bother validating it because its going to do a  
subsequent cryptographic validation of the other party anyway.

> 	thats not a new idea either - but fraught w/ transient trust

Its the same transient trust problem present in TLS's CA structure, or  
any PKI infrastructure.  And it doesn't add any MORE transient trust  
problems than any other PKI infrastructure.  In fact, in both cases  
you have to trust Verisign.

> 	Yowsa... put everything in the DNS 'cause thats all we got?

No, put it in DNSSEC because its code that works.

Lesson #1: never reimplement crypto when there is an off-the-shelf  
solution.

> 	not sure what this means.

That if you actually DO want this, you include library code that  
interfaces with DNS directly, bypassing gethostbyname() completely,  
because the policy you want for the gray cases is probably not the  
policy the stub resolver wants.

---

From: [email-masked]
Date: Wed, 8 Oct 2008 18:51:38 +0000

> "opensesame" as the password?  Your server's not being very liberal in

	well, if you were more conservative in what you sent...  :)

--bill

---

From: Brian Dickson <[email-masked]>
Date: Wed, 08 Oct 2008 15:32:05 -0400

> ways to attack the final application.

You are perilously close to "getting it". ;-)

The simplest viewpoint can be reached by considering a system consisting
of just a control plane and a data plane.

In such a system:

    * if neither the control plane nor data plane is secured against
      tampering, you have no (end-to-end) security
    * if the data plane is secured but the control plane is not secured,
      you have (at best) the illusion of security
    * if the control plane is secured but the data plane is not secured,
      you also have (at best) the illusion of security
    * only if both the control plane and data plane are secured, can you
      have (at least theoretical) end-to-end security

SSL/TLS can protect the data channel, i.e. the data plane from our model.

However, without DNSSEC or some similar method of protecting the
name->address mapping, the data protection is at best of limited use.

(You really should review Dan Kaminsky's Black Hat presentation, and
Anton Kapella's Black Hat presentation, to understand why.)

I don't believe any reasonable advocates of DNSSEC are also anti-SSL/TLS.

DNS without DNSSEC *is* an additional way to attack the final application.

> This is why I don't believe the MitM is the proper threat model for DNS.

See the above. MitM protection is necessary, but not sufficient, to
provide security for any system that relies on DNS, e.g.,  what most
people think of when they refer to "The Internet".

Brian Dickson

---

From: [email-masked]
Date: Wed, 8 Oct 2008 20:26:28 +0000

> do a separate integrity check.  I can't find anything that suggests  

	has the ability to have an integrity guarentee.  a priora, it 
	(DNSSEC) does not ensure that a reply to a query has an integrity
	guarentee - it simply provides the framework on which such auarentees
	can be made.  

> multiple invocations of ping.

	then they are not stub resolvers.

> Thats exactly my point.  DNS is not the application!

	the DNS is AN application.  a host-lookup is a DNS lookup, e.g.
	the DNS application.  the results may be used by other applications.

> ways to attack the final application.

	w/o DNSSEC, there are ADDITIONAL ways to attack, regardless of 
	the target application.  you can and should still use other
	security methods like TLS or SSL or other application specific
	techniques.

> This is why I don't believe the MitM is the proper threat model for DNS.

	then take it up w/ the authors of the DNS risk/threat RFC.

> will.  If the app doesn't validate it, it gains no protection from  

	thats your claim.  we'll see how things pan out.

> you have to trust Verisign.

	er, not quite the same.  stuffing SSH keys or any other application
	key into the DNS presumes that the application owner controls the contents of
	the DNS zone... which is not true in most cases.  the one case that
	the IETF retained was storing x509 certificates in CERT rrs.

> No, put it in DNSSEC because its code that works.

	that argument has been used before  w/ limited efficacy.

> Lesson #1: never reimplement crypto when there is an off-the-shelf  

 not quite what I learned but close.

	) never reimplement crypto that works for your intended use.

** unless you are a crypto person and know what the heck you are doing.

> policy the stub resolver wants.

	so you are talking about a validator API independent of the
	resolver API?  

--bill

---

From: [email-masked]
Date: Wed, 8 Oct 2008 20:47:18 +0000

> A SERVFAIL because of network breakage is not really a DNSSEC problem.

	how do you tell?

--bill

---

From: Dean Anderson <[email-masked]>
Date: Wed, 8 Oct 2008 17:04:40 -0400 (EDT)

[ Note: Post was moderated. ] 

> name->address mapping, the data protection is at best of limited use.

The above is not true, as I recently explained on the DJBDNS list.

The point is that there is only two categories:  One category of attack
that can come from anywhere, and the other category of attack can only
come from the middle.  DNS over TCP eliminates the first category, so no
further effort is needed to eliminate that category. TLS, properly
verified, completely eliminates the second category, so no further
effort is needed to eliminate that category.  All done. No more changes
to DNS are needed.

> Anton Kapella's Black Hat presentation, to understand why.)

Kaminsky's claims have been discredited; he didn't discover or even
rediscover forgotton attacks. The attack kaminsky describes was
described as recently as 2006 to the IETF, and was pointed out by Dr.  
Bernstein in the 1990s when the 'balliwick' changes were being
discussed.  The Kaminsky report created "urgency"; A frequent element of
a scam is to have such urgency that one can't stop to think about
whether the claims are legitimate or make sense. Professor Bruce Wedlock
often repeated "Always ask yourself 'Does this make sense?'"  Of course,
the attack could have been forgotten and 'rediscovered', but that isn't
the case, either. I found a design report for Unbound (developed by
Nominet, Verisign, NLnet Labs, EP.NET (Bill Manning))
http://www.unbound.net/documentation/ietf67-design-02.pdf in which they
describe that "spoofed NS additionals confuse iterator".  This paper was
discussed at IETF 67, in November 2006, so one can't even say that DJB
discovered the attack in the 90's but it was forgotten and rediscovered
by Kaminsky.  Kaminsky just created a lot of "urgency", with the result
of scaring people into adopting DNSSEC.

I've recently been discussing a problem Kaminsky and Kevin Day reported
(at blackhat) to exist in DJBDNS. They still have not revealed precisely
what the bug is, months later, and many in the DJBDNS community are
getting fed up with the delay. After criticizing Kaminsky and Day for
failing to talk to the DJBDNS community about the problems, Kaminsky and
Day began to talk a bit more about their mathematical assumptions.  To
put it bluntly, their math was complete BS. And after I analyzed the
math a bit (discrediting their analysis), I did discover some few things
that could be smarter in DJBDNS, that apparently they had previously
seen but not reported.  They proposed (to me, at least) changes to
DJBDNS to re-use ports. (no patches, just the idea of doing this).  
Their proposal has the effect that any port coincidence would then have
multiple possible QIDs instead of exactly one. This actually harms
security, but they don't see that. Instead of

   probability of port coincidence * 1/65536 QIDs

as currently a response received must have the correct query, port and
QID, it becomes

   probability of port coincidence * probability of QID coincidence.

The CRC handbook of Applied Cryptography gives the formulas needed in
section 2.1.5, Birthday problems. On a regular unix system, the first
1025 ports usually won't be assigned to a socket, leaving 64510 ports
available for use.  The math for the first case:

model B (2 urns, no replacement)
p4(64510, 200, 200)
exact formula: 1 - (perm(m, n1+n2) / (perm(m, n1) * perm(m, n2))
   simplified (n1 = n2): 1 - (perm(m, 2n) / (perm(m,n) ^ 2))
(%i48)  float( 1 - ( 64510! / ( 64510 - 400)! ) / ( ( 64510! / ( 64510 - 
200)! ) ^ 2 ) );
(%o48)                         0.46312147260386
(%i49) % * (1/65536);
(%o49)                       7.066672860776713E-6
(%i50) 1 / %;
(%o50)                         141509.3099258154
(%i51) 200 * %;
(%o51)                       2.830186198516307E+7

So, as is, one must repeat 141509 times before success, expect to send
28,301,862 packets against DJBDNS.  Yet Kaminsky asserts the birthday
attack is carried out in

 65536 * 65536 / 200 = ~21474837 packets. 

While within an order of magnitude, Kaminsky calculates and incorrect
number and uses an incorrect formala for a birthday attack.

After the Kaminsky/Day proposed changes to DJBDNS (and possibly other
DNS servers), there would be two birthday attacks that combine resulting
in:

model B (2 urns, no replacement) (port coincidence as above)
p4(64510, 200, 200)
exact formula: 1 - (perm(m, n1+n2) / (perm(m, n1) * perm(m, n2))
   simplified (n1 = n2): 1 - (perm(m, 2n) / (perm(m,n) ^ 2))
(%i48)  float( 1 - ( 64510! / ( 64510 - 400)! ) / ( ( 64510! / ( 64510 - 200)! ) ^ 2 ) );
(%o48)                         0.46312147260386

model B (2 urns, no replacement) (QID coincidence)
p4(65536, 200, 200)

(%i73) float( 1 - ( 65536! / ( 65536 - 400)! ) / ( ( 65536! / ( 65536 - 
200)! ) ^ 2 ) );
(%o73)                          0.4578519611075
(%i75) %o48 * %o73;
(%o75)                         0.21204107446267
(%i76) 1 / %;
(%o76)                         4.716067405968776
(%i77) 200 * %;
(%o77)                         943.2134811937551

So, if you have 200 outstanding ports, with 200 outstanding QIDs, and
any correct port can have a coincidence on the 200 QIDs, the cache is
spoofed in just under under 5 tries, or in about 943 packets!!! Holy
added-security flaws!

> DNS without DNSSEC *is* an additional way to attack the final application.

DNS *with* DNSSEC is an additional way to attack the final application.

DNSSEC caches can still be poisoned by setting the CD bit so that the
cache does not verify the data, then spoofing by ordinary means with the
appropriatly set DO and CD bits. The cache won't verify the data, and so
will cache invalid data that it hands to the stub resolver for
verification. The resolver that tries to verify the data will reject the
invalid signature, but can't get past the cache with the bad data.
Result: DOS.

And of course, don't forget that spoofed DNSSEC queries of TLDs or 
significant domains can result in an upto 8KB response that can't be 
easily mitigated.

> people think of when they refer to "The Internet".

DNSSEC does not protect an application against a MITM attack.  Even
getting the right domain name, if the application does not use TLS or
if the application does not properly verify the certificates, it is
still vulnerable to a MITM attack.

If the application gets bad domain data, TLS and proper verification 
will detect this. DNS 'security' is not necessary to avoid MITM attacks.

There are also some other crypto problems with DNSSEC, in that they
didn't follow the recommendations for adding a random salt before the
signatures, and so are vulnerable to low encryption coefficient attack,
etc.

		--Dean

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

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 15:19:59 -0700

On Wed, Oct 8, 2008 at 2:04 PM, Dean Anderson <[email-masked]> wrote:
> further effort is needed to eliminate that category.

This is not entirely true.  DNS over TCP is vulnerable to TCP RST
denial-of-service attacks (like any TCP service).  Of course, if you
switch to sending your encrypted/authenticated queries over UDP (e.g.,
using a scheme like DNSCurve), then you can defend against these
attacks also eliminating the extra round for the TCP handshake.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 8 Oct 2008 17:18:20 -0700

> attacks also eliminating the extra round for the TCP handshake.

TCP RST injection in a blind mode is not effective if your end host is  
finniky about packet acceptance.

Additionally, since DNS messages are short and the protocol is  
effectively stateless, just start up a new connection: it leaves a  
very low timeout window for an attack to do any good.

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 17:32:42 -0700

> finniky about packet acceptance.

Yeah, but not all attackers have to operate blind.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 8 Oct 2008 17:41:44 -0700

> Yeah, but not all attackers have to operate blind.

But a non-blind attacker can ALWAYS screw you up by attacking the  
final application as a MitM:  Why waste the effort DoSing the DNS TCP  
connection?

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 19:31:00 -0700

On Wed, Oct 8, 2008 at 5:41 PM, Nicholas Weaver
<[email-masked]> wrote:
> But a non-blind attacker can ALWAYS screw you up by attacking the final
> application as a MitM:  Why waste the effort DoSing the DNS TCP connection?

If you already know the other host's public key through another
channel secure against the attacker (e.g., public keys known a priori
for the root servers or securely retrieved from parent name servers),
then the attacker cannot forge any application-level data.  They're
limited to corrupting the TLS stream or resetting the TCP connection;
i.e., denial of service attacks.

Using UDP prevents sniffing attackers from being able to mount denial
of service attacks.  Forged UDP responses can be detected and
discarded while continuing to wait for an authentic response.  (Of
course, routers between the two hosts can still deny service by
dropping packets, but this is unavoidable.)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 08 Oct 2008 20:20:24 -0700

At Wed, 8 Oct 2008 19:31:00 -0700,
> dropping packets, but this is unavoidable.)

As a nit: I'm not sure this is really true. 

Let's say that Alice wants to connect to Bob and a priori knows
Bob's public key. The MITM intercepts the handshake and generates
invalid protocol data (e.g., if you're doing TLS it pretends not
to speak a compatible cipher suite). This looks like a protocol
error. Maybe you retry later, maybe you don't, but I suspect
for most well-behaved stacks this wouldbe a reasonably effective
DoS.

-Ekr

---

From: "Adam Langley" <[email-masked]>
Date: Wed, 8 Oct 2008 21:02:17 -0700

> for most well-behaved stacks this wouldbe a reasonably effective

For the specific case of DNSCurve (which I suspect is what Matthew had
in mind), that doesn't work. An attacker can observe the request and
then fabricate replies with the correct TXID and port, all of which
will be rejected in only a few thousand CPU cycles until the real one
comes in. The attacker may destroy the request in transit and cause a
DoS, but the client will never accept an unauthenticated reply if a
parent DNS believes that the DNS server should be DNSCurve capable.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 08 Oct 2008 21:23:56 -0700

At Wed, 8 Oct 2008 21:02:17 -0700,
> parent DNS believes that the DNS server should be DNSCurve capable.

I really don't see how this situation differs from TLS/DTLS in any 
appreciable way.

Yes, the client believes that the server speaks the secure protocol,
but the attacker removes the server's response (or the client's request)
from the wire and impersonates a *broken* server. Sure, the client
could just keep banging on the server, even though it appears to be
broken, but that's rude behavior. Well-behaved clients will back off.
Instant DoS.

-Ekr

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 21:36:47 -0700

> I really don't see how this situation differs from TLS/DTLS in any

It differs for attackers that can only sniff traffic as opposed to
control it.  There's obviously no way to prevent denial of service
from attackers who can simply disconnect you from parts of the
Internet.

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 21:58:49 -0700

On Wed, Oct 8, 2008 at 9:36 PM, Matthew Dempsky <[email-masked]> wrote:
> control it.

To be more explicit, DNSCurve has no handshake step for a sniffing
attacker to interrupt.  A DNSCurve-enabled server announces its public
key and supported cipher suites through its DNSCurve-encoded NS record
name.

When a DNSCurve-enabled client wants to send a DNS query to this
server, it generates a standard DNS query, computes a shared secret
using Diffie-Hellman, encrypts and authenticates the query, and sends
it along with its own public key to the server as a DNSCurve query.

The server detects the DNSCurve formatted query, extracts the public
key, computes the shared secret as well, verifies and decrypts the
standard DNS query, generates a standard DNS response, encrypts and
authenticates the response, and sends it back to the client as a
DNSCurve response.

The client receives the DNSCurve response, verifies and decrypts the
response, and processes the embedded standard DNS response.

Clients and servers simply discard any DNSCurve packets that don't
verify correctly.  E.g., if a client sends a DNSCurve query, sets a
one second timeout for the response, and receives a bogus DNSCurve
response half a second later, then it discards that response after the
authenticator fails to verify and continues to wait out the remainder
of the second for a legitimate response.

If an attacker can only sniff traffic and forge responses, eventually
the legitimate query will reach the server and eventually the
legitimate response will reach the client.

If an attacker can reliably mangle and/or drop traffic, then there's
nothing cryptography can do to help prevent a denial of service
attack.  (Of course, DNSCurve clients will retry DNSCurve queries the
same as regular DNS queries to deal with intermitent network
failures.)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 08 Oct 2008 22:00:57 -0700

At Wed, 8 Oct 2008 21:36:47 -0700,
> It differs for attackers that can only sniff traffic as opposed to

Again, how is this different from TLS/DTLS? If you can't inject
traffic, you can't DoS TLS/DTLS either. 

Is your argument that an attacker who can both sniff and 
inject traffic can DoS a TLS/DTLS connection, but that it's
possible to design a new protocol that doesn't have this
property (I still haven't seen a DNScurve spec, so I can't
comment on whether it has that property). This may well
be true, but it's not clear to me that there are actually
a significant number of threat environments where an
attacker can sniff, inject, but not block or gag at all.
Can you name one? 

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 08 Oct 2008 22:07:27 -0700

At Wed, 8 Oct 2008 21:58:49 -0700,
> key and supported cipher suites through its DNSCurve-encoded NS record

Per Paul Hoffman's suggestion, I'd rather not get into a long
discussion of DNSCurve until there's a real I-D describing it.
That said, this seems like a feature that could trivially
be added to DTLS/TLS, simply by announcing the same information
in an NS record.

> If an attacker can only sniff traffic and forge responses,

Can you name a threat environment that actually matches
this description?

-Ekr

---

From: "Matthew Dempsky" <[email-masked]>
Date: Wed, 8 Oct 2008 23:47:23 -0700

> Can you name a threat environment that actually matches

I'm willing to concede that I cannot.  (After some reconsideration,
for the scenarios I originally had in mind, I suspect the attacker
could additionally hijack control of the victim's traffic, escalating
his powers.)

However, I'm currently not convinced that such an attacker can *never*
exist.  So if we have a way to defend against one at no extra cost, it
makes sense to do so and then not have to worry about it.

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 09 Oct 2008 12:01:35 +0200

Hi Dean,

> of scaring people into adopting DNSSEC.

The thing that Kaminsky added was the retry for a different (previously
unseen) query name, which delivers the race-to-win and no wait for TTLs.
 The rest is indeed the same.  The race-to-win made the problem very urgent.

> spoofed in just under under 5 tries, or in about 943 packets!!! Holy

Are you saying that using multiple ports at the same time creates
birthday attack problems?  Or do you assume in the above that this is
the same query that is sent out with multiple outstanding ports/multiple
outstanding QIDs?

> invalid signature, but can't get past the cache with the bad data.

Unbound has a cache of 'bad' data.  This is data that it considers
bogus.  This data can be retrieved by setting the CD bit, that is the
purpose of the CD bit.  This data is not returned to regular stub
resolvers (withholding the bad data).  The stub resolver can then choose
via the CD bit to verify that data itself, with its own security policy.

Best regards,
   Wouter

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Oct 2008 06:54:44 -0700

At 9:58 PM -0700 10/8/08, Matthew Dempsky wrote:
>attacker to interrupt.

How do you know that? DNSCurve is essentially unspecified. We really should wait for Dan (or someone) to write a stable document that says what DNSCurve really means before we make such bold statements.

I am far from convinced that, when we see the working protocol, that the above statement will necessarily be true. I would be happy to be wrong.

--Paul Hoffman, Director
--VPN Consortium

---

From: [email-masked]
Date: Thu, 9 Oct 2008 14:51:52 +0000

> Can you point us to some of these?

	this might be what you are looking for.

	http://www.rs.net/rva/index.html

--bill

---

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 09 Oct 2008 17:19:11 +0200

> 	http://www.rs.net/rva/index.html

There is a draft, I think it has seen a lot of effort.
http://tools.ietf.org/html/draft-hayatnagarkar-dnsext-validator-api-06
But it was too featurefull for me.

The API that lib unbound exposes when validating to an application - one
borne out of implementation, simplified and not backwards compatible is
 http://unbound.net/documentation/libunbound.html

I am not suggesting just one implementations API should be a standard,
but it could be a useful input.

Best regards,
   Wouter

---

From: "Matthew Dempsky" <[email-masked]>
Date: Thu, 9 Oct 2008 11:02:16 -0700

On Thu, Oct 9, 2008 at 6:54 AM, Paul Hoffman <[email-masked]> wrote:
> How do you know that?

Because the current specification doesn't use a handshake.

> DNSCurve is essentially unspecified.

It's specified enough that Adam Langley and I have independently
implemented server and client functionality that communicate using
DNSCurve protected packets.

> We really should wait for Dan (or someone) to write a stable document that says what DNSCurve really means before we make such bold statements.

http://dnscurve.org/impl.html has an outline of DNSCurve for
implementers, and the main ideas have not changed.  The only changes
that I've known of are changing the base32 encoding character set from
[0-9a-v] to [0-9b-df-hj-np-z], expanding the nonce size, and adding
the streamlined packet format.  I can imagine a few more encoding
changes along these lines, but I expect the rest of the spec to remain
stable.

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 9 Oct 2008 11:32:56 -0700

At 11:02 AM -0700 10/9/08, Matthew Dempsky wrote:
>implementers, and the main ideas have not changed.

That page is *significantly* different than it was a few weeks ago. It is much more complete, which is good, but it is obviously not stable.

Your idea of "main ideas" may be different than other people's ideas. That's part of the protocol development process.

It sounds like you are quite interested in this protocol. Could you take the time to instantiate some current version of the protocol into an Internet Draft? That would *really* help this discussion.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Oct 2008 14:41:44 -0400

> DNSCurve protected packets.

"Running code" does not a specification make.  It would be quite
valuable to the rest of us if you would summarize your and Adam
Langley's understanding of DNSCurve in an Internet-Draft that the rest
of us can read and try to understand.  In the absence of such a
document, as we've noted on this list before, there is nothing for the
DNS Extensions Working Group to talk about.  

In the absence of a formal specification either as an I-D or in some
other format, the discussion of DNSCurve on this list is a
distraction.  DNSCurve is interesting, but this is not a forum for
discussing all things DNS.  This is a list for an IETF working group,
and therefore, we need to focus the discussion to things that can
plausibly be entertained as WG work items, and to actual WG items.

Therefore, I remind participants that Olafur and I have already asked
for some formal draft about DNSCurve.  We encourage the creation of
such a draft, either as an I-D under the auspices of the IETF, or in
some other forum.  But until such a draft appears, we ask that
participants consider carefully the value of further speculation about
DNSCurve before posting any more remarks about it.

Thanks,
Andrew
(for the Chairs)

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Oct 2008 15:07:02 -0400

At 11:32 -0700 10/9/08, Paul Hoffman wrote:

>It sounds like you are quite interested in this protocol. Could you take
>the time to instantiate some current version of the protocol into an
>Internet Draft? That would *really* help this discussion.

Why does it have to be an Internet Draft?  The author of the 
mechanism hasn't asked for IETF review nor RFC Editor for 
publication.  If the DNSEXT WG wants to discuss someone else's work, 
the onus is on the group, not the other person.

(Yes, I am just causing trouble here.  But historically we have 
recognized a non-IETF document in the definition of the protocol, so 
there's precedent.  See the ATMA resource record definition.)

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Oct 2008 15:47:46 -0400

On Thu, Oct 09, 2008 at 03:07:02PM -0400, Edward Lewis wrote:

> Why does it have to be an Internet Draft?  The author of the mechanism 
> hasn't asked for IETF review nor RFC Editor for publication.  If the DNSEXT 
> WG wants to discuss someone else's work, the onus is on the group, not the 
> other person.

I agree.  And if we want to discuss it _here_, in this working group,
we need to do that in keeping with the practices of the IETF.  The way
documents are processed in the IETF is with I-Ds.

We can of course recognise non-IETF documents in the definitions of
the protocol.  If a specification for DNSCurve stabilizes outside the
DNS Extensions working group, that's fine: we can deal with it then.
But if we want to discuss how the protocol is going to be defined, and
work out its details, we either need to let that happen outside this
working group (which means on some other list, please) or else do the
development inside the IETF according to IETF conventions.  The IETF
has enough problems with procedure without this working group
inventing new, ad hoc mechanisms for protocol document review.

A

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Oct 2008 16:12:42 -0400

>inventing new, ad hoc mechanisms for protocol document review.

The crux of the matter is, to chop up your words, "if we want to ... 
work out its details."  I don't think that is a decision that is up 
to us.  We may want to work out its details but it isn't ours to play 
with.

I think that we can consider the work when trying to decide our own 
agenda.  In that context, discussing it here is germane even without 
it existing in an IETF approved format.  It is not up to us to demand 
that it be brought here.

We aren't reviewing the work.  No one has asked the IETF for a 
review.  But that doesn't mean we can't discuss it.  I don't want to 
get into a fuss over us trying to "copy" the work into the group. 
Whether or not there are intellectual property concerns (but as I am 
not a lawyer, eeeek, I'm not going to guess).

For those that haven't been around this group for a long time, the 
author of this work, Dan Bernstein, has had a strained relationship 
with the IETF.  Rightly or wrongly, it doesn't matter.  Given history 
I suspect it is unlikely that he would submit his work for IETF 
review.  That doesn't mean we should therefore ignore it.  We can 
form group opinions of the work, but we have no change control over 
it - it is not our work.

(And, yes, I am still just causing trouble here.)

My point is that we have something to talk over now.  The web page 
description has the details needed.  Its not an ID, but, then again, 
how well written is RFC 1034/1035? ;)  There's no change control 
there?  So what, we aren't approving or rubber stamping anything, we 
are just examining the engineering in it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Nicholas Weaver <[email-masked]>
Date: Thu, 9 Oct 2008 13:14:50 -0700

On Oct 9, 2008, at 12:47 PM, Dean Anderson wrote:

> On Thu, 9 Oct 2008, Wouter Wijngaards wrote:
>
>>
> I don't think Kaminsky added this. This 'race-to-win' was only  
> remotely
> relevant after NXDOMAIN was added in 1998, after the balliwick issue.
> When the balliwick issue was being discussed, queries for non-existant
> names were not cached.  I don't recall anyone ever proposing TTL as a
> solution to spoofing attacks, so I don't think it can be a big  
> surprise
> that it wasn't a valid security assumption protecting one from  
> spoofing
> attacks. How could it be surprising when no one ever said that?
>
> NXDOMAIN was a offered as a performance enhancement, not a security  
> fix.
> (see the abstract of RFC2308). Indeed, RFC2308 security considerations
> section actually describes spoofing attacks using NXDOMAIN.
>
> There is nothing 'urgent' in what Kaminsky describes, because there is
> nothing new or novel in what Kaminsky describes. Not even the
> 'race-to-win'.

I don't believe NXDOMAIN behavior has anything to do with this.  It is  
caching the ADDITIONAL records (usually the authoritative nameserver  
records) on what appears to be a VALID (albeit spoofed) reply.

Without the ability to target a name for replacement that is not the  
name being queried (the Kaminski innovation: an ancillatory data  
attack), you are limited in time even with just 16b of entropy, and  
can't effectively attack things like the NS RRSet for .com, even with  
the dinky 16b of entropy.

But with race until win, you can practically attack the NS RRSet  
for .com, in a short amount of time without source port randomization,  
and even in reasonable-effort on the local network WITH source port  
randomization.

Race-until-win is a significant attack innovation.  And I have yet to  
see anything that suggests that race-until-win attacks were known  
prior to Kaminski's work.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Oct 2008 17:21:04 -0400

[No hat]

On Thu, Oct 09, 2008 at 04:12:42PM -0400, Edward Lewis wrote:

> We aren't reviewing the work.  No one has asked the IETF for a review.  But 
> that doesn't mean we can't discuss it. 

I don't see what there is to discuss _in this working group_.  This is
an IETF working group, and we have work to do.  If someone wants to
propose a work item that derives from any of this, then the way to do
that in the IETF is to write an I-D and ask the WG for feedback.  As
you note, nobody has done that.  Therefore, we haven't anything to
discuss here, now.

I know that DNSCurve is interesting, and I think that it probably does
need to be discussed somewhere.  But I think it is important that the
WG focus on the tasks we do have before us, and not ones that we might
like to have, think could be interesting, or whatever.  

Best,

A

---

From: Edward Lewis <[email-masked]>
Date: Thu, 9 Oct 2008 20:06:19 -0400

At 17:21 -0400 10/9/08, Andrew Sullivan wrote:

>I don't see what there is to discuss _in this working group_.

I guess the (and this is probably too far from real work to care 
about) question is - is the mailing list only open to WG agenda 
items.  Namedroppers preceeded DNSEXT and probably will live on after 
the WG is closed.

Maybe there isn't anymore to be said.  But as someone interested in 
the development of the DNS protocol it is helpful to know about all 
of the tricks of the trade being employed in the off chance they 
might roll into the mainstream protocol.

There are many ways in which DNS is operated that have shaped the 
protocol.  There are significant elements of the de jure protocol 
that have never come into the IETF for (complete) review.  (Split DNS 
for one.)  There are folks that take for granted that "views" are an 
essential part of the protocol, not simply a feature started in one 
implementation (and possibly copied to others - I only assume).

I'm cranky when I see "please don't talk about that here" talk 
because that is shutting out what made the IETF interesting, you 
know, the hundred flowers and all  (yeah, 1000 flowers, but the 
origin[0] was 100).  If you think a topic is boring, ignore it - I 
admit I ignore a lot of things on namedroppers (in the sense of "I've 
heard all that before - but not everyone else has - the curse of long 
term subscribing I guess").

It's interesting to see DNSCurve, especially a fairly detailed 
specification of it[1].  The author has been ahead of the curve (no 
pun intended) before.  Not that I think that DNSCurve is going to 
save the day or stave off DNSSEC at this point but nevertheless it's 
something.  And not that I always agree with the author's 
engineering.  (E.g., truncating messages mid RR, not answering lame 
questions at all, tsk, tsk.)  Still it's input to the process of 
engineering a better protocol.  Maybe not this protocol but perhaps 
someday when DNS 2.0 is produced.

Slap, finger snap, wake up --- sorry - I got into some of Bill's meds again.

Demanding an IETF formatted document from people not participating in 
the IETF just because somefolks wanted to talk about it on a mailing 
list run by the IETF  shows a lot of 
http://en.wikipedia.org/wiki/Chutzpa.  I want to keep this group 
relevant to the protocol and how it is used, not see it creep off 
into an ivory tower of protocol purity.  Gotta be "keeping it real."

[0] http://en.wikipedia.org/wiki/Hundred_Flowers_Campaign
[1] http://dnscurve.org/impl.html
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Oct 2008 12:03:11 +0200

On Thu, Oct 09, 2008 at 08:06:19PM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 61 lines which said:

> Demanding an IETF formatted document from people not participating
> in the IETF just because somefolks wanted to talk about it on a
> mailing list run by the IETF shows a lot of

I mostly agree with Ed Lewis here but, if the chairs insist we should
not discuss a protocol which is not an IETF protocol, what are the
other solutions? I am not aware of a mailing list dedicated to the
evolutions of the DNS besides namedroppers. Should someone create a
"[email-masked]"?

---

From: Paul Vixie <[email-masked]>
Date: Fri, 10 Oct 2008 14:11:04 +0000

> "[email-masked]"?

is the future of dns not an ietf topic, then?

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 10 Oct 2008 10:28:06 -0400

[no hat]

On Thu, Oct 09, 2008 at 08:06:19PM -0400, Edward Lewis wrote:

> I guess the (and this is probably too far from real work to care about) 
> question is - is the mailing list only open to WG agenda items.  

In my personal view, no, it's not only open to WG agenda items.  But
we had a fair amount of discussion; and as Paul already pointed out,
the web page does not seem to be a stable specification (it's
changing, or at least has changed considerably and doesn't have any
commitment of stability.  So, from my point of view, we don't have
something stable to discuss.  That's all I've been trying to say.

But I feel strongly that a bottomless rathole about administration of
the group is even less interesting to participants than speculation
about a fluid proposal for new DNS functionality, so I'm going to stop
talking about what's appropriate on the list and leave that decision
to the good judgement of the participants (as I suggested in my
moderation note).  I'd personally prefer a stable thing to discuss,
rather than a sketchy outline on a web page, but maybe that just
reflects my personal working style.

A

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 10 Oct 2008 07:52:01 -0700

> is the future of dns not an ietf topic, then?

I think a better argument/question is "What NEW is there to say about  
DNSCurve that hasn't already been posted to the list?"

I dare say DNSCurve was already done-to-death in previous threads, as  
understanding the systemic advantages and disadvantages didn't need  
much of a specification anyway.

Also, really, DNSCurve has nothing to do really with DNS except it  
uses DNS as a key distribution mechanism.  Its really a datagram-based  
transport-layer security in the same category as DTLS, but with a  
single RTT handshake and using a particular elliptic curve.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Oct 2008 09:06:11 -0700

At 7:52 AM -0700 10/10/08, Nicholas Weaver wrote:
>I dare say DNSCurve was already done-to-death in previous threads, as understanding the systemic advantages and disadvantages didn't need much of a specification anyway.

We fully disagree here. Looking at the diffs in just the last month on the web site, and talking with Dan off-list, I see low-level ideas that were far from clear in earlier versions of the web site.

>Also, really, DNSCurve has nothing to do really with DNS except it uses DNS as a key distribution mechanism.  Its really a datagram-based transport-layer security in the same category as DTLS, but with a single RTT handshake and using a particular elliptic curve.

DTLS for long-term key distribution is different than DTLS for protecting a single query-and-response.

DTLS with a PKIX hierarchy is different than DTLS with an alternate trust model.

And so on.

I think it is unwise to say "we can predict what will be said in the first draft of the protocol", much less what might come out of a group with diverse interests working on that protocol.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 10 Oct 2008 08:58:55 -0700

At 3:07 PM -0400 10/9/08, Edward Lewis wrote:
>Why does it have to be an Internet Draft?

It doesn't; I proposed that as the simplest method for the group to have a stable document to look at. If the authors want to do something more difficult to get a stable document for us to look at, that's probably fine too.

>The author of the mechanism hasn't asked for IETF review nor RFC Editor for publication.

But others have. Note that I did not say Dan Bernstein had to write the draft; I proposed it to others who wanted to discuss the protocol in the IETF.

>If the DNSEXT WG wants to discuss someone else's work, the onus is on the group, not the other person.

How can we tell if we want to discuss some work if we don't know what the work is? As I said in my earlier message, Dan has changed (improved, in my opinion) DNScurve since it was introduced.

--Paul Hoffman, Director
--VPN Consortium

---

From: Dean Anderson <[email-masked]>
Date: Fri, 10 Oct 2008 12:25:30 -0400 (EDT)

> records) on what appears to be a VALID (albeit spoofed) reply.

No, you're not following the attack. Additional NS records are spoofed,
resulting in all further queries going to another Nameserver. (Before 
balliwick, this used to be very common; balliwick was invented to make 
that harder. But as was pointed out back then, still not impossible.

NXDOMAIN has historical relevance to the 'TTL race-to-win' argument. The
race-to-win argument in proper historical context, is complete BS. You
need to re-read my message.

> prior to Kaminski's work.

There is nothing novel in the race-to-win argument. Every spoofing
attack was always assumed to take place before the correct response
arrived, and before NXDOMAIN, there was no correct response.  Even the
NXDOMAIN draft discusses NXDOMAIN being spoofed.

If one looks at the spoofing descriptions, you see brute force described
as "One only needs to send 65k packets before the correct packet
arrives". TTL has nothing to do with anything related to spoofing.

Kaminsky's only 'invention' was the notion that somehow, before
Kaminsky, people thought that TTL was a defense against spoofing. But
that notion was BS to begin with; no one ever thought that.

	--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 9 Oct 2008 15:47:48 -0400 (EDT)

>  The rest is indeed the same.  The race-to-win made the problem very urgent.

I don't think Kaminsky added this. This 'race-to-win' was only remotely
relevant after NXDOMAIN was added in 1998, after the balliwick issue.
When the balliwick issue was being discussed, queries for non-existant
names were not cached.  I don't recall anyone ever proposing TTL as a
solution to spoofing attacks, so I don't think it can be a big surprise
that it wasn't a valid security assumption protecting one from spoofing
attacks. How could it be surprising when no one ever said that?

NXDOMAIN was a offered as a performance enhancement, not a security fix.
(see the abstract of RFC2308). Indeed, RFC2308 security considerations
section actually describes spoofing attacks using NXDOMAIN.

> > So, if you have 200 outstanding ports, with 200 outstanding QIDs,
> > and any correct port can have a coincidence on the 200 QIDs, the
> > cache is spoofed in just under under 5 tries, or in about 943
> > packets!!! Holy added-security flaws!
> 
> birthday attack problems?  

Yes. But that isn't the big issue. It requires about 28 million packets
to be successful, and there are some things I have proposed to make this
even harder (see posts on [email-masked]). But Kaminsky's idea makes
it trivially easy. I haven't checked to see if these ideas were included 
in the 'urgent' patches.

The way DJBDNS (DNScache) works now, a new random port is allocated for
each recursive query, a random QID is selected, and the query is sent.
Packets recieved on that port are checked by a function callled
'irrelevant()', which ensures that the QID and the query are the same.

What was proposed was to reuse ports; that is one port may have multiple
outstanding query ids.  To implement that, one would have to keep track
of all the valid outstanding query ids (probably over all ports), and
check any incoming packet on a valid port to see if its query id matches
one of the valid outstanding query ids. So one may also have a
coincidence over the query ids. The combination of two coincidences
drastically reduce the strength of using random port numbers and random
QID, as the math shows.

> Or do you assume in the above that this is the same query that is sent
> out with multiple outstanding ports/multiple outstanding QIDs?

If you reuse the port, presumably, it is for different queries; but the
same query could be repeated by different clients. So all outstanding
queries could be arranged to be the same textual query. Follow?

> via the CD bit to verify that data itself, with its own security policy.

I don't think this is completely correct. If the site intends to offload 
verification on the stub resolver, then the stub has to set the CD bit. 
Such cache setups can be poisoned.

I seem to recall (but haven't verified in the RFCs), that when 
unverified data is cached in the 'bad cache', and the stub doesn't set 
the CD bit, that the cache is supposed to return an error in that case.

And of course, if the cache does verify, it is vulnerable to attacks in 
which many hard to verify records are requested at a high rate.

And of course, I didn't mention before that in either case,
cryptographically valid (but replaced) records can be used to poison the
cache, too. Indeed, in some cases, (specially nsec with unverified
delegations), spoofed delegations can be _created_ in secure zones using
the replaced (but still crypto valid) NSEC records. The stub resolver
will conclude these are valid records.

		--Dean

---

From: Paul Vixie <[email-masked]>
Date: Fri, 10 Oct 2008 16:59:16 +0000

> In my personal view, no, it's not only open to WG agenda items.  ...

in my personal view, dnscurve competes with dnssec in that if either is
deployed the other will be a curiousity.  i don't mind seeing this mailing
list used to discuss experimental topics, the greatest minds of dns are all
here and it's a good way to reach them.  what i want from ietf is not a
shutdown of the dnscurve discussion but rather a clear statement that ietf
is not reopening the debate as to whether dnssec is our chosen solution.  i
want this for the simple reason that we will otherwise never complete any
task that takes more than a generation, since every new generation of dns
protocol architects will want to throw out the mistakes of the past and
just do what makes sense to them.

saying "where's the I-D?" is just a way of backing into the question that's
actually important which is: "is ietf willing to change its direction?" and
it's important that we actually ask and answer that real question since we
will otherwise confuse and terrify the people who have deployment decisions
to make.

so if ietf can periodically and strongly reiterate its position on dnssec's
viability and desireability, then discussions of dnscurve or other new ideas
will be nondisruptive and the participants of this mailing list can either
read, reply, or killfile, as they see fit.

the way a country puts a man on the moon is that one president says we ought
to do it and the next president says ok even though i'd rather go to mars we
will go to the moon since that's the multigenerational project we're in the
middle of right now.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 10 Oct 2008 10:08:26 -0700

On Oct 10, 2008, at 9:06 AM, Paul Hoffman wrote:
>> I dare say DNSCurve was already done-to-death in previous threads,  
>> as understanding the systemic advantages and disadvantages didn't  
>> need much of a specification anyway.
>
> We fully disagree here. Looking at the diffs in just the last month  
> on the web site, and talking with Dan off-list, I see low-level  
> ideas that were far from clear in earlier versions of the web site.

The differences are ones in terms of implementation details.  The high  
level structure and tradeoffs of channel confidentiality & integrity  
vs object integrity are the key distinction for purposes of "Does  
DNSCurve make sense as an alternative/addition to DNSSEC".

And for purposes of securing DNS transactions against an adversary,  
channel integrity is STRICTLY less powerful than object integrity  
(look at the problems of corrupted recursive resolvers, which DNSSEC  
can address but DNSCurve can not), while channel confidentiality is  
almost nonexistant in the face of traffic analysis for DNS.

Likewise, the transitivity of trust and trust heirarchy still remains  
completely unchanged from DNSSEC, the only difference there is rather  
than having the key explicitly signed by the +1 domain up, the key is  
implicitly "signed" by being returned by the +1 domain up as the  
nameserver's name.

This simply means you have an implicit short-lived certificate who's  
expiration is equal to the TTL rather than an explicit longer-lived  
certificate.

Nothing in the different drafts have changed these primary properties,  
and for "Is DNSCurve a viable alternative to DNSSEC", it is these  
properties, not details on the encoding of keys in names or the  
computational and network overhead of signatures, that is the problem,  
and these aspects have been discussed to death.

>> uses DNS as a key distribution mechanism.  Its really a datagram- 
>> based transport-layer security in the same category as DTLS, but  
>> with a single RTT handshake and using a particular elliptic curve.
>

DNSCurve has a PKI heirarchy, it is just implicit (and sometimes  
lacking signing if the upstream DNS provider doesn't support DNSCurve)  
rather than explicit, and is forced to follow the DNS trust heirarchy  
(the same heirarchy that DNSSEC follows).

> I think it is unwise to say "we can predict what will be said in the  
> first draft of the protocol", much less what might come out of a  
> group with diverse interests working on that protocol.

For the HIGH LEVEL viewpoint, you can:  DNSCurve is a channel  
confidentiality and integrity protocol, with a key distribution  
mechanism which uses the DNS as an implicit PKI.  Period.  Anything  
that changes this you can't really call DNSCurve anymore.

And the implementation details/items of interest really belong in a  
transport-layer security working group.  Apart from an implicit PKI  
based on DNS rather than a separate explicit PKI, DNSCurve really has  
nothing to do with DNS but everything to do with datagram-oriented  
channel integrity & confidentiality.  So why should such details be  
discussed here?