Subject: Re: DNSSEC - Signature Only vs the MX/A issue.

From: Florian Weimer <[email-masked]>
Date: Sat, 02 Dec 2006 21:14:18 +0100

* Mike StJohns:

> Any other ideas in this general topic?

I think this could be addressed in a straightforward manner, keeping
the spirit of SO, if you published a signed bitmap of all permitted
RTYPE/RCLASS combinations for a particular value.

If you wonder if this is worth the additional complexity, it seems to
me that this is less complex than the A/MX heuristics described
earlier in the thread.  At least it's completely deterministic.

There is a significant overhead, of course, compared to SO as
proposed, but less so compared to plain old DNS.

--
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: Paul Vixie <[email-masked]>
Date: Sat, 02 Dec 2006 22:26:15 +0000

i'm having trouble understanding the scope of this discussion.  the working
group refused to consider a simpler design that lacked, among other things,
secure nxdomain.  masataka ohta wrote up a viable proposal 11 years ago and
the working group went the other direction.  now, to the extent that dnssec
will ever be deployed, the industry as represented in this working group has
chosen to deploy a more complicated design.

if we are readdressing our original scope, then let's look at masataka ohta's
simpler design from 11 years ago, and let's stop working on NSEC3 and "white
lies" and so on.  i for one think that would be a bad idea, both because we
have invested a lot of time and money in the current design, and because i am
more comfortable with secure denial of existence, even with all its costs.

but this third way forward is mystifying me.  i am mystified that msj brought
it up at all; i am curious to know who, among the deployment communities (who
are domain holders, domain registrars, domain registries, client implementors,
server implementors, server operators, and internet governance institutions),
feels ready to discard the current design at this, the 11th hour (which we
have already reached and retreated from seven times in 12 years), and move
back to something that the industry rejected in 1995 or so when eastlake/
kaufman was chosen over the ohta design.  and if we're moving backward, why
are we reinventing it rather than reusing ohta's perfectly reasonable design?

i am completely amazed to see anyone here arguing technical merits on another
fundamental change in direction.  does anyone really believe that if the ietf
starts over an 8th time on this technology, that any potential deployer will
ever again take this working group seriously?

msj, this isn't a personal slam.  from a quick glance, your proposal looks to
be every bit as good as ohta's.  the quality of the proposal is not in doubt,
only the timing and strategy.

re:

> From: Florian Weimer <[email-masked]>
> To: Mike StJohns <[email-masked]>
> Cc: [email-masked]
> Subject: Re: DNSSEC - Signature Only vs the MX/A issue.
> Date: Sat, 02 Dec 2006 21:14:18 +0100
> Sender: [email-masked]
> 
> * Mike StJohns:
>

---

From: Mike StJohns <[email-masked]>
Date: Sat, 02 Dec 2006 18:41:49 -0500

Hi Paul -

Thanks for your note, and I appreciate it's not an attack on me.  You 
asked why:

 From http://www.whitehouse.gov/omb/circulars/a094/a094.html -

Sunk Cost -- A cost incurred in the past that will not be affected by 
any present or future decision. Sunk costs should be ignored in 
determining whether a new investment is worthwhile.

The above, although cribbed from a government publication is a good 
general business practice - ignoring it is how businesses go bankrupt.

>  i for one think that would be a bad idea, both because we
>have invested a lot of time and money in the current design,

Unfortunately, that sentiment seems to be widespread.

The entire development of DNSSEC up to this point is sunk costs - the 
amount of investment is no predictor of the success of the 
development.  After 14 years, with no firm date for completion in 
sight and no guarantee that there won't be yet another show stopper - 
I think it's reasonable to re-consider the direction, or at least 
have some fall back position.

Here's the timeline as I understand it:

~1986 - the Protocol Standards technical panel of the DOD identified 
the need to have a way to validate DNS data
~1992-3 - TIS submitted a proposal to ARPA for research in this area 
- a 3+ year contract (or maybe a task order against an existing 
contract) was awarded.

1999 - DNSSEC was declared done with the publication of RFC2535
2000-2002 - OK, maybe some twiddles - new RFCs covering some changes 
- no real deployment of DNSSEC
2003 - Publication of DS RFC
2004 - Typecode rollover discussions
2005 - DNSSEC declared done again with the publication of 4033, 4034, 4035
2005 - OK... maybe not done - NSEC not sufficient for certain zone 
operators  - some zones (e.g. NL) signed, few signed deletations
2006 - Still working on NSEC3, few signed delegations
2007 - Maybe NSEC3 complete, maybe more show stoppers

So blaming my proposal as a distraction seems to be a bit ... 
unreasonable.   It may be more reasonable to blame the lack of 
attraction of DNSSEC to the zone operators and the lack of any 
application driven desire for DNSSEC for its failure to take hold up 
to this point.

WRT to Ohta's design - I've actually never seen it.  It may be 
perfectly fine, but my guess is that it doesn't provide even a hint 
of interoperability with the 4033-4035 DNSSEC and I was hoping to at 
least use the existing server code base.

In general, my proposal is targeted at the space mostly ignored by 
PNE DNSSEC - that of how an application uses signed DNS data.  I 
don't actually consider this a change in direction, rather one that 
could focus this deployment on the use of the data rather than simply 
the signing of it for signing's sake.

I've heard the sentiment "Stay the course" too much over the last 4 
years -both here and in American politics - the arguments for both 
tend to get weaker the longer things go on.

Finally, you asked about 11th hour.  When I came back into this 4 
years ago people swore it was done and that other proposals weren't 
needed.  Last year it was "NSEC3 is almost done - have patience" - 
the same this year. I actually waited three and a half years on this 
or 25% of the total time period.  While it may be true that NSEC3 is 
almost, I can't predict the future and sunk cost analysis suggest 
that I shouldn't attempt to.  So the proposal came out after many 
patient years.  I'm sure if I had submitted this at the beginning of 
the NSEC3 discussions I would have gotten the same "11th hour" 
comments.  So feel free to ignore it - I''ll keep it live as a draft 
for a year or so and we can talk about 11th hour issues again in 
about a year or two while we're waiting for NSEC4.  :-)

You decry my timing and strategy, but I ask you when if not 
now?  Should I have submitted this as a place holder 3 years ago when 
roughly the same argument was made to me?  Should I have waited until 
NSEC3 was complete - if ever?  Never?  If the latter really is the 
answer, then the IETF is a vastly different organization that it used to be.

Later, Mike

---

From: Paul Vixie <[email-masked]>
Date: Sun, 03 Dec 2006 00:18:01 +0000

> ... blaming my proposal as a distraction seems to be a bit ...unreasonable.
> It may be more reasonable to blame the lack of attraction of DNSSEC to the
> zone operators and the lack of any application driven desire for DNSSEC for
> its failure to take hold up to this point.

i think the lack of attraction is explainable separately from the quality or
complexity of the current official design.  kc said it best, on one of steve
crocker's concalls, when steve asked "what's the one thing the community
needs to begin dnssec deployment?" and kc answered, "motivation."  dnssec is
a classic internet design, demanded by military/government types.  it is not
like the web or ssl, demanded by the market and/or useful for commerce.  if
you're trying to create motivation, then adding an 8th 11th-hour retrenching
isn't the way.  if you're trying to overcome inertia and/or improve the
cost:benefit toward a more compelling level, then again, adding an 8th 11th
hour retrenching to the schedule is not your best move.

> WRT to Ohta's design - I've actually never seen it.  

that's a sad statement in and of itself.  you're acting like a latecomer who
has all the answers but hasn't done a lot of research and/or homework.  since
i know you better than that, i am mystified.  what kind of deployment community
backing have you received that made your current proposal seem useful?

> In general, my proposal is targeted at the space mostly ignored by PNE
> DNSSEC - that of how an application uses signed DNS data.  I don't actually
> consider this a change in direction, rather one that could focus this
> deployment on the use of the data rather than simply the signing of it for
> signing's sake.

as most of us have been saying for a decade, the major reason to deploy dnssec
is that it will protect nameservers from following evil NS/A/AAAA chains.  if
there's a secondary benefit (that dnssec is useful in commerce or antispam
or antiphish or whatever) then such secondary benefits will not be known or
visible until after the basic infrastructure is in place.  that's due to the
chicken-or-egg problem, folks won't sign their zones until it improves their
lives, and folks won't install a validators until it improves their lives.
something had to be the first mover.  obviously, that's the NS/A/AAAA chains.

