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

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 03 Jan 2002 22:52:26 -0500

In message <[email-masked]>, bert hubert writes:
>On Thu, Dec 27, 2001 at 10:14:46AM +0100, Olaf M. Kolkman wrote:
>
>> deployment limited to only the largest (g|c)TLDs. I understood
>> 'delegation only' was considdered for a new version of the draft.)
>> 
>> --Olaf
>> 
>> P.S. I love the idea to have DNSSEC in a workable state by summer.
>
>I seem to keep hammering this point - have clientside people been involved
>yet? The vast majority of DNS lookups right now are A queries, and most of
>those come from the browser.

Talk to the IPsec vendors -- general IPsec, beyond VPNs, isn't secure 
without DNSSEC.  I'm referring particularly to the opportunistic 
encryption folks, i.e., draft-richardson-ipsec-opportunistic-03.txt

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com

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: Tue, 08 Jan 2002 23:00:06 -0800

> The discussion concluded that the deployment of DS was critical, and worried
> that a decision not to adopt Opt-in could pose problems in deployment.  Thus
> we propose the following:
>  o DS and Opt-in proposals both be adopted and
>  o RFC 2535 backwards compatibility NOT be retained. (flag day!)
> ...
> This beings a two week last call on this proposal, to end 2002.01.01.

it has been over two weeks.  it is the view of the chairs that

  o there seems to be a very clear consensus for DS.  in fact, there were
    no negative technical comments.

  o there does not seem to be a consensus for Opt-In.  there was
    considerable discussion pro and con, with technical considerations
    in both directions.

if someone has NEW technical arguments to present for or against either
proposal, please do so now.  N_E_W arguments.

randy

---

From: [email-masked] (Ted Lindgreen)
Date: Thu, 10 Jan 2002 10:49:45 +0100

[Quoting Randy Bush, on Jan  9,  8:41, in "Re: DS and Opt-in -  ..."]

>     no negative technical comments.

Agree.

> proposal, please do so now.  N_E_W arguments.

N_E_W arguments, at least new technical arguments, are probably
difficult to produce, I think they have been beaten to death
and are pretty clear for most of us.

What has not been discussed enough, IMHO, is what we want to
accomplish with DNSSEC, and once we answer that question, the
technical arguments about Opt-In fall into place easily.

I'll try to take a shot at it. I see four paths to go forward:

1. Forget DNSSEC in its current shape.
2. Strive for full implementation, i.e. the goal is to get
   most of the DNS tree secured over time.
3. Go for course grain security, i.e. some or more large secureds
   branches side by side with large unsecured branches, and
   divided by clearly defined borders.
4. Go for fine grain security, i.e. some or more secured RRs within
   a further unsecured DNS-tree.

ad 1. This will happen when we do not go forward, it's the easy way :-)

ad 2. This is not realistic to expect to happen soon.

ad 3. Course grain security will lead to secured safehavens,
      garded by the major DNS forwarders/cachers. Some users
      may also check themselves, but many others will probably
      just trust their ISPs DNS forwarders/cachers. This way,
      it will be difficult for scriptkiddies to produce major
      spoofs in the safehavens, which is a major gain.

ad 4. Fine grain security makes it possible to have scattered
      secured RRs, this is more easily implementaed than 3, and
      it solves many problems for instance for the IPSEC people,
      and may open some interesting business opportunities.
      People who want these scattered secured RRs to be certified
      will check them themselves, others will probably want an
      answer (with possible outdated sig) more dearly than a
      certified answer, so chances are big that most major DNS
      forwarders/cachers will not bother checking the few
      scattered secured RRs.

Now, lets see how Opt-In fits in:
1. Does not matter.
2. Chances are slim we ever get here without Opt-In, chances
   are virtually zero we get here when we start with Opt-In.
3. Opt-In does not fit into this scheme.
4. Opt-In makes this possible, but there are probably more
   easy ways to accomplish the same (like an alternative PKI
   outside DNS, or DNSSEC without auth. denial).

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jan 2002 14:13:47 -0800

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

Arguments 1-4 are based on a false assumption that calls into
question the authros understanding of what OPT-IN does and
what a PKI is.

1.	OPT-IN does nothing to reduce the utility of DNSSEC.
	OPT-IN is OPTIONAL, it only adds one extra feature that
	allows deployment in large zones at acceptable cost.

