Subject: RE: DS and Opt-in - a proposal

From: [email-masked] (Ted Lindgreen)
Date: Fri, 11 Jan 2002 12:35:57 +0100

Sorry, send it of to quickly, let me refrase the conclusion.

[Quoting Ted Lindgreen, on Jan 11, 11:51, in "RE: DS and Opt-in -  ..."]
> [Quoting "Hallam-Baker, Phillip", on Jan 11,  3:03, in "RE: DS and Opt-in -  ..."]
> 
> > I have yet to see a technical argument of any kind against Opt-in.
>
> <Some intro-bla>

In conclusion, just five of the technical arguments I remember
that have been raised:

1. There is no consensus, that reducing the usefullness of DNSSEC
   and ignore DNS's current vulneribilty, is the right thing to do.
2. DNSSEC+OptIn makes only a lousy PKI.
3. DNS is the wrong tool for the job.
4. DNSSEC+OptIn is a very complicated way to achieve something
   that can also be achieved in much simpler ways.
5. There is serious doubt, that Opt-In is actually necessary
   for even the largest TLDs to join the DNSSEC party.
 
Regards,
-- ted

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 Jan 2002 04:25:23 -0800

>    for even the largest TLDs to join the DNSSEC party.

for me personally, i.e. chair hat far off, this is the big missing
piece of the puzzle to me.  given it would seem to be the main
motivation for opt-in, that it is not described and quantified may
be why folk are not jumping on the bandwagon.

randy

---

From: Roy Arends <[email-masked]>
Date: Fri, 11 Jan 2002 16:42:44 +0100 (CET)

>    and ignore DNS's current vulneribilty, is the right thing to do.

That is FUD, not a technical arguement.

> 2. DNSSEC+OptIn makes only a lousy PKI.

DNSSEC - OptIn makes a lousy PKI. OptIn is the redundant word here.

> 3. DNS is the wrong tool for the job.

Tool ? For what job ? Is this still about the PKI stuff ?

>    that can also be achieved in much simpler ways.

Very very very vague.

>    for even the largest TLDs to join the DNSSEC party.

Ah, finally, we have an arguement here. Your questioning the motivation
for opt-in, not really a technical arguement for or against opt-in.

No-one in their right mind will dispute that a opt-in com zone is
significantly smaller then an 2535 com zone. Significantly smaller in the
sense that from rollout, the opt-in com zone is practically the same size
as the plain com/net/org zone. It (opt-in) allows the zone to grow in
scalable, manageble ways.

There is serious effort been put into stopping opt-in from happening. Some
tried to get the FUD out, but it keeps entering the picture, even to the
rediculous first 4 points above.

To me it is worrying that a WG-Chair bases "no-consensus" on the mere fact
that a few people question the motives behind opt-in (while they are
very clear) rather then stating technical arguements against opt-in.

Now, I don't work for Verisign, so I don't have, nor am interested in such
numbers, but they can probably be produced.

Roy Arends

---

From: Paul Vixie <[email-masked]>
Date: Fri, 11 Jan 2002 08:09:06 -0800

> be why folk are not jumping on the bandwagon.

i stepped into the bandwagon once i realized that DS had to happen in
a non-backward-compatible way.  opt-in is actually the cleaner and
more elegant way to do dnssec, but i would not have supported putting
it in unless i'd already swallowed the DS poison.  i won't argue from
"necessity" since i consider even COM to be servable without opt-in.
(and i don't think COM's publisher could prove otherwise, so there!)

---

From: Mark Kosters <[email-masked]>
Date: Fri, 11 Jan 2002 11:58:04 -0500

>    that can also be achieved in much simpler ways.

Please present the better way. I personally think opt-in is a pretty
simple way to incrementally adopt dnssec in large zones. It grows as demand
(people who have signed their zones) warrants.

>    for even the largest TLDs to join the DNSSEC party.

The main issue is serving up the zones. With DNSSEC, memory footprint and 
zone file contents jump an order of magnitude. So, if we support 2535
this puts us uncomfortably close to the edge of what is available now and the 
near future for boxes stuffed with large amounts of memory. Based on
past growth rates, we would outpace Moores law. Also propagation in a timely 
manner is a problem in sites that are far-flung. *

Of course, one can engineer around these things by partitioning, internal
query routing, etc. But, as one of the providers of critical infrastructure,
we like to keep the zone serving issue as simple as possible (Murphy's law
applies here). Opt-in allows us to do that and we like to serve it up as soon 
as possible.

The primary purpose Opt-in solves is the problem of redundant crypto 
(signing unsecured delegations that is overridden by the child).  
Notwithstanding the Moore's Law issue, if we keep 2535 type of info
in the parent zones, this gets to be a large overhead for very
marginal benefit. Especially when it is unclear how many delegations desire
to be actually secured, this gets to be a very expensive endeavour. I don't
see those rationale behind those who think that 100% of the dns tree needs
to be secured and feel compelled to force them to be that way. I see that very
few (but important) domains will actually serve up dnssec zones. And this
will go up slowly over a long period of time given demand from customers has
not yet really started given the api needs to be fleshed out more so the 
clients can see that the answer was performed over a secure resolution path.

Since we are doing this non-backwards compatible thing with DS (which I 
understand is much more expensive on the resolver than opt-in), why not add 
in opt-in too? It does not hurt the security model and it helps us and every
other large zone maintainer get this out the door.