> ... I'm sure if I had submitted this at the beginning of the NSEC3
> discussions I would have gotten the same "11th hour" comments.  So feel free
> to ignore it - I''ll keep it live as a draft for a year or so and we can
> talk about 11th hour issues again in about a year or two while we're waiting
> for NSEC4.  :-)

here, you are preaching to the choir.  i wasn't going to propose EDNS until
DNSSEC was done, but in 1998 donald eastlake convinced me that there was time.
michael graff and i decided not to propose "slabbed DNS" with security as
metadata in 2002 because we didn't want to muddy the waters.  a bazillion
people have told me not to bother deploy DLV since NSEC3 is coming real soon
now.  a couple of times per year, i drag something up from the old jim galvin
dns-security mailing list archive and repost it to namedroppers under the
subject, "on this date in 1997" or whatever, and it'll be the same thread all
over again.  i hate this whole thing.  dnssec is the worst design-by-committee
effort i've ever seen, both in terms of how late it is, how fuzzy the goals
have been, how often the goals have changed, and how complicated and heavy it
is now that it is trying to be all-things-to-all-people.

but you won't improve it by adding an 8th 11th-hour redesign.  all you could
do would be to convince anybody who has been waiting for dnssec that they'll
have to go their own way.  are you failing to grasp that any change to the
way this stuff works will take at least two years to stop arguing about and
test-in-lab and write code for and so on?  and that the real deployment work
will not begin until those moments stop coming?  and that real deployment
will take five years once it starts?

> You decry my timing and strategy, but I ask you when if not now?  Should I
> have submitted this as a place holder 3 years ago when roughly the same
> argument was made to me?  Should I have waited until NSEC3 was complete -
> if ever?  Never?  If the latter really is the answer, then the IETF is a
> vastly different organization that it used to be.

never.  because the IETF is a vastly different organization than it used to
be.  and while you're hitting on the reasons we tried to start MODA, that's a
separate discussion (and, MODA is dead, since it could not overcome inertia.)

---

From: Edward Lewis <[email-masked]>
Date: Sun, 3 Dec 2006 00:02:20 -0500

At 0:18 +0000 12/3/06, Paul Vixie wrote:

(MSJ) > WRT to Ohta's design - I've actually never seen it.
>backing have you received that made your current proposal seem useful?

That's a bit harsh.  Ohta's proposal is very hard to find.  I've 
tried, and eventually did get a copy.   Here's a URL for it.

http://www.watersprings.org/pub/id/draft-ohta-simple-dns-02.txt
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Dessert - aka Service Pack 1 for lunch.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 3 Dec 2006 07:59:32 -0200

On Sat, Dec 02, 2006 at 10:26:15PM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 65 lines which said:

> the working group refused to consider a simpler design that lacked,
> among other things, secure nxdomain.  masataka ohta wrote up a
> viable proposal 11 years ago

Thanks to the archaeologist Ed Lewis, I've read this draft and I'm
puzzled: it does cover PNE for domains, with the ZL record (and PNE
for types with the RRD record). Ohta's proposal does not seem to be SO
and therefore does not seem to be a direct competitor of St John's.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 3 Dec 2006 08:07:14 -0200

On Sat, Dec 02, 2006 at 09:14:18PM +0100,
 Florian Weimer <[email-masked]> wrote 

> RTYPE/RCLASS combinations for a particular value.

This moves the complexity to the resolver, which would have to
remember, when receving (NOERROR, Answer=0) to retrieve the signed
bitmap and to check it.

But, yes, it seems simpler than the RRD in Ohta's draft (recently
resurrected).

---

From: Ralph Droms <[email-masked]>
Date: Sun, 03 Dec 2006 08:10:57 -0500

I'm very interested in the problem of motivation, because I'm part of an
organization that is trying to predict customer motivation, which will
predict customer demand for DNSSEC features in our products.  We can use
those predictions to guide our decision about when to have those DNSSEC
features ready for our customers.

As far as I can tell, there is no market/commerce motivation today.  Attacks
that can be mitigated by DNSSEC are not in the public consciousness like
spam or malware or phishing attacks.  Do we have documented evidence of
specific successful attacks that can be mitigated by DNSSEC?

What is the direct, immediate RoI for the resources I have to commit to
providing DNSSEC resolution for names in my zone?  My external contacts
("customers") may benefit from mitigation of attacks, but that's an indirect
benefit.  

The motivation driving deployment problem is compounded by the complexity
(as measured by the number of moving parts) of the solution, which results
in a chicken-and-egg problem.  My organization may benefit by enabling
DNSSEC resolution on my internal hosts and recursive servers, but that
benefit only accrues if the sites I access provide DNSSEC.

The motivation factor seems to be necessary (although not sufficient) to
drive DNSSEC deployment...

- Ralph

---

From: bert hubert <[email-masked]>
Date: Sun, 3 Dec 2006 15:53:17 +0100

> specific successful attacks that can be mitigated by DNSSEC?

Yes, there have been succesful spoofing attacks, whereby end-users end up on
a different website from the one they thought they were visiting. These
attacks could have been prevented without DNSSEC however, and any website
that is truly important uses SSL, which would flag the misdirection (which
would then be ignored).

Such spoofing has actually happened a number of times, but hasn't really hit
the news.

It is also easy to do, to quote from 
http://www.ietf.org/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt

   The calculations above indicate the relative ease with which DNS data can
   be spoofed.  For example, using the formula derived earlier on a domain
   with a 3600 second TTL, an attacker sending 7000 fake answer packets/s (a
   rate of 4.5Mb/s), stands a 10% chance of spoofing a record in the first
   24 hours, which rises to 50% after a week.

   For a domain with a TTL of 60 seconds, the 10% level is hit after 24
   minutes, 50% after less than 3 hours, 90% after around 9 hours.

I've written some tools that perform this action, when you manage to
saturate the bonafide authoritative servers, success is achieved within
seconds. Partial saturation means somewhat longer time is needed. The
calculations above are for the non-saturated case.

> ("customers") may benefit from mitigation of attacks, but that's an indirect

They might conceivably worry more over the (inherent) higher reliability
problems of DNSSEC: there are far more failure modes. This is not DNSSECs
fault, it is inherent in any protocol that gets encryption added to it.

This is why I favor (immediate) ameliorization measures, as outlined in my
draft, which are easy to implement. 

However, recapping, there IS a problem that needs to be solved.

	Bert

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

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 04 Dec 2006 05:53:09 +0900

Mike StJohns wrote:

> ~1992-3 - TIS submitted a proposal to ARPA for research in this
> area - a 3+ year contract (or maybe a task order against an
> existing contract) was awarded.

It maybe the reason why TIS's proposal was chosen without any
real (Paul's confusion on my proposal is an evidence) discussion.

> for types with the RRD record).

Yese, it does everthing DNSSEC does. The difference is that my
proposal avoided, by design, all the gotchas related to CNAME, glue,
UDP size overflow and so, most of which was confirmed with an
implementation.

OTOH, TIS's proposal was not implemented and was claimed to have
some minor features intentionally missing from mine, all of which
is useless/harmful/impossible and was, later, dropped.

> Ohta's proposal does not seem to be SO

It's trivially easy to add my propoal some record that a zone does
not support ZL.

However, even though my proposal makes more simpler to
implement, deploy and operate, the real problem of DNSSEC is
that it is merely weakly secure.

That is, if you can blindly believe that all the namesever
operators between you and your peer are secured, you can blindly
believe that all the ISPs between you and your peer are secured.

						Masataka Ohta

---

From: Shane Kerr <[email-masked]>
Date: Mon, 04 Dec 2006 11:45:03 +0100

[ Apologies for a mostly non-technical mail that says what everybody already
knows. ]

> ("customers") may benefit from mitigation of attacks, but that's an indirect

Isn't this always the case with security though? What is the direct, immediate
RoI for putting a lock on your door?

I think the reason things like DNS and routing security don't get much traction
is because there is much lower hanging fruit for attackers. If the end points of
the Internet weren't so insecure, then things would be different.

If DNSSEC stabilizes after NSEC3, then DNSSEC could slowly become part of the
BCP for network operators. The blocking factor here is the TLD (and the root),
which has little or nothing to do with RoI.

- --
Shane

---

From: bert hubert <[email-masked]>
Date: Mon, 4 Dec 2006 13:39:30 +0100

> RoI for putting a lock on your door?

Try removing the lock from your office building and you find out quickly
enough.

Security IS part of doing business, and if it is more effort than it is
perceived to be worth, people don't do it. 

Perception is the key word here though.