2.	DNSSEC makes exactly as good or bad a PKI as DNSSEC + OPTIN

3.	What job? And you accuse me of handwaving ???

4.	Specify how, again handwaving.

> 5. There is serious doubt, that Opt-In is actually necessary
>    for even the largest TLDs to join the DNSSEC party.

And the criteria for 'necessary' would be defined by whom?

We have established that the cost of deployment is raised
by an order of magnitude. The demands for further proof can
only be made in bad faith. Providing a full answer to the 
question would require revealling 1) customer confidential
information, 2) proprietary trade secrets and 3) be obsolete
within a few months.

An order of magnitude is an order of magnitude. If a feature
optimises an expensive protocol by an order of magnitude a
reasonable group will accept it.

VeriSign would not have a Vice President, the Principal 
Scientist, and four research engineers arguing the case if
the costs in question were small change.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jan 2002 14:13:34 -0800

> I thought this was pretty clear, but apparently not,
> so I'll try to summarise.
> 
> The technical arguments against Opt-in boil down to:
> 
>    It changes the protocol in such a manner that it becomes
>    less, or even not at all, useful for the goal:
> 
>      "To make the DNS infrastructure less vulnerible"

This is untrue. Nobody has identified any security threat
that is controlled in 2535 that is not controlled with 
Opt-in.

The record insertion risk is not realised as a threat
because anyone can register names in the large domains.

Sercurity is risk control, not risk elimination, the cost
of implementation has to be justified in terms of improved
security. Nobody has demonstrated that Opt-in reduces the
ability to control threats. Nobody disputes that Opt-in
significantly reduces costs.

> The technical arguments in favor of Opt-In boil down to:
> 
>    It extends the protocol such that superlarge zones
>    can start implementing DNSSEC, while fully retaining
>    its usefulness for the goal:
> 
>      "To implementing PKI facilities into DNS"

That is not an issue. DNSSEC is not architected as a PKI
and OPT-in is not intended to support PKI type facilities.
The only connection between PKI and opt-in is that the
original concept grew out of discussions between well known
PKI experts and DNS experts.

While DNSSEC may be used for 'opportunistic encryption' for
end entity applications and is likely to become the key
distribution infrastructure that allows IPSEC to move beyond
VPS and justify its first initial, DNSSEC is not a PKI,
adding OPT-IN to DNSSEC does not make it any more or less 
of a PKI.

> My question, seeing these two different goals, was:
> 
>    What was the goal again?

Good question to ask since it appears that you are confused.

The purpose of Opt-in is to enable deployment of DNSSEC in
the large zones. It has no other purpose that is not part
of the overall purpose of DNSSEC.

> Another question that was raised and referred to by you:
> - Olaf asked why full RFC2535 would be a problem for large or
>   even superlarge zones. He referred to documented work (by
>   NLnet Labs) that showed that:
>   - signing zones with many tens of millions delegations is not
>     a big techical challenge with the current of-the-shelf
>     available hardware.

He may have asserted that, he did not demonstrate it.

Nobody is disputing the increase in the data volume, that is
the major killer.

The capabilities of 'commercial off the shelf' cryptographic
hardware are significantly reduced when you have to use 
FIPS-140/3 certified devices and manage the private keys
to a high standard.

>   - Dealing with ten times larger zonefiles appears not to be
>     a big techical challenge with the current of-the-shelf
>     available hardware.

If you believe that any production manager is going to accept
responsibility for deployment of a technology that has such 
a dramatic effect on a critical infrastructure it is unlikely
that any amount of reason is going to disabuse you of the 
notion.

The primary contractual obligation of VeriSign to ICANN is
to maintain the reliability of the DNS system. Deployment of
a security specification that unnecessarily compromises that
reliability just is not going to happen.

> What I read as answer were handwaving arguments, like the size of
> Verisigns computerroom. I also read a request from Jaap for hard
> numbers. In your current mail I again see you answering that
> with only a handwaving argument.

The hard numbers of significance here are 30 million domain names
and 85% of Internet users.

Nobody is disputing that OPT-IN significantly reduces the cost
of deploying DNSSEC. The only dispute is the degree to which
the cost is reduced.

We have by your own admission agreed that is is an order of 
magnitude. Case closed, discussion over.

> So, in conclusion, just two of the technical arguments:
> 
> 1. There is no consensus, that reducing the usefulness of
>    DNSSEC to just a PKI, is the right thing to do.