Regards,
Mark

* We had a similar thing a number of years ago on the routing side dealing
with the advertisement explosion that resulted in rfc 2050 that helped
deal with memory footprint and convergence.

-- 

Mark Kosters             [email-masked]       Verisign Applied Research

---

From: Derek Atkins <[email-masked]>
Date: 11 Jan 2002 09:52:19 -0500

in Salt-Lake, in the after-dnsext DNSSec meeting, I specifically
asked the Verisign group (I'm sorry, I don't remember who you
were specifically) to get me a few numbers:
        size of .COM zone
        size of .COM zone with 2535
        size of .COM zone with DS
        size of .COM zone with Opt-In
        size of .COM zone with DS+Opt-In

I believe that we were assuming a 1% "interest" in DNSSec (1% of the
children supply keys).  It's now mid-January and I haven't heard back
from Verisign.  Until I do, my personal belief is that Opt-In is
"assertion-ware" and should be ignored.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Derek Atkins <[email-masked]>
Date: 11 Jan 2002 17:24:07 -0500

> scalable, manageble ways.

Why doesn't DS alone provide for this?  If a child is not secured,
then the parent would have no DS/SIG{DS} records.  As more children
request secured delegations, their DS/SIG{DS} records get added to
the parent.

> numbers, but they can probably be produced.

One would think so, but they haven't been.  From where I sit, looking
at the prospects of DS, the only place that Opt-In would appear to be
useful is in the tld zones.  Considering the few number of tlds, I'd
like to see proof that Opt-In is necessary.

By proof I don't want just a comparrison to 2535 -- the WG has already
agreed that DS is the way to go.  I'd like to see a comparrison of
Opt-In against 2535+DS!  Nobody has yet done that.  I believe that DS
is sufficient to solve the scaling problems, and still provides the
secure delegation to non-secure zones (and secured non-existance of
all zones).

-derek

---

From: bert hubert <[email-masked]>
Date: Sat, 12 Jan 2002 00:18:49 +0100

> for opt-in, not really a technical arguement for or against opt-in.

Mounting my hobby horse again, this is actually a good thing. It creates a
business pull for dnssec implementation, which complements our technology
push.

Yes, a fully signed zone with secure denial of non-secured delegated zones
is technically a good thing. However, it requires a big investment that does
not scale well with the amount of secured delegations - there is a huge
up-front cost.

This does not make business sense. Businesses like to see costs that rise
with increasing customer base, where those costs rise with a lower exponent
than the income generated - at which point it is beneficial for them to
grow. 

Opt-in makes this possible. For an initially modest investment, a new
service can be launched: the secure delegation.

>From Ted's standpoint, I understand where he is coming from. Opt-in does not
generate benefits for everybody. It is technically far inferiour to 2535.

Sadly you could call this the VHS effect. Inferior technology that makes
better business sense always wins out over superior technology that
represents a shoddy business case. 2535 is betamax.

> numbers, but they can probably be produced.

Everybody should feel interested. A registry that implements opt-in enables
its registrars to sensibly offer secure delegations, which will generate an
implementation pull, leading to a safer internet.

DNSSEC will *not* happen because it makes geeks' hearts flutter, including
mine. Even though I used to have Betamax.

Regards,

bert hubert

-- 
http://www.PowerDNS.com          Versatile DNS Software & Services
http://www.tk                              the dot in .tk
Netherlabs BV / Rent-a-Nerd.nl           - Nerd Available -
Linux Advanced Routing & Traffic Control: http://ds9a.nl/lartc

---

From: Roy Arends <[email-masked]>
Date: Sat, 12 Jan 2002 11:32:18 +0100 (CET)

> request secured delegations, their DS/SIG{DS} records get added to

Lets look at both.

First a delegation with 2535+DS.

In 2535+DS the extra statement is (marked by -> )

     a.com. NXT b.com. NS DS SIG NXT
     a.com. SIG (NXT)
     b.com. NS somewhere
 ->  b.com. NXT d.com. NS SIG NXT
 ->  b.com. SIG (NXT)
     d.com. NS somehwere....

opt-in proposes to do it:

 ->  a.com. NXT d.com. NS DS SIG
     a.com. SIG (NXT)
     b.com. NS somewhere
     d.com. NS somewhere....

(note the absence of the NXT bit in a.com NXT which states opt-in).

DS obsoletes no-key and the accompanying SIG, but still has the NXT plus
SIG(NXT) for every unsecured delegation.

> secure delegation to non-secure zones (and secured non-existance of

Take 1000 domains, average of 2 NS records per delegation. One percent is
secure. Lets leave the apex out for a sec.

1035:  2000 NS records

2535:  2000 NS
       1000 KEY
       1000 NXT
       2000 SIG
       ------------
       6000 RRs

DS:    2000 NS
         10 DS
       1000 NXT
       1010 SIG
       -------------
       4020 RRs

opt-in:2000 NS
         10 DS
         10 NXT
         20 SIG
       -------------
       2040 RRs

While the number of RR are trippled when comparing 2535 with opt-in, and
doubled comparing DS with opt-in, these are only numbers of RR, not
calculated is the size of the RR. It is fair to say that the size of a SIG
is by far larger then the others.

Also, this assumes only one signature per signed RRset.

Roy Arends
Nominum