My feeling however is that the full cost of DNSSEC (even without NSEC3)
vastly outweighs any perceived (or even: real) benefit.

See http://ds9a.nl/secure-dns.html for some further discussion. I don't
doubt DNS needs better security, but it doesn't warrant anything really
complex.

	Bert

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 4 Dec 2006 12:02:30 -0200

On Mon, Dec 04, 2006 at 11:45:03AM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 38 lines which said:

> Isn't this always the case with security though? What is the direct,
> immediate RoI for putting a lock on your door?

You get a big cut in your insurance costs . That's a RoI!

[This could be a good model for DNSSEC. In the real world, decisions
about security are not taken based on technical merits. They are taken
based on what the insurance companies require.]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Dec 2006 09:15:56 -0500

>specific successful attacks that can be mitigated by DNSSEC?

I have seen just one attack documented.  It isn't like the attack 
that Bert Hubert describes, I'll explain that later.

http://www.alvestrand.no/subjects/dns-attack-1.html documents the one 
case.  This is not a "it could happen" but an attack that did happen.

The attack works on manipulation of data within the registration 
system.  It could be the result of subscriber fraud (such as using a 
fake credit card) or it could be the result of a hiccup in the 
registration process.

The hiccup begins with using an out-of-bailiwick name server that is 
so out-of-bailiwick the name server is in another domain.  There's no 
tractable way for the expiration of a domain name to trigger a check 
of all uses of name servers in that domain across all other 
registries.

A tractable defense to this is to have zones that use out of 
bailiwick servers to check on the expiration dates of the domains 
homing their slaves.  This could be built into a name server product 
or a zone management product.

Or completely avoid of out-of-bailiwick name servers.  (Peter - I'm 
just saying...)

DNSSEC would be one way to address this situation (I wouldn't call it 
an attack necessarily), with the alternative being tighter defense 
against subscriber fraud and diligent management of out-of-bailiwick 
name servers.  (Said in the vein that RFC 2181 and the code Andreas 
mentioned on the list are an alternative to DNSSEC when fighting 
cache poisoning.)

The attack that Bret mentions (I forget if it is a prediction or an 
observation - I think it is a prediction because he uses formal math 
to describe it) is something that is of concern.  But it is cache 
poisoning a directed attack at poisoning a particular server.  The 
situation documented by Harald is a widespread situation, when it is 
pulled off, all iterating name servers "will fall victim" to it not 
just the targeted one(s).

---

From: Edward Lewis <[email-masked]>
Date: Mon, 4 Dec 2006 09:45:07 -0500

>Perception is the key word here though.

No pun intended, yes, it's all perception.

>vastly outweighs any perceived (or even: real) benefit.

Having worked with DNSSEC for more than two years, I know a lot about 
what DNSSEC is.  But knowing how (well) it is constructed doesn't 
mean it is the right solution to the problems we have now.

Times change, problems change.  What was probably the best solution 
in 1996 might not be the best solution in 2007.  Just because DNS has 
a vulnerable protocol state and DNSSEC offers a means to defend it 
does not mean DNSSEC is the answer.

This doesn't mean DNSSEC ought to be abandoned.  But I do wonder why, 
if DNSSEC is the solution to problems, that it isn't wholeheartedly 
adopted?  I don't hear anyone saying "I'd love to use DNSSEC, but 
could you adjust it here or there?"  I.e., I don't see a building 
demand for it.

DNSSEC does take a water-tight approach to security, it would be able 
to defend a lot of forms of attack and supports all of the robustness 
principles of the DNS (caching, replication, etc.).  But is the 
effort to be this secure worth the cost?  I haven't seen anyone who 
says yes to the latter with an open wallet.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Paul Vixie <[email-masked]>
Date: Mon, 04 Dec 2006 15:24:55 +0000

> This doesn't mean DNSSEC ought to be abandoned.  But I do wonder why, if
> DNSSEC is the solution to problems, that it isn't wholeheartedly adopted?

because, like AV products for home PC's, most folks who need this technology
do not know that they need it.  without marketing, there is no market.  (duh!)

---

From: [email-masked]
Date: Mon, 4 Dec 2006 15:52:06 +0000

> says yes to the latter with an open wallet.

	those w/ open wallets are now w/ empty wallets and nothing (much)
	to show for it.  :)

--bill

---

From: Paul Vixie <[email-masked]>
Date: Mon, 04 Dec 2006 17:16:27 +0000

> I don't think I've ever seen an insult done as subtly and smarmily as the
> one above.   Congratulations on your use of the English language.

mike, i think we're done here.

---

From: Mike StJohns <[email-masked]>
Date: Mon, 04 Dec 2006 12:12:21 -0500

>hour retrenching to the schedule is not your best move.

I'm not adding anything to the schedule.... feel free to complete and 
deploy NSEC3 on schedule.. what is that schedule by the way?

>backing have you received that made your current proposal seem useful?

I don't think I've ever seen an insult done as subtly and smarmily as 
the one above.   Congratulations on your use of the English language.

I actually did a fair amount of research and homework as you well 
know.  I also discussed the generics of my proposal with many people 
who have been involved with DNSSEC over the last 4 years and Ohta's 
proposal never came up.  If it had, having now looked at it, I 
wouldn't have used anything from it as it had no interoperability 
with 4033-4035.  Finally, after I presented SO at the IETF a number 
of people who are trying to deploy DNSSEC found me to chat - and said 
that this proposal might actually speed deployment.

>have to go their own way.

You seem to be all out of proportion afraid of one simple 
proposal.  If the DNSSEC train can be derailed by such a simple thing 
(think penny on the track) isn't it possible that the track needs 
rebuilding or the engine needs redesign?

>are you failing to grasp that any change to the

Actually, given reactions from folks like you I've about decided to 
publish it as experimental - as a profile of 4033-4035 with 
extensions.  That should have it done mostly at the next IETF.  For 
code - well stub zones without further delegation will run on 
4033-4035 compliant servers (already have a few proof of concepts 
there).  The changes to 4033-4035 authoritative and recursive servers 
for full compliance mainly involve teaching them that OSIG should be 
treated like RRSIG(DNSKEY) and DSSO like the DS record.  For 
deployment, if someone thinks they can make money signing OSIG 
records I'll bet that would happen sooner than 5 years.  For the 
application side - that's a bit harder, but since validators for 
4033-4035 already exist for a few apps, not as hard as you would 
think as SO validation is a subset of PNE validation.

>separate discussion (and, MODA is dead, since it could not overcome inertia.)

And that's what happens when political considerations override 
technical ones... sad.

If you've got further technical arguments to make - please make 
them.  I'm done with this political thread.

Later, Mike

---

From: Robert Story <[email-masked]>
Date: Mon, 4 Dec 2006 13:22:38 -0500

On Mon, 04 Dec 2006 12:12:21 -0500 Mike wrote:
MS>   The changes to 4033-4035 authoritative and recursive servers 
MS> for full compliance mainly involve teaching them that OSIG should be 
MS> treated like RRSIG(DNSKEY) and DSSO like the DS record.  For 
MS> deployment, if someone thinks they can make money signing OSIG 
MS> records I'll bet that would happen sooner than 5 years.  