An entirely irrelevant argument since OPT-IN has nothing
to do with 'PKI'.

> 2. There is serious doubt, that Opt-In is really necessary
>    for even the largest TLDs to join the RFC2535 party.

This is disingenuous. What you really mean is that you want
to engineer a situation in which you can either force VeriSign
to spend a huge amount of money or accuse VeriSign of bad faith,
either because VeriSign does not deploy DNSSEC or because
VeriSign does not deploy a standard version of DNSSEC or
adopts some other security measure.

Such games may have weight inside this group. However they
will have very little weight in the IESG or the IETF at large
and absolutely none outside the IETF.

The consensus amongst the operators of large domains is that
OPT in is essential if DNSSEC is to be deployed.

The consensus amongst the group is that OPT-IN does no harm
to the objectives or the implementation of DNSSEC.

The only dispute is over the issue of whether the group should
adopt a change to the specification to accomodate the operators
of large domains.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 11 Jan 2002 14:28:05 -0800

Greg raises some important issues about PKI architectures.

The essential point is that whatever you do to DNSSEC it is
not going to make a good client interface to PKI, however it
may be part of the infrastructure that a PKI interface
accesses to deliver validated private keys to applications.

I have no dispute with the concept of using DNS and DNSSEC as
part of a trust infrastructure. I do dispute the notion that
welding DNSSEC calls into applications is a good plan.

There is a lot of PKI about, there are millions of certificates,
PGP keys and DNSSEC will hopefully add millions more keys which
are usefull for 'some' purpose.

What that purpose is is going to require local configuration 
at the site level. Here a site may be a division of an F500
company or a consumer with a lot of geeky gadgets that she is
not even aware do PKI very often.

That is the purpose of the XKMS specification which allows 
lightweight application clients to interogate a trust service
to obtain keys.

The idea that OPT-IN somehow turns DNSSEC into XKMs is not just
untrue, it is completely wierd.

		Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Greg Hudson [mailto:[email-masked]]