I find this interesting, since you've said yourself that you haven't
figured out a way for a resolver to know if it should expect an OSIG
record (and thus know if it's been stripped). Which is too bad, I think
off-tree signing would be very nice to have.

-- 
Robert Story
SPARTA

---

From: Mike StJohns <[email-masked]>
Date: Mon, 04 Dec 2006 14:03:33 -0500

>off-tree signing would be very nice to have.

Sorry - apples and oranges here.

The presence of a RRSIG(DNSKEY) hint (e.g. with a special algorithm 
type) tells a validator/resolver to look for an OSIG record at the 
apex regardless of whether it was returned under a DO query.  If it 
finds the OSIG, the validator  can use the OSIG to create a chain of 
trust into the zone.

Under PNE, the presence of a trust anchor implies that I should be 
able to complete a proof of existence or non-existence for any query 
subordinate to that trust anchor.  That's really the first part of 
the validation algorithm - setting the expectation before ever 
retrieving any data.  If the OSIG zone is not under a trust anchor, 
then the RRSIG and OSIG could be stripped without ever causing the 
PNE validator to reset the expectation from unsigned to signed 
resulting the zone being treated as "unknown" or "unsecure"

In SO - all unvalidated answers are equally bad so this isn't a problem.

So you could use this mechanism for PNE, but the results for a zone 
signed by OSIG but not subordinate to a trust anchor would be no 
better than SO.  (Hmm... I guess you could include NSEC records for 
the zone, but the signalling for whether a zone is PNE or SO is done 
by choice of DS or DSSO so you'd have to encode that in the OSIG).

The way this OSIG/RRSIG hack works is that the OSIG is treated by a 
non-SO-compliant server like any other non-dnssec data - (E.g. 
RFC3597 master file representation syntax).

Mike

---

From: Robert Story <[email-masked]>
Date: Mon, 4 Dec 2006 14:43:05 -0500

On Mon, 04 Dec 2006 14:03:33 -0500 Mike wrote:
MS> At 01:22 PM 12/4/2006, Robert Story wrote:
MS> >On Mon, 04 Dec 2006 12:12:21 -0500 Mike wrote:
MS> >MS>   The changes to 4033-4035 authoritative and recursive servers
MS> >MS> for full compliance mainly involve teaching them that OSIG should be
MS> >MS> treated like RRSIG(DNSKEY) and DSSO like the DS record.  For
MS> >MS> deployment, if someone thinks they can make money signing OSIG
MS> >MS> records I'll bet that would happen sooner than 5 years.
MS> >
MS> >I find this interesting, since you've said yourself that you haven't
MS> >figured out a way for a resolver to know if it should expect an OSIG
MS> >record (and thus know if it's been stripped). Which is too bad, I think
MS> >off-tree signing would be very nice to have.
MS> 
MS> 
MS> Sorry - apples and oranges here.
MS> 
MS> The presence of a RRSIG(DNSKEY) hint (e.g. with a special algorithm 
MS> type) tells a validator/resolver to look for an OSIG record at the 
MS> apex regardless of whether it was returned under a DO query.  If it 
MS> finds the OSIG, the validator  can use the OSIG to create a chain of 
MS> trust into the zone.

I guess I wasn't clear.. I was referring to this paragraph from your
initial message on off-tree signing:

> If a DNSSEC aware client makes a query into the DNS tree for data 
> that is not subordinate to one of the trust anchors it knows about 
> (e.g.  it olny knows about .COM, the query is for "FOO.NET"), that 
> data is automatically treated as not-signed by the validator.  Say 
> that foo.net has an off tree signature - there's no way to convey to 
> the validator that this part of the tree is signed - a simple 
> deletion attack could remove any DNSSEC data and the validator 
> wouldn't know the difference.

So, my observation was simply that I can't imagine people signing up
for OSIGs when a deletion attack is so simple...

-- 
Robert Story
SPARTA

---

From: bert hubert <[email-masked]>
Date: Mon, 4 Dec 2006 20:49:58 +0100

> deploy NSEC3 on schedule.. what is that schedule by the way?

Also - if DNSSEC were to be a success, NSEC3 would be the most complex part
of *any* protocol actually used on the internet. It even beats H.323.

Not many protocols require mathematical problem solvers embedded in mission
critical software.

> You seem to be all out of proportion afraid of one simple proposal.  If
> the DNSSEC train can be derailed by such a simple thing (think penny on
> the track) isn't it possible that the track needs rebuilding or the engine
> needs redesign?

DNSSEC has been derailed many times already. 

Signature Only however might fit the 'cost/benefit' balance.

> extensions.  That should have it done mostly at the next IETF.  For 

That is one other problem of DNSSEC - it is absorbing most of the 'brain
cycles' of DNSEXT members. Non-DNSSEC drafts struggle to get enough
attention, even those which would have an immediate positive influence on
DNS security.

Which I understand, a lot of time is needed to work through all DNSSEC
drafts and proposals etc.

But it is sad nonetheless. You may find the same problem getting people
willing to proofread your RFC.

	Bert

---

From: Mike StJohns <[email-masked]>
Date: Mon, 04 Dec 2006 14:58:19 -0500

>for OSIGs when a deletion attack is so simple...

For SO - its a "don't care" or rather  "unvalidatable signed data 
(e.g. because of deletion) is no better than unsigned data.  That's 
the basic design of SO....  the only output of the validator is 
either validated or unvalidated - if the former, do the "secure" 
thing, if the latter do something else.

---

From: Mike StJohns <[email-masked]>
Date: Mon, 04 Dec 2006 15:09:23 -0500

>thing, if the latter do something else.

Hmm.. let me expand this.... with the sole exception of a delegation 
into an unsecure zone you use PNE to  prove that the data you asked 
for doesn't exist (NB - at the time you ask).  What the practical 
result of that is that you won't try and connect (because ... 
duh  :-) ... you don't have the data).

If you get a valid/exists result in PNE you pretty much never look at 
the non-existence data - so this is directly equivalent to SO.

If you get a bogus result (e.g. an inability to either prove or 
disprove the existence of data) - that's equivalent to an 
"unvalidated" result in SO - both PNE and SO will generally treat 
bogus/unvalidated as not secure and take some action less than the 
"secure" action.

It's only the corner cases - the provably unsecure set of records 
(either not under a trust anchor or under a securely unsecure 
delegation) where PNE and SO treat results differently.  SO treats 
anything that it can't validate as unvalidated.  PNE treats data that 
it didn't know how to validate as better than data it did know how to 
validate, but for which it wasn't able to complete the validation 
(e.g. better than bogus data).

Hmm...

---

From: bert hubert <[email-masked]>
Date: Mon, 4 Dec 2006 21:30:59 +0100

> for OSIGs when a deletion attack is so simple...

Without intercepting traffic from either the client or the authoritative
nameserver, a deletion attack is only easy if the source port and DNS id of
queries are predictable.

People with the ability to intercept and inject packets are rare compared to
those able to spoof data from non-BCP 38 compliant networks - who I
currently consider the gravest danger to the DNS.

	Bert

---

From: bert hubert <[email-masked]>
Date: Mon, 4 Dec 2006 21:00:14 +0100

> says yes to the latter with an open wallet.

We've asked many of our customers and users this exact question: would you
be willing to fund DNSSEC development in PowerDNS, and the answer has so far
always been a resounding 'no'.

We've seen people list "DNSSEC" (w/o further specification) as a
requirement, but nobody clamoured for it enough to pay a (modest) premium
for it.

To put this statement into perspective, in many areas, including some of the
largest internet markets (ie, Germany), PowerDNS controls >50% of domains
right now, and in others over 40% of resolving needs.

So if there were a 'hidden demand' for DNSSEC, or even 'more secure DNS'
we'd heard of it by now.

And I agree fully with Bill Manning's statement that most people previously
willing to fork over money for DNSSEC protocol development now have "an
empty wallet, and nothing (much) to show for it".

	Bert

---

From: David Blacka <[email-masked]>
Date: Mon, 04 Dec 2006 16:20:50 -0500

> of *any* protocol actually used on the internet. It even beats H.323.

Er, no.

> Not many protocols require mathematical problem solvers embedded in mission

What are you talking about?

I feel compelled to point out that NSEC3 isn't that complicated to
actually *do*.  If it is complex, it is complex to analyze.  That is, it
can be hard to convince yourself that it works without a bit of mental
stretching.

-- 
David Blacka                      <[email-masked]>
Sr. Engineer    VeriSign Infrastructure Product Engineering

---

From: bert hubert <[email-masked]>
Date: Mon, 4 Dec 2006 22:37:52 +0100

> can be hard to convince yourself that it works without a bit of mental

It has a 51 page draft, and it details only *non*-existence.

I am referring to NSEC3 non-existence proofs. Perhaps I missed something,
but messages like:
 
"In practice, then, we must show an NSEC3 record that encloses the hash of
 x.C, one that encloses the hash of *.C, and any RR owned by C (which could
 be an NSEC3, in which case it would be owned by the hash of C). A resolver
 verifying this proof would have to try longer and longer closest enclosers
 to determine which was being demonstrated as C, if an NSEC3 is presented.
 If any other RR was used, then C would be the owner. Once C has been
 determined, the resolver can easily check x.C and *.C against the proof."

http://www.ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00468.html

.. look rather like I need to solve for a system of constraints within my
software.

But perhaps this applied to a previous draft, of perhaps I am dense (most
likely). The mind boggles however at the failure modes implied by the
wording quoted above.

	Bert

---

From: David Blacka <[email-masked]>
Date: Mon, 04 Dec 2006 17:15:19 -0500

> It has a 51 page draft, and it details only *non*-existence.

I'm not sure that the length of the draft is totally correlative to the
complexity of the protocol.  It certainly took some words and examples
to cover all of the cases, however.

> .. look rather like I need to solve for a system of constraints within my

I don't think that text appears in the any version of the draft.

In any case, all it is actually saying is that you have to iteratively
hash a known, finite series of names in order to determine the closest
encloser.  The series of names is the qname, followed by all ancestors
of qname up to and including the zone apex (which you know).

> likely). The mind boggles however at the failure modes implied by the

The actual proof follows a fairly simple algorithm.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 5 Dec 2006 21:54:56 +0200 (EET)

> attention, even those which would have an immediate positive influence on

Agree.  There are a lot of (IMHO, more) pressing problems with DNS, 
such as writing an understandable basic specification (think of 'DNS 
implementation requirements') so that 98% of vendors don't get it 
wrong (or miss important features, e.g., the cache poisoning 
validaton) in one way or the other.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Edward Lewis <[email-masked]>
Date: Tue, 5 Dec 2006 15:08:00 -0500

At 21:54 +0200 12/5/06, Pekka Savola wrote:
>Agree.  There are a lot of (IMHO, more) pressing problems with DNS, such as
>writing an understandable basic specification (think of 'DNS implementation
>requirements') so that 98% of vendors don't get it wrong (or miss important
>features, e.g., the cache poisoning validaton) in one way or the other.

This is one of the many good ideas that has floated to the surface 
time and again over the years.  Every time this is thought about, we 
get caught in what is "right."  E.g., look at what happened when we 
tried to clarify just AXFR.  Clarifying wildcards took 4 years.  I'd 
rather waste my time designing DNS II than clarifying RFC 1034, et.al.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Ben Laurie <[email-masked]>
Date: Tue, 05 Dec 2006 22:06:52 +0000

> likely). The mind boggles however at the failure modes implied by the

I don't see why. All its saying, admittedly at great length, is that you
have to determine the closest encloser.

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

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

---

From: bert hubert <[email-masked]>
Date: Wed, 6 Dec 2006 00:17:24 +0100

> rather waste my time designing DNS II than clarifying RFC 1034, et.al.

Count me in!

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Dec 2006 10:35:13 +0200 (EET)

On Tue, 5 Dec 2006, Edward Lewis wrote:
> This is one of the many good ideas that has floated to the surface time and 
> again over the years.  Every time this is thought about, we get caught in 
> what is "right."  E.g., look at what happened when we tried to clarify just 
> AXFR.  Clarifying wildcards took 4 years.  I'd rather waste my time designing 
> DNS II than clarifying RFC 1034, et.al.

Yes, I know it's cooler to design new protocols than do maintenance on 
the old ones, and I didn't say this would be easy.  But if it's too 
difficult for us to get agreement on this, how do you think the 
implementors will be able to get it right?  For overly contentious 
topics, one may be able to omit normative specification, but include 
some discussion so that the implementor can make an informed decision. 
The key point is that I hope that at least 90-95% of DNS 
specifications are not contentious and if we are able to recognize 
which parts are which, we might be able to make reasonable progress in 
finite number of years :-)

I wonder what the implementation and interoperability status of the 
basic IP protocols would be without the Host Requirements and Router 
Requirements standards.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Dec 2006 08:54:06 -0500

At 10:35 +0200 12/6/06, Pekka Savola wrote:

>Yes, I know it's cooler to design new protocols than do maintenance on the
>old ones, and I didn't say this would be easy.  But if it's too difficult for
>us to get agreement on this, how do you think the implementors will be able
>to get it right?  For overly contentious topics, one may be able to omit
>normative specification, but include some discussion so that the implementor
>can make an informed decision. The key point is that I hope that at least
>90-95% of DNS specifications are not contentious and if we are able to
>recognize which parts are which, we might be able to make reasonable progress
>in finite number of years :-)
>
>I wonder what the implementation and interoperability status of the basic
>IP protocols would be without the Host Requirements and Router Requirements
>standards.

There are two reasons why I think it is futile to do a mass rewrite 
of the DNS protocol as it stands today.

One is that for the most part, it works.  Evidence of this is the 
huge investment made based upon the existence of the DNS.  The domain 
name industry is just the first order effect.  People fight over 
"ownership" of domain names - evidence that there is value in the 
name.  A lot of advertising money is spent to build value in a domain 
name.  (Even in the 90's, when a newspaper ran an add that was just 
it's WWW service name - a full page, multi-colored printing of the 
letters.)  What is there is solid enough for industry to make use of 
it.

The parts of the DNS that do not interoperate (well) are details that 
DNS nerds notice.  I wonder if this is just us trying to make work 
for us.  There are places where there are things to be fixed, but the 
marginal benefit in tackling these issues is worth the cost.  For 
example, when developing the wildcard clarify document, the WG 
haggled over what it means to have an NS RRset owned by a wildcard 
domain name.  In the end, we decided that it was a protocol barb that 
wasn't worth the effort to smooth out.

The second reason I think it is foolish to do a major overhaul of the 
DNS specification is that a lot of the new functions that are being 
demanded from DNS cannot be accommodated in the current architecture. 
I've recently blathered about "slapped on security" and problems I 
suspect are inherent in that.  There's a rising call for limited 
search capabilities, something DNS does not accommodate being a 
lookup service, that is a reasonable thing to desire but is not 
something I can see being fitted into the current protocol. 
Non-coherent DNS is another desire.  And it could be argued that IDN 
is something that DNS doesn't adequately accommodate.  (Another case 
where we have something that is beneficial but we could have done a 
lot better if the protocol was a little bit different.)

A new approach to DNS will happen when two things come together. 
When the marginal benefit is greater than the cost there will be 
motivation to replace DNS.  Part of that, but important enough to be 
mentioned separately, is that the new system has to be regulated in 
the same way that the DNS is regulated. I.e., the non-protocol 
investment in the DNS cannot be undermined.

What does this mean in the DNSEXT WG?  To me it makes me think the 
work here is pretty much over, just the mopping up of some issues. 
I'm not saying shutdown work like NSEC3, SO, and whatever else we 
have, but that I don't see this group taking on a major topic and 
seeing it come to a change.  I'm not against superwildcarding, I am 
not optimistic that it can be finished.  In the 11 years I've 
followed DNSEXT and its forerunners DNSIND and DNSSEC, we've only 
managed to get one document to Draft Standard, which I would think is 
far easier than slapping on yet another function.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Dec 2006 16:39:54 +0200 (EET)

On Wed, 6 Dec 2006, Edward Lewis wrote:
> One is that for the most part, it works.  [...]
> The parts of the DNS that do not interoperate (well) are details that DNS 
> nerds notice. [...]

We seem to have a different view of what's broken with DNS in the 
field.  I have seen for example:
  - load balancers and such dropping all queries except 'A'
  - DNS servers giving various sorts of bogus error codes in various
    kinds of conditions (e.g., RFC 4074)
  - Totally broken (in various ways) DNS resolvers out there (e.g., RFC
    3697)
  - various pieces of DNS infrastructure not supporting new RR types as
    well as we might like to
  - cache poisoning prevention still having no useful normative
    specification
  - EDNS0 not working very well, e.g., because some products choose
    to drop "too big" DNS packets.

Someone better versed with DNS specifications and their 
implementations could continue the list.

All of these have contributed to "dumbing down" the minimum, useful 
subset of DNS.  DNSSEC requires more than the minimum subset, which is 
likely one (minor) reason why it likely won't become popular outside 
fringe communities ("DNS nerds" you mentioned) any time soon.

> The second reason I think it is foolish to do a major overhaul of the DNS 
> specification is that a lot of the new functions that are being demanded from 
> DNS cannot be accommodated in the current architecture.

Is your point that revising the specs now isn't worth it because we 
can't wrap these new demands in the core DNS spec?  Otherwise I didn't 
quite understand.  Or did you mean that once the core spec is 
"opened", worms will sprout out and we'll end up with redesigning the 
DNS to accommodate new functions?  My intention very specifically was 
NOT to include any of these search, IDN, DNSSEC etc. capabilities in 
the updated "core DNS" specification.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Dec 2006 10:20:57 -0500