> Sent: Friday, January 11, 2002 10:10 AM
> To: Ted Lindgreen
> Cc: namedroppers
> Subject: RE: DS and Opt-in - a proposal
> 
> 
> On Fri, 2002-01-11 at 05:51, Ted Lindgreen wrote:
> I can't help but believe that people are confused about the
> ramifications of opt-in.
> 
> As I understand the situation, with straight rfc2535, if 
> Verisign wants
> to charge extra to sign people's KEY records, they can.  
> Verisign would
> be forced to sign everyone's NS records (or no one's), but 
> without a KEY
> record that doesn't provide very much additional protection.
> 
> So, lack of opt-in does not particularly damage the goal of protecting
> the DNS infrastructure at the .com level.  There is some danger that
> people in leaf zones will find it more convenient to use opt-in than
> sign their own zones, but I am not convinced this is a significant
> danger.
> 
> Even if your argument made sense, your wording would be going
> overboard.  Since opt-in is a domain holder's choice, it cannot make
> DNSSEC "less useful" for the stated goal, though it could conceivably
> make it "less likely to achieve" the goal.
> 
> The rest of my message is tangential; Ted made some other statements I
> disagree with, but they don't relate to my argument above.  
> As much as I
> think DNSSEC holds potential as a PKI, I do definitely 
> believe that "to
> protect the DNS infrastructure" is its primary goal.
> 
> >    2a. DNSSEC makes a lousy PKI, there is not even a
> >        key revocation mechanisme.
> 
> Quite the contrary.  Because DNSSEC is an online system, you can make
> signatures expire quickly, and people can easily fetch new signatures
> when expiry happens.  That's a big improvement over the web 
> browser PKI
> we live with today, where certificates have to last a long 
> time (on the
> order of months), and the revocation features are ignored.
> 
> >    2b. There are perhaps more appropriate infrastructures,
> >        for this, like LDAP, but also other.
> 
> LDAP is a protocol.  It is not, at the current time, a global
> infrastructure.  It may be more appropriate as a protocol, 
> but it simply
> isn't there to do the job in the important capacity.
> 
> (To be fair, DNSSEC isn't there as a global infrastructure either, but
> it's somewhat more likely to get there than LDAP is.)
> 
> >    2c. But if we misuse DNS anyway, Opt-In seems an overly
> >        complicated way, just allowing for no NXT records
> >        would be much simpler and with almost the same effect.
> 
> No, that would be completely inadequate.  DNSSEC with opt-in allows
> authenticated denial of signed records in an opt-in zone.  If 
> we simply
> allowed .com to have no NXT records, then anyone could spoof 
> a response
> to a .com query saying that amazon.com has no KEY record, even if it
> does have one.
> 
> 
>

---

From: [email-masked] (Ted Lindgreen)
Date: Sat, 12 Jan 2002 10:33:22 +0100

[Quoting Derek Atkins, on Jan 12,  7:48, in "Re: DS and Opt-in -  ..."]

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

Correct, that is because we don't heve a working DS implementation
yet.  The good news, however, is that it can easily be estimated
from work that has been done, as the effect of DS is roughly
equivalent to that of sig@child, which has been studied in detail.

The short answer is that with a parsely secured zone, and 2545 the
number of RRs more than double, with 2535+DS the number of RRs less
than double, and with 2535+DS+OptIn it hardly grows. With a fully
secured zone there is no difference.

The long answer is:

At NLnet Labs, we (in fact, Roy Arends and Miek Gieben) started in
early 2000 to gain life experience with 2535 on TLDs by really
signing actual .com, .de, and .nl zonefiles and playing real-life
registry (with written permission from these registries, by the way).

In very short: what was found, was that the expected problems with
machine power were much less to non-existing, and a real problem
was the adminstration and maintenance of (valid and signed) childs
KEY RRs in the parent zonefiles. We have concentrated on the last
problem, but both sig@child and later DS indeed have also a very
benificial effect on zonefile size and needed signing power, as
they obsolete the NULL-KEY.

For some estimates (for hard figures, please ask Roy Arends or
Miek Gieben):

Let's look at a delegation-only TLD (like .nl and .com).
Assume N delegations, and fraction X secured.
Further assume on average 2 RRs per delegation and 1 glue RR per
2 NS RRs.

When N is large, we can safely ignore the handfull of local RRs
(SOA, etc).

In the non-DNSSEC situation, we have about 3N RRs.

In RFC-2535 we must add a KEY or NULL-KEY plus an NXT and both
signed to each RR (Please note that neither NS nor glue get signed
at the paret).
This makes 7N RRs. So it more than doubles.

In RFC-2535+DS there are no KEYs, there are only DS RRs
for zones that continue to be secured (please note that
all zonenames themselves remain secured).
This makes (5 + 2X)N. With X=small this is 5N, i.e. less
than double, with X=100% it becomes again 7N.

RFC-2535+DS+OptIn, there are no NXTs for zones that are
not secured (please note that these names themselves are
not secured anymore because of OptIn).
This makes (3+4X)N. With X=small this is 3N, with X=100%
it becomes again 7N.

REMARK 1: the above estimate is not valid for other zones than
only- or mostly-delegation zones, there we find the often
mentioned "order of magnitude" growth.

REMARK 2: We (NLnet Labs) still think that the machine power needed
to do either nothing, RFC 2535, RFC-2535+DS, or RFC-2535+DS+OptIn
actually matters. The real problem is the administrative burden
needed for secure childs at the registry, which is independend
of Opt-In (but strongly influenced by DS).

Regards,
-- ted

---

From: Derek Atkins <[email-masked]>
Date: 12 Jan 2002 13:26:47 -0500

Roy Arends <[email-masked]> writes:

> Lets put in another small variable called Q in your formulae. Q stands for
> the size of the SIG record (against size of NS, A or NXT) multiplied by
> the amount of signatures per RRset. Lets assume the size of NS,A and NXT
> is 1.
> 
> In the example below, Q stands for three SIGs plus a size of 10 per sig
> (which result in 30).

I still don't understand where this 30 is coming from?  Do you mean
you are assuming three SIG records at factor-10 size?  Well, geeze,
if you assume a factor of ten, surprise, you get a factor of ten.

I'd rather work with _REAL_ numbers.  There are Z zones currently in
.COM and the zone-file is B bytes in core.  Assume SIG records are of
size S.  Also assume that NXT records are of size N and DS records are
of size D.  This implies that we've got a total size of:

        B + Z*(N+S) + Z*X*(D+S)
        B + Z*(N+(1+X)*S+X*D)

Now assume a 1024-bit RSA key as the signatory.  Therefore SIG records
are approximately 142 bytes each (128 bytes for the signature itself
and 14 bytes for the rest of the sig header).  This implies we're
adding approximately Z*(1+X)*142 bytes due to signatures.  So the
question is, what is Z, and what is B?

> btw, last year at NLnet Labs, signing a .com zone increased the bare
> zonefile with factor 4 (ascii file, not the file in core). Signed by a
> single 768 bit DSA key. This took about 71 hours including sorting,
> without certified crypto-hardware or software.

This isn't too surprising.  Signature creation with DSA is a lot worse
than signature creating with RSA.  So, I would expect that RSA
signature would take significantly less time on equivalent hardware
(probably a factor of two).

-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: Roy Arends <[email-masked]>
Date: Sat, 12 Jan 2002 20:37:46 +0100 (CET)

On Sat, 12 Jan 2002, Ted Lindgreen wrote:

> [Quoting Roy Arends, on Jan 12, 14:55, in "Re: DS and Opt-in -  ..."]
>
> > While the number of RR are trippled when comparing 2535 with opt-in, and
> > doubled comparing DS with opt-in ....
>
> You forget the glue, which makes the difference again a little less
> pronounced, but anyway, we seem to agree that we are talking about
> a factor of 2 and not an order of magnitude.

Factor of 2 in numbers, which result in an order of magnitude in
size.

                              X=0    X=.5     X=1
                              Q=30   Q=30     Q=30

No DNSSEC      3N              3N     3N       3N
DS             (4+X+Q(1+X))N  34N    49.5N    65N
OptIn+DS       (3+2X+Q(2X))N   3N    34N      65N

WHOA, factor 10, order of magnitude.... anyway, I was on the low side by
estimating that a SIG record is about 10 times larger then an A or NS
record.

Most importantly, optin sets the growth scale more dynamically (from
Q(1+X)N to 2XQN ) which allows for an initial offset of 0.

> > 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.
>
> Of course, but the size of RRs is a whole other problem.  To cope
> with that we have already consensus, that we need the larger EDNS0
> packets as prerequisite for DNSSEC, but still if many decide to
> use multiple and/or larger KEYs or SIGs than EDNS0 can hold, large
> scale fallback from UDP to TCP will happen with a possibly devastating
> effect on the performance of the DNS infrastructure. But, again,
> this is another problem, which even OptIn cannot solve.

Nice, but no, size of SIG _is_ relevant here. With OptIn there are simply
less signatures when X has not reached 1. That is why the Q factor above
is so influential.

   http://www.nlnetlabs.nl/dnssec/sign.com.html

Roy Arends
Nominum

---

From: Derek Atkins <[email-masked]>
Date: 12 Jan 2002 14:46:18 -0500

Roy Arends <[email-masked]> writes:

> Generating RSA signatures is slower then DSA signatures....

I'm sorry, you are correct.  Generating an RSA signature takes about
twice as long as generating a DSA signature.  HOWEVER, verifying a DSA
signature takes ten times as long as verifying an RSA signature.

Considering most of the DNSSec operation would be verification, you
wind up performing twice as much work up front to save an order of
magnitude of work for the verifier.

To give some concrete numbers, courtesey Eric Rescorla:

=> Here are some approximate timings for the various operations
=>  (measured on a Celeron 300). All moduli are 1024-bit.
=> 
=>  RSA private key op      30 ms  (e.g. signature create)
=>  RSA public key op        2 ms  (e.g. signature verification)
=>  DSA signature           17 ms
=>  DSA verify              21 ms

-derek

---

From: [email-masked] (Ted Lindgreen)
Date: Sat, 12 Jan 2002 23:20:25 +0100

[Quoting Derek Atkins, on Jan 12, 22:07, in "Re: DS and Opt-in -  ..."]

> > RFC drafts talking about more than one KEY and/or SIG to allow for
> > key rollovers, but I'm not sure why Roy thinks that 3 KEY/SIG sets
> > for all RRsets in a TLD will be the future norm. Roy, perhaps you
> > can enlighten us?
> 
> I don't understand this, either.  Sure, you need a second key (which
> doubles the number of signatures) during key rollover, but I don't
> expect anyone to keep multiple key/sigs around at all times.