>  - Totally broken (in various ways) DNS resolvers out there (e.g., RFC

(Do you mean 3697?  Flow-label? I don't see DNS in there.)

>    to drop "too big" DNS packets.

I don't discount that this happens or is a pain.  But with the 
exception of the penultimate point, what part of that is the result 
of the protocol specifications being unclear or missing?  E.g., 
handling only A records seems like a choice, not a misbelief that 
they are the only records in use.

>Someone better versed with DNS specifications and their implementations could
>continue the list.

That seems to be self-contradictory.  Folks well-versed probably 
can't see what is unclear.

>All of these have contributed to "dumbing down" the minimum, useful subset
>of DNS.  DNSSEC requires more than the minimum subset, which is likely one
>(minor) reason why it likely won't become popular outside fringe communities
>("DNS nerds" you mentioned) any time soon.

What's wrong with something being "dumbed down?"  Perhaps it is a 
sign that the other clutter we've thrown in over the years is 
extraneous complexity.  The reason why the DNS was built is to 
provide a service to others, not be basis for on-going work.

>Is your point that revising the specs now isn't worth it because we can't wrap
>these new demands in the core DNS spec?  Otherwise I didn't quite understand.
>Or did you mean that once the core spec is "opened", worms will sprout out
>and we'll end up with redesigning the DNS to accommodate new functions?  My
>intention very specifically was NOT to include any of these search, IDN,
>DNSSEC etc. capabilities in the updated "core DNS" specification.

I think that to do some of the new things that are desired cannot be 
accommodated in the code now.  Part of that is architectural, part of 
that is design, part of that is compatibility with the existing base. 
Architectural - that DNS is a lookup, not a search.  Design - the 
CLASS field is after the label.  Compatibility - old code won't cope 
so we shoe horn unnaturally.

I also don't think we will get agreement on what is in the core now. 
I've kicked around the idea of just doing a profile - a document 
listing the other documents that define the protocol, and haven't 
been able to get any consensus on what is and is not essential.  Not 
every one likes AXFR, not everyone does CNAME.  If we were to 
describe what is absolutely necessary for interoperability only in 
DNS, we'd get a mudfight.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 6 Dec 2006 17:35:40 +0200 (EET)

I think I'll be quiet after this post...

> (Do you mean 3697?  Flow-label? I don't see DNS in there.)

Sorry, 4697.

> I don't discount that this happens or is a pain.  But with the exception of 
> the penultimate point, what part of that is the result of the protocol 
> specifications being unclear or missing?  E.g., handling only A records seems 
> like a choice, not a misbelief that they are the only records in use.

Almost all of these are due to an insufficiently clear specification, 
lack of identification of the "minimum subset of DNS" and to some 
degree insufficient motivation ("why is it important to do this?", see 
e.g. RFC1812 for examples)

> What's wrong with something being "dumbed down?"  Perhaps it is a sign that 
> the other clutter we've thrown in over the years is extraneous complexity. 
> The reason why the DNS was built is to provide a service to others, not be 
> basis for on-going work.

The problem is that most of the DNS community and some subset of the 
IETF seem to believe the DNS is offering much more than that.  If the 
specifications only included the "dumbed down" parts (provided that 
DNS could still work well enough with those, which I at least I 
disagree with), that'd be OK.

This may also be a reason for Keith Moore's rants about unreliability, 
slowness etc. of DNS for.., well, pretty much anything :-)

---

From: Edward Lewis <[email-masked]>
Date: Wed, 6 Dec 2006 11:19:38 -0500

>I think I'll be quiet after this post...

I am not trying to be antagonistic.  If someone wanted to digitally 
remaster the DNS specifications I would applaud the effort.  What I 
am writing are the reasons why I don't think any effort to do produce 
a remastered copy will run to a successful (having a new spec) 
completion.

Either we are going to find that there are funds to pay someone or 
some small group for the effort to do this or we are going to find a 
person (or group) who would rather pursue this at the cost of their 
own otherwise free time or this won't happen.  Such is the nature of 
volunteer efforts.

There is evidence of demand for this work.  But that hasn't 
translated into action.  If someone can drum up support to do this, 
great, I would not stand in the way.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Florian Weimer <[email-masked]>
Date: Wed, 06 Dec 2006 22:04:22 +0100

* Edward Lewis:

> There are two reasons why I think it is futile to do a mass rewrite of
> the DNS protocol as it stands today.

The main reason, IMHO, is that a potential successor (which has to be
decoupled from the current DNS to offset itself from its security
issues) would hardly inherent most of the legal privileges DNS enjoys.
Nobody except a TLD registry operator can get away with such
large-scale trademark violations.  This card blanche extends down the
registrar/reseller pipeline, and it's very hard to compete with *that*.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 17:20:52 -0500

Have these spoofing attacks been recorded somewhere that can be referenced,
e.g. US-CERT?  Can you say more about how those attacks could have been
mitigated without DNSSEC?  Have there been attacks that could only be
mitigated with DNSSEC?

Of course, a spoofing-phishing attack turns into a DoS attack if the host
discards the bogus DNS info but never gets the DNSSEC validated info.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 17:32:39 -0500

I think the root and the TLD is just one blocking factor.  Then, there's the
DNSSEC-aware recursive servers, the DNSSEC-aware host resolvers, signing all
those organization zones, and the fundamental "what's my ROI" question.

I have this vision of a jigsaw puzzle with about 6 or 8 pieces, that we have
to drop from a couple of feet off the ground and have all the pieces land in
place, interlocked, all at once to make DNSSEC fly...

The immediate RoI isn't directly like locking your door, because you don't
have the risk of anything being stolen *directly* from you if you don't
apply DNSSEC to your zones.  It's more indirect - somebody else trying to
access your website won't be robbed through a phishing attack if you put a
lock on your door.

- Ralph

On 12/4/06 5:45 AM, "Shane Kerr" <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFc/wuMsfZxBO4kbQRAknGAKCno1hfO/JrNoyhsk+9rkEx94BMRwCginCo
> VWL6Q40W+fGBrmwth3D67ds=
> =Gzje
> -----END PGP SIGNATURE-----

---

From: Ted Lemon <[email-masked]>
Date: Thu, 07 Dec 2006 15:43:53 -0700

> access your website won't be robbed through a phishing attack if you put a

It depends on how much your reputation is worth.   I was having dinner
with a guy the other day whose site had been hacked using a SQL
injection attack which resulted in customers' information being acquired
and misused.   He certainly didn't think that this was his customer's
problem - indeed, his e-commerce site has been offline for three months
now because they're so worried about the possibility of compromising
their customer info again.   DNSSEC doesn't solve this problem at all,
but the point is that companies who don't have a monopoly, which is most
companies, really do care whether their customers' transactions are safe.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 07 Dec 2006 18:23:31 -0500

Ted - I agree 100% that there are risks for loss of reputation, recovery
from customer losses due to fraud, etc.  Perhaps those assets are as
tangible as direct theft of cash...

- Ralph

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Dec 2006 12:45:27 -0800

> discards the bogus DNS info but never gets the DNSSEC validated info.

Actually, if you look at market motivation, there is a case to be made
for focusing on DOS attacks.

Suppose someone is trying to secure a transaction with
"www.example.com". In practice, they will use some form of end-to-end
security, TLS or SSL, as in "https://www.example.com". The end to end
security should provide a proof that they are communicating with the
real "www.example.com".

In these conditions, what is the point of securing the DNS look-up? The
end-to-end verification of the certificate will validate it.
Certificates allow for third party signature, and thus are somewhat
easier to deploy than a strict hierarchical scheme. The verification
will not implicitly validate the mapping of name to address. It will
also protect against routing attacks that might divert the traffic to a
bogus site, an attack not addressed by securing the DNS look-up.

End-to-end security mitigates a spoofing attack and reduces it to a
denial of service attack. If the name to address mapping was wrong, or
unavailable, or if the routing was bogus, the secure transaction will
simply not happen. The focus of DNS security should thus be a protection
against DOS attacks, i.e. ensure that if a record exists, it will be
found.

-- Christian Huitema

---

From: bert hubert <[email-masked]>
Date: Sun, 10 Dec 2006 22:01:18 +0100

> end-to-end verification of the certificate will validate it.

Exactly. This is also the reason why we don't have an "ARPSEC" protocol.

Or perhaps we do, but is about as exciting as DNSSEC. I wrote about this on
http://ds9a.nl/secure-dns.html .

	Bert

---

From: Jim Reid <[email-masked]>
Date: Sun, 10 Dec 2006 21:05:13 +0000

> issues) would hardly inherent most of the legal privileges DNS enjoys.

Perhaps. Though I'm not sure DNS has any legal privileges. DNSv2  
would surely be doomed by all the layer-9 goop it would attract.  
Governments, regulators, lawyers, industry groups and all sorts of  
non-technical organisations would have a feeding frenzy about who got  
to control the root, where the servers get placed, who gets runs them  
and how they are policed, etc, etc.

> registrar/reseller pipeline, and it's very hard to compete with  

I disagree with your premise but accept the conclusion. Registrars,  
resellers and the intellectual property folks would scream very  
loudly if there was a viable replacement to the current DNS.

BTW, TLD registry operators don't "get away with trademark  
violations". They're generally innocent third parties. Validating  
trademarks is hard and expensive. [I've just spent months looking at  
this issue with IPR professionals for a new TLD operator.] Even if an  
impostor registers a trade mark, there are a variety of methods for  
the true holder to gain control of the domain. This is now way off  
topic for this list, so no followups on UDRP and suchlike to  
namedroppers, please...

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Dec 2006 21:12:31 +0000

christian, your words echo some i heard recently from stuart cheshire:

> Suppose someone is trying to secure a transaction with "www.example.com".
> In practice, they will use some form of end-to-end security, TLS or SSL, as
> in "https://www.example.com".  The end to end security should provide a
> proof that they are communicating with the real "www.example.com".

there are at least two problems with this approach.  one is, tls/ssl is not
a lightweight device:  not all of us want to use tcp for all transactions,
and many of us want to be able to virtualize many domain names on a single
ip address.  the other is, ssl/tls depends in practice upon x.509, which is
outside of "the internet" for all practical terms.  the internet ought to be
able to do this kind of security for itself.

so, here's what i told stuart cheshire: if you believe that the web is all
there is to the internet, or you believe that the approach taken for securing
https/imaps/smtps is appropriate for all future applications/protocols used
on the internet, then it's natural that you would think ssl/tls/x509 is all
we need.  i do not think that the ssl/tls/x509 model is futureproof, and so
i think that we need something else, something more internet-like.

to understand what i mean, consider the number of e-mail transactions which
will be carried by smtp this year and this decade, compared to smtps.  the
insecurity does not lead to migration of mail toward the tls/ssl/x509 model;
rather, it leads to e-mail reputation systems, spam filtering, and phishing
attacks worth USD$100B/year.  as long as we're using domain names as unique
endpoint identifiers and as universal service locators, the world will suffer
from any lack of security in the dns infrastructure, and in the continuing
lack of confidence in end-to-end dns data.

the fact that x509 is an industry which funnels a large amount of money to
a small number of toplevel key repositories who are themselves chosen by web
browser vendors, means that there are financial scaling problems in the x509
model that are at least as compelling as the technological scaling problems.
with x509, "effective and usable security" can never become the default, it
will always be a premium service with a high cost of entry, used only when
other money is at stake (like when entering credit card numbers).  that isn't
the kind of internet or the kind of world we ought to be trying to make.

paul

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Dec 2006 21:15:49 +0000

> Perhaps. Though I'm not sure DNS has any legal privileges. DNSv2  would
> surely be doomed by all the layer-9 goop it would attract.

we know there won't be a new namespace.  ever.  but in addition to adding
new kinds of names (idn) and securing the data (dnssec) we have sometimes
tried to improve the protocol (edns).  if i were to embark on dnsv2 it would
be with the hope of completely forklift-upgrading the protocol while keeping
the namespace as it is.

---

From: bert hubert <[email-masked]>
Date: Sun, 10 Dec 2006 22:30:08 +0100

> i think that we need something else, something more internet-like.

I very much agree with this sentiment. But DNSSEC is not the answer as is
only sends out authenticated small and static messages.

It doesn't to whole transactions.

One cannot rely on DNSSEC for the whole shebang. In theory it could be the
conduit of a web of trust, perhaps that is what you mean? 

Which makes the vast amount of effort and brain cycles on it all the more
puzzling. In the vein of your statement regarding the 'king makers' in the
browser that annoint X.509 certificate vendors, perhaps there is something
along those lines happening within DNS?

I honestly don't know (it wouldn't seem likely), but it is unclear to me why
people continue to expend so much time on such a small part of a secure
internet.

	Bert

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Dec 2006 13:37:54 -0800