As Roy already explained, this is for procedure schemes to do key
roll-overs,  as worked out at several places. These schemes tried
to solve the 3-generation problem of vanilla 2535 (a zone needs
its parent to sign its new KEY and at the same time its children
to include the SIGs from the new KEY in their zonefile).
This was extremely complicated to do in a secure manner and without
disrupting service when scheduled, and virtually impossible when
unscheduled (as an emergency key rollover after a key compromise).

That's why DS has been introduced, and with DS these complicated
procedures are greatly simplified. With DS one needs either a
temporary double zone-KEY (useful for large zones, like TLDs) or a
temporary double set of RRs (useful for most other zones), but not
both, to do a scheduled rollover. An unscheduled rollover needs
no double KEY or SIGs (in fact you don't want the compromised old
stuff anymore), but some out-of-band mechanisme is needed instead.

-- ted

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 12 Jan 2002 19:01:33 -0800

Just an additional point of information here, the secure
signing hardware used for commercial grade crypto tends to
have processors that are slower than Celeron 300s. In fact
the popular chip of the moment is the ARM.

Don't ask me what happens to all these PR we see for
mega-fast crypto chips with modular exponentiation H/W.
For some reason it does not seem to wind up at the companies
who have trustworthy manufacturing facilities that can pass
a decent audit and end up in FIPS 140/3 certified gear.

Derek's original point was actually not far off when you
do the whole signature creation process which includes
test verification. 

> From: Derek Atkins [mailto:[email-masked]]
> Sent: Saturday, January 12, 2002 2:46 PM
> To: Roy Arends
> Cc: [email-masked]; namedroppers
> Subject: Re: DS and Opt-in - a proposal
> 
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 14 Jan 2002 08:31:01 -0800

Dereck writes
> "Hallam-Baker, Phillip" <[email-masked]> writes:
> 
> > OK so we are talking about 2.02*S rather than 0.02*S ??
> > 
> > So I was wrong! The difference between opt-in and not is
> > TWO orders of magnitude...
> 
> What are you smoking, Phill?  Whatever it is, can you get me some?
> 
> How does a multiplier of 2 result in two orders of magnitude?  Also,
> as has been said, with DS you don't get the 2.02*S, because you never
> need to have two complete sets of signatures. 

2.02 * S / 0.02 * S = 101

The point is the baseline you choose. So far we have been suckered 
into the bogus argument that the difficulty of running DNS is an
acceptable baseline, it is not.

The proper way to measure the difference in cost is:

Additional cost of 2535 deployment / Additional cost of OPT IN

> Is a factor of 4-6 really overwhelming?

If you are the one who has to write the cheque, yes.

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 14 Jan 2002 08:27:02 -0800

> And if everyone in the universe gets this choice, we wont be any
> better than we are now, because nobody is willing to go to the
> extra effort to add security if they don't have to.
> 
> When it comes to scurity, choices are a Bad Idea (TM).  The more
> choices you have, the more possibility you have to shoot yourself
> in the foot.

Derek,

	I am surprised that you make the mistake of confusing the number
of options with the complexity of the solution. Options are one way
of introducing unnecessary complexity, but they are not the only way.

	The issue is how the debate is framed. if the benchmark for
comparison is the existing complexity of DNS then 2535 increases
data volume by a factor of six or ten depending on the assumptions
made.

	If however the comparison is made to the ADDITIONAL cost of 
deploying DNSSEC the picture looks entirely different. The first DNSSEC
secured zone in dotcom requires a sixfold increase in the support 
infrastructure. That is a vast and unacceptable increase in the
complexity of managing the TLD.

	Lack of choices is a far worse option when they prevent the
deployment of the protocol or force the operators of the large TLDs
to deploy a non-standard protocol.

	The proper terms in which to frame the debate is which solution
is better, 2535 or 2535+OPT IN? The group has accepted a change that
is not backwards compatible. The argument that OPT-IN will cause
delay is now vaccated.

	The only argument being advanced in favor of 2535 is that it
is the status quo. People in the group should wake up and realise
that the status quo is non-deployment. The general opinion of the
DNSSEC spec outside the group is that the group has been dragging
its feet for too long and that the failure to deploy reflects on the
quality of the spec.

	The rush to corronate 2535 as a standard while deployment
remains at the experimental stage is not going to be very credible.
Advancing a backwards incompatible change (DS) while refusing
to admit OPT-IN is going to appear incredible. 

		Phill

---