> christian, your words echo some i heard recently from stuart cheshire:

Well, Stuart and I often disagree, so you might consider that us
agreeing somehow shows something... 
 
> so, here's what i told stuart cheshire: if you believe that the web is
> all there is to the internet, or you believe that the approach taken
for
> securing https/imaps/smtps is appropriate for all future
applications/protocols
> used on the internet, then it's natural that you would think
ssl/tls/x509 is
> all we need.  i do not think that the ssl/tls/x509 model is
futureproof,
> and so i think that we need something else, something more
internet-like.

I am not so much looking at SSL than at end-to-end security. Name
resolution is one step in the end-to-end process of completing the
transaction. If you are really concerned about the security of the
application, you want to secure the entire process, not just one step.
You may use SSL, secure RTP, IPSEC, or maybe some application specific
solution. The point is, you will use something.

Now, consider the "market for DNS security". Logically, the early
adopters ought to be the most security conscious users. Yet, those
security conscious users are also most likely to deploy end-to-end
security for their application. They are thus not likely to invest in
yet another deployment, and to bear the management cost of yet another
system. They will only do this investment if securing the DNS brings
clear additional benefits, on top of what they already have.

What would be the characteristic of a DNS security system that
complements, rather than replace, end-to-end security? For me, the
obvious answer would be to ensure availability of the DNS service. The
secure DNS should guarantee that, if the relevant name servers are
available and reachable, the name resolution transaction will complete. 

The best "secure DNS" would be one that provides that guarantee at the
least possible deployment cost. 

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Dec 2006 23:04:53 +0000

> > there is to the internet, or you believe that the approach taken for
> > applications/protocols used on the internet, then it's natural that you
> > would think ssl/tls/x509 is all we need.  i do not think that the
> > ssl/tls/x509 model is futureproof, and so i think that we need something
> > else, something more internet-like.
> 

yes, but dnssec is also a web of trust in its own right, albeit not useful
for "whole transactions" in the sense of e-commerce or web or whatever.

> along those lines happening within DNS?

it's because dnssec makes only one king where there are three, that it is hard
for the world to make traction for it. that is, right now root zone management
is a groupthink process involving icann, us-doc, and verisign, but once there
is a root key, the holder of that key will be the one true king.  meatspace
does not admit the possibility anymore of one true king.

but you touched on something even more important.  x509 succeeded because it
was clear what was at stake and it was clear that investment could pay off.
pgp and dnssec, by not offering a specific and definite fiscal pyramid, don't
offer the kind of investment incentive that's usually nec'y for big things to
be built.  (if not for netscape's profit-motive, i think the web would have
been slower to take off, and if you doubt this, ask bill gates what he was
thinking back in 1996 on this topic.)  (if not for bbn's and later uunet's
profit motives, i think the internet would have been slower to take off, etc.)

> people continue to expend so much time on such a small part of a secure

because it's a very important part.  it's an enabling technology for just
about everything else we all want to do.  sadly, it's not the sexy part nor
is it investment-worthy in its own right.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Dec 2006 00:35:18 +0000

> Well, Stuart and I often disagree, so you might consider that us agreeing
> somehow shows something...

it does.

> I am not so much looking at SSL than at end-to-end security.

you're also willing to consider a design that creates security-haves and
security-have-nots, such that any application that cares at all about security
has to do it end-to-end.  if all an application wants is confidence in the
kind of information that's easy to store in dns, like SPF or A or PTR or PGP
or MX, and is otherwise not concerned about authorization or encryption, then
in your model they have to do some kind of end to end security thing which in
your model involves non-internet key exchanges (sneakernet, x509, whatever).

in my model, applications who don't care so much about security that they're
willing to pay an end-to-end complexity penalty (like ssl or tls), can still
get moderate confidence in the basic results of a dns query.  once this is
established, we're in a position to add more types of data to dns, which the
current confidence-free system does not really encourage.

> least possible deployment cost. 

so you're allowing for NS-only security.  others have proposed that, but it
was decided early on (by consensus among those willing to to volunteer to do
work in this area) that end-to-end application security was something we
wanted Secure DNS to be a building block for.  so the Secure DNS model is
end-to-end rather than interior-only.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 11 Dec 2006 10:37:57 +0900

Paul Vixie wrote:

> so the Secure DNS model is

It is not e2e.

With DNSSEC, zone administrators between you and your peer are
the intelligent intermediate entities subject to all the technical
and social hacking attacks.

E2e security can be enjoyed if and only if you and your peer directly
share secret information without intelligent intermediate entities.

DNSSEC does not provide cryptographic security.

PKI does not provide cryptographic security.

						Masataka Ohta