From: "Loomis, Rip" <[email-masked]>
Date: Mon, 14 Jan 2002 13:45:20 -0500

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: Monday, 14 January, 2002 11:31

> If you are the one who has to write the cheque, yes.

It is increasingly clear (to me at any rate) that 2535 is
less and less likely to see widescale deployment without DS.
Therefore it would appear that the proper way to measure
the "difficulty factor" of signing .com without Opt-in is:
   Additional cost of (2535+DS) / Additional cost of (2535+DS+Opt-In)

(Note that I believe the real-world time to implement 2535+DS
in DNS software is essentially equivalent to the real-world
time to implement 2535+DS+Opt-In.)

I believe that the difficulty factor above is *not* two orders
of magnitude.

NEXT:  On to my overly-long set of statements/comments, now that
I've opened my mouth.

Some of the discussions that have come up would appear to
be strongly into the political and philosophic.  I'm more
of a libertarian and would prefer that DNS allow, "an
it harm none, do what ye will".  However, I would state that:
 - DNSSEC will cause much discombobulation, pain, and agony
   no matter which implementation is done at this point.
   DNSSEC is believed to be worth the pain and agony *not*
   because we're trying to protect a few specific nodes that
   have "higher" value--DNSSEC is needed to address basic
   weaknesses in the current protocol that have been exploited
   in the past.  We're not just trying to do for DNS what
   SSL server certificates have done for HTTP. [0]
 - If Opt-in is allowed to be used at *all* levels of the
   DNS hierarchy, then the basic protocol issues will never
   be fully addressed.  (I still occasionally wonder if
   DNS v2.0 is the right answer...)  If Opt-in is allowed
   only on *specific* zones, it is not clear what reasonable
   set of restrictions can be used to limit it only to those
   zones that "really" need it.
 - Even if it is made clear that Opt-In is only allowable
   for zones that meet all three of these (notional) criteria:
     1.  Must be a gTLD or ccTLD
     2.  Must consist largely (>95%) of delegations
     3.  Must contain at least 10000 distinct and unique
         nodes
   then I still believe that Opt-In creates a scenario that
   causes more confusion to both users and administrators
   of the exact "is it secured?" status for each zone/node.
   That confusion will severely hamper the acceptance and
   usage of DNSSEC.

I'm not part of The Security Mafia, but I'm here on behalf of
a different security mafia with a decent-sized DNS hierarchy.
If the only way that we can get .com to be signed is to accept
Opt-In, then I believe that DNSSEC will never move very far
beyond the "small pockets of signed zones" model.  That is not,
and has never been to my knowledge, the stated end goal of
DNSSEC--and *that* is why I still can't back Opt-In.

OTOH, if we can't get $LARGE_GTLD signed, we're also stuck in the
"small pockets of signed zones" model for much of the net.
I don't like that answer either, and it's become clear that
VeriSign/NSI strongly believes that this is a point worth
fighting.  ICANN is unlikely to give instructions that require
signing of .com using 2535+DS, and VeriSign would not appear
interested in signing .com without Opt-In. [1] 

Can anyone of the well-qualified folks who bothered to read this
far give a non-biased flame-free summary of the 5 most critical
plusses/minuses of the current Opt-In proposal, to summarize
the last 50 messages on the subject?  I believe that we may
in fact need to ask for guidance from on high, and I don't believe
that we yet have such a summary of the status.

Very Respectfully,
--
Rip Loomis
Senior Systems Security Engineer
SAIC Center for Information Security Technology [2]

[0] If DNSSEC had been fully fielded prior to HTTP, then SSL
    certificates would still have been worthwhile to provide
    for session privacy--but *some* of the sites that use HTTPS
    for essentially all transactions right now are doing it
    because DNSSEC is still not fielded.

[1] If the necessary infrastructure improvements would be in the
    back-end database portion that gets billed equally to all
    registrars (and passed on by them to their customers), then
    it seems that the additional cost would not bankrupt VeriSign.
    Perhaps I just don't understand the business model well
    enough (which is likely).  But...what *really* gets me torqued is
    that VeriSign has known for *years* that DNSSEC would likely
    happen one day, and that it *would* require additional
    resources.  Do the additional resource requirements now come
    as a complete surprise?

[2] Note that as an SAIC employee-owner, I have some financial
    interest in VeriSign/NetSol.  I *still* want .com signed sooner
    rather than later, preferably the whole stinkin' thing.