---

From: Ben Laurie <[email-masked]>
Date: Wed, 13 Dec 2006 14:43:35 +0000

Jim Reid wrote:
> surely be doomed by all the layer-9 goop it would attract. Governments,
> regulators, lawyers, industry groups and all sorts of non-technical
> organisations would have a feeding frenzy about who got to control the
> root, where the servers get placed, who gets runs them and how they are
> policed, etc, etc.

What root? ;-)

> resellers and the intellectual property folks would scream very loudly
> if there was a viable replacement to the current DNS.
> 
> BTW, TLD registry operators don't "get away with trademark violations".
> They're generally innocent third parties. Validating trademarks is hard
> and expensive. [I've just spent months looking at this issue with IPR
> professionals for a new TLD operator.] Even if an impostor registers a
> trade mark, there are a variety of methods for the true holder to gain
> control of the domain. This is now way off topic for this list, so no
> followups on UDRP and suchlike to namedroppers, please...
> 
> 
> --

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Dec 2006 17:37:27 -0500

>be with the hope of completely forklift-upgrading the protocol while keeping

I agree with that.  Where I see the discussion getting wrapped around 
an axle is when we cross the divide between conveying the data in the 
name space with regulating the data in the name space.  I've trotted 
this out before, there is a difference between talking about DNS and 
talking about provisioning of domain names.

It may be hard to see, but every DNS zone is managed by some sort of 
registry.  Whether it is a formal one like the g/sTLDs of ICANN or a 
ccTLD, or just a personal zone with three names in it, there is a 
registry.  The heart of the registry may be a distributed database or 
a text file, the process of generating the zone file may be a 
database difference report or the text file may already look like a 
zone file.

Coming up with a new wire protocol for DNS would represent about as 
much of a change as bring up servers on IPv6 to a registry.  DNS is 
just a publication mechanism, not what is regulated.  Perhaps a new 
protocol is more like the transition from LP's to CD's - the music 
stayed the same but the cases got smaller.  'Course the analogy 
breaks down when you get to MP3's and on-line stores, etc.  And 
DC-101 (local radio) had to change from "7 album sides at 7" to "7 
CD-sides at 7" declaring each half of a CD to be a side.

A cleaned up DNS would present an issue to the regulators - a better 
implementation of the CLASS concept.  But that's their problem, not 
ours. ;)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Edward Lewis <[email-masked]>
Date: Mon, 18 Dec 2006 09:56:46 -0500

At 21:23 +0000 12/16/06, Jay Daley wrote:

>I'm also increasingly of the view that DNS is /so good/ that most people
>simply don't realise it. And it is all those complex and weird little
>quirks that enable it to be so good.  What worries me about any attempt at
>DNSv2 is that some of the brilliance will be lost by trying to 'fix' DNS
>and DNS is just too important to work in any less good a way.

DNS stands on the shoulders of other naming systems, I am not 
surprised that DNS is a good protocol at heart.  I don't mean to 
disparage the effort by saying that DNS stands on other's shoulders, 
it means that it wasn't just a lucky bolt out of the clear blue sky.

I think that what is lost often is what makes the DNS a good 
protocol.  I work in an area in which DNS is a new beast, a 
non-Internet environment.  It is interesting to see what "them folks" 
think is the best part of DNS.  They aspects often cited are the 
quick response, the lightweight nature, the robustness.  They that I 
hear are less enthused about the scaling, etc.

DNS is not perfect though.  Some problems are in the architecture for 
example CNAME chasing in the authoritative server, the fixed message 
size assumptions (in data and header), and message compression.  In 
the sense of "you've optimized a design when you can't possibly strip 
away any more" these are things that probably would have been taken 
out if there was better hindsight back then.  Outside of CNAME, most 
of what I'd take out now were originally put in to handle problems of 
15 years ago - namely really constrained bandwidth.

There are other problems with DNS that are accidents of history, 
cruft thrown in because of implementation gaffs over time.  Mangling 
misunderstood types are an example of this, as well as some of the 
extra records that BIND threw in years ago that probably ought not to 
have been in responses (like the authority records in a 
CNAME-impacted response).

A DNSv2 would have to retain the lightweight nature, and make it even 
more lightweight.  It would also have to remove the limitations of 
small fields without adding more to the fields.  Finally, it would 
have to expand the notion of what's atomic from the RR to the RRset 
plus ancillary info.  But, please, abandon the hope of negotiating 
service parameters - that's heavy weight and adds round trips.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Dec 2006 16:26:44 +0000

> I think that what is lost often is what makes the DNS a good protocol.  ...

ask five people this question, get seven distinct nonoverlapping answers.

> ... But, please, abandon the hope of negotiating service parameters - ...

i can't think of a successful protocol that lacks an "options" escape-hatch?

---

From: Mike StJohns <[email-masked]>
Date: Mon, 18 Dec 2006 11:56:49 -0500

How about DNS?  Admittedly EDN0 was grafted on - but only to deal 
with changes and expansions to DNS.  DNS did fine without it for many 
many years.

With respect to negotiations in DNS - there are actually two 
protocols involved - the transmission protocol and the data 
protocol.  It's somewhat easier to add negotiation to the 
transmission protocol (and that's what EDNS0 did in part) because 
it's between just a client and a server during a specific 
conversation.  Adding negotiation to the data protocol is a bit 
harder (see for example grafting on the notion of non-existence and 
the various indications that have to go into the data to signal to a 
resolver/validator meanings). Its also the case that the publisher of 
the data doesn't have a clue as to the capabilities of its consumers 
and they will vary wildly.

So without a massive change to the data model (which may in turn lead 
to a massive change in the name space with all the political issues 
thereof - ??), I'm mostly with Ed here.  If you just want to re-write 
the query language and leave the data structures mostly intact - then 
lets just get the query language correct at the start. We've got 20 
years of experience with DNS that should allow us to write a tight 
protocol for the next 20 years.

Mike

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Dec 2006 17:16:31 +0000

> So without a massive change to the data model (which may in turn lead to a
> massive change in the name space with all the political issues thereof -
> ??), I'm mostly with Ed here.  If you just want to re-write the query
> language and leave the data structures mostly intact - then lets just get
> the query language correct at the start. We've got 20 years of experience
> with DNS that should allow us to write a tight protocol for the next 20
> years.

i'm not proposing that we make parts of the namespace optional, though IDN
does that implicitly and there will be similar insertions in the future (for
example, consider whitelies.)  so if being with ed means "better query
language" then i'd be with ed, too.  (i think you're misreading ed, fwiw.)
note that one insertion i'd want right off the bat is better wildcards, so
that one could have per-type wildcards, apex-inclusive DNAMEs, and probably
other stuff i can't remember at the moment.  these new wildcard forms would
only be visible to clients who understood them, so they'd be like DNSSEC or
IDN.

my two hot buttons with the current design are that it's middlebox-prone and
that it puts too much workload on the authority servers.  authority servers
should not have to do any kind of wildcard synthesis, and the ANY qtype is
just right out.  an authority server who has wildcard data that fits a query
should be able to just give out the wildcard data that covers the query, and
it ought to be normally cacheable.  and of course, security would be built in
from the get-go, both hop-by-hop (what we do with TSIG and SIG(0) today) and
end-to-end (what we do with RRSIG-et-al today).  there are no new clients
being made for whom this kind of processing is a burden.  a wristwatch made
in 2001 has more RAM than a VAX made in 1981.  let's shift the workload and
get authority-side processing out of the realm of supercomputing.

but this is all just talk, as long as the WG's to-do list remains endless
and as long as we're putting new (SO) lipstick on the DNSSEC pig every year.

---

From: Jay Daley <[email-masked]>
Date: Sat, 16 Dec 2006 21:23:23 +0000

[ 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. ]

> I think I'll be quiet after this post...

This is an important discussion and you have some interesting things to 
say.

> > I don't discount that this happens or is a pain.  But with the 
exception of 

> e.g. RFC1812 for examples)

DNS certainly has the problem that most people think it is simple to 
understand and don't realise there are some real complexities in the 
details.  This, in my view, explains the astonishing mistakes that many 
implementors make.

I think this is going to change as implementors get to grips with DNSSEC. 
The complexity of DNSSEC is such that they can't give their DNS work to 
the office junior who reads RFC1035 and then thinks that they understand 
DNS.  Hopefully the trigger of thinking about DNSSEC will force 
implementors to address all the bits of DNS they have not yet got around 
to understanding.

Jay Daley
Nominet UK