Subject: DNSEXT WGLC: To OPT_IN or not to OPT-IN

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 12 Mar 2003 23:01:05 -0500

This starts a two week working group last call,
concluding on March 28'th 2003.

Q: Is there consensus by the WG, to allow Opt-in zones?

The document to base this discussion on is
     http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt

Please send explicit statements of support or disagreement.

Note this is not a last call on the technical issues in the document,
if any such issues exist they should be assumed to be fixable and not
affect the judgment on the question above.

The document is on the standards track. If this document is advanced by
the working group, it will be integrated into the DNSSECbis documents.

Silence during this working group last call will be taken as support
for opt-in based on comments made during the technical last call on
OPT-IN.

	Olafur

--
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: Daniel Massey <[email-masked]>
Date: Thu, 13 Mar 2003 12:18:04 -0500

On Thursday, March 13, 2003, at 10:47  AM, Scott Rose wrote:

> As per Olaf's comment - I support the draft with the last round of 
> comments.
> And wish there was a good way of recommending OPT-IN for "huge zones" 
> only.
> However, I know what makes a zone "huge" would be a rathole debate.
>
> Scott
>

same as above.  support for the draft with the last round of comments.

Dan

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 10:56:58 -0800

Sigh.  I've said I don't care what decision is made as long as a 
decision is made and I still feel that way, however this is a bit over 
the top.

So, let me get this straight:

On Thursday, March 13, 2003, at 06:09  AM, Olaf Kolkman wrote:
> Although I would advise against its use in all other cases but the huge
> zones out there, I do support the draft.

> same as above.  support for the draft with the last round of comments.

You all appear to be arguing that we should yet again modify DNSSEC, 
increasing complexity and changing the security model, to include 
functionality to address a temporary transition issue that only a 
handful of folks will ever need and that many who have looked at the 
problem believe is solvable in other arguably better ways?

If you want to support pushing opt-in forward, I believe it should be 
done so with the belief that it is necessary, generally useful, and 
improves the protocol, not a hack for a small set of outliers or "well, 
it doesn't look like it will do any harm".

Rgds,
-drc

---

From: David Blacka <[email-masked]>, (by way of David Blacka <[email-masked]>)
Date: Thu, 13 Mar 2003 13:52:40 -0500

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

On Wednesday 12 March 2003 11:01 pm, Ólafur Gudmundsson/DNSEXT co-chair 
> Please send explicit statements of support or disagreement.

I support Opt-In.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 21:31:12 +0000

> There is at least one recursive implementation of opt-in that has been
> completed.  And we have had some experience that it interoperates
> correctly with at least two authoritative opt-in servers. So with this
> knowledge of actual running code, perhaps we should ask ISC and/or
> Nominum to comment on how much more "complex" it is to add opt-in
> support.
> 
> Mark

the complexity arguments are a tempest in a teapot, as silly as verisign's
whining about memory footprints and bandwidth requirements.  any argument
based on either basis is just pure FUD.

this is a tradeoff between complexity and autonomy.  the complexity part
has been shown to be manageable; opt-in validators exist and have been
tested by people other than their authors.

let's move on.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 17:44:59 -0800 (PST)

Mark writes, quoting Paul Vixie:
> Is this a reasonable answer for Ted?
> 
> Mark

I was afraid when I tried to boil down two sets of trade-offs to a simple
statement that I would boil it down too far.  It seems I have, and I'm
sorry.  No, the existence proof of the code is not sufficient to prove
that complexity isn't an issue.  If the draft couldn't be implemented,
we would have a different discussion.  

I have elsewhere answered Paul's comment on autonomy,
					regards,
						Ted

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 21:48:52 -0800 (PST)

Paul writes: 
> > This point of view, that the OPT-IN mechanism is there primarily to
> > provide a knob for zone managers to use in running their businesses,
> 
> i don't think i said "primarily".  here, let's look:
> 
> > > it is not up to us as protocol developers to tell zone managers how
> > > they ought to "run their businesses."  that would be paternalism at
> > > its offensive worst, worse even than the "restrict key" silliness.
> 

Point taken; you did not say "primarily". 

> it's an aspect of what ought not be done, that's all.
> 
> > does not seem to me well laid out in the draft.  If the justification
> > is based on this, then I would say making clear which new knobs are
> > needed to do what would be a very useful thing.
> 
> the justification is not based on this.  

And we seem to agree that the draft does not make this argument.

> however, some zone managers
> have said that they want this and have put the onus on the standards
> community to say why they can't have it.  i don't think there's a
> reasonable basis for denying the request for this feature.  dnssec is
> such a step upward in complexity and brittleness from basic dns, that
> the incremental complexity from opt-in is pretty much lost in the noise.

We disagree.  You believe that the trade-off in value for this
feature is worth the incremental complexity.  I do not.

The primary point made in favor of this approach has been that
it will be easier to deploy for very large, flat zones.  I
do not disagree that it is problem.   I believe, however, that 
the barriers that they face are smaller now and continue
to recede.  The complexity will not recede.

You have made a second point that this provides a knob for
zone managers.  I believe that if that is even part of the reason for
this approach, a clear statement of its value belongs in the draft,
so that the community can better understand who this benefits (and
what the knob will be turned for).  As other messages in this thread
have made clear, there are real costs to this approach.

>  it is in other words far more likely that a
> given application manager or recursive server operator will avoid dnssec
> altogether than that they will face any noticable complexity penalty due
> to opt-in.

It is moderately obvious that you and I see the protocol from different
points of view, and I suppose that it is not surprising that we see
the likely deployment curve differently as well.  Rather than the
debate the merits of either of our conjectures, let us leave it that deployment
must be taken into account with the other factors, and let others
put the emphasis on it that they think appropriate.  
					regards,
						Ted Hardie

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 23:10:06 -0800

Dan,

On Thursday, March 13, 2003, at 02:04  PM, Daniel Massey wrote:
>> however this is a bit over the top.
> No, to me it reflects that is trade-off rather than a clearly right or 
> clearly wrong issue.  we are long past the time we should have decided 
> on this trade-off.

Agreed on both counts.

What I was complaining about was that the arguments raised by Olaf and 
Scott to which you were agreeing were adding the proviso that opt-in 
should only be used for "huge" zones.  This is, I believe, not an 
appropriate constraint to add.  There aren't a whole lot of "huge" 
zones (and it has often been argued that given their size, they should 
have sufficient resources to deal with this issue without spreading the 
cost over every secure DNS server implementation) and opt-in _only_ has 
value if you assume only a portion of the full zone is signed (thus my 
'temporary transition issue' statement).  If the protocol modification 
is not generally useful but instead is intended to address 
non-technical requirements for a limited set of users, then I 
personally do not believe it should be added.

Rgds,
-drc

---

From: Greg Hudson <[email-masked]>
Date: 14 Mar 2003 11:37:36 -0500

On Fri, 2003-03-14 at 02:10, David Conrad wrote:
> If the protocol modification 

I'm not sure what "non-technical" requirements you believe opt-in
addresses.  If Verisign wants to charge extra for a secure delegation,
they can do that without opt-in.

As to the "limited set of users" argument: almost every DNSSEC user is
expected to make use of opt-in from the client side.  It's important to
distinguish asymmetric features like this--used by only a few people on
the server side, but still affecting lots of users--from features which
will impact almost nobody.

---

From: Paul Vixie <[email-masked]>
Date: 14 Mar 2003 18:32:16 +0000

David Conrad <[email-masked]> writes:

> ...
> appropriate constraint to add.

i agree.

> There aren't a whole lot of "huge" zones (and it has often been argued
> that given their size, they should have sufficient resources to deal with
> this issue without spreading the cost over every secure DNS server
> implementation) and opt-in _only_ has value if you assume only a portion
> of the full zone is signed (thus my 'temporary transition issue'
> statement).  If the protocol modification is not generally useful but
> instead is intended to address non-technical requirements for a limited
> set of users, then I personally do not believe it should be added.

the opt-in protocol enhancement is generally useful, and increases the
control that administrators have over their zone data, at the marginal
cost of some kind of purported but unmeasured implementation difficulty.

arguments against opt-in have taken one of two forms, so far.  (1) "zone
autonomy is bad, and we the people demand our right to force administrators
of foreign/distant zones to sign it all or sign nothing."  or (2) "there's
some kind of nonzero incremental complexity, which could be harmful, so we
shouldn't do it."

arguments in favour of opt-in have taken one of two forms, so far.  (1)
".XYZ needs this."  or (2) "it improves the design."

has anybody got a new argument to offer, on either side?
-- 
Paul Vixie

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Mar 2003 11:52:21 -0800

Greg,

On Friday, March 14, 2003, at 08:37  AM, Greg Hudson wrote:
> addresses.

To be explicit, this isn't a Verisign-only issue. In today's Internet, 
you typically need a business case to justify doing something new to 
pretty much any infrastructure.  Given the vast majority of zone owners 
won't be interested in DNSSEC when it is first (finally) released, it 
is unlikely they'd be happy about paying more to get what DNSSEC 
provides.  Given it is unlikely people will want to pay more, it is 
hard to come up with a business case that would justify the additional 
costs necessary to deploy the DNSSEC infrastructure if those costs are 
significant which was thought to be the case for very large zones.  
Opt-in addresses this problem by allowing only those interested in 
DNSSEC to choose (and pay) to have their zones and delegations secured. 
  This is not a technical requirement, it is a means by which a business 
case can be made.

However, others have pointed out that Moore's law has caught up and 
passed this problem.  Signing a huge zone (say 33 million delegations, 
for example) has been demonstrated to take less than 2 hours on a $10K 
box (or rather, $10K a year and a half ago) and could be done faster.  
Propagation and loading the data is indeed an issue, but this issue is 
addressable in a variety of fashions (e.g., only propagate/load 
changes) using existing technology, albeit perhaps with changes to 
existing business processes.

My point was that opt-in should be included or not based on its general 
applicability, not because a small number of zones have decided for 
non-technical reasons to not fully sign the zone (and hence opt-in 
should be limited to those zones).   As Paul V. states, there may be 
intrinsic benefits that opt-in provides that justify its inclusion and 
the decision should be made by analyzing the costs of those benefits.

> expected to make use of opt-in from the client side.

I am unsure whether the vast majority of zone owners will bother with 
not signing their entire zones.  I guess it depends on the signing 
tools.

Rgds,
-drc

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 15 Mar 2003 20:33:32 -0800

I support OPT-In Zones.

I believe there has been consensus on the need for opt-in for
over a year.

	Phill

> -----Original Message-----
> From: Ólafur Gudmundsson/DNSEXT co-chair [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2003 11:01 PM
> To: [email-masked]
> Subject: DNSEXT WGLC: To OPT_IN or not to OPT-IN
> 
> 
> 

	Olafur

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sat, 15 Mar 2003 21:47:44 -0800

> box (or rather, $10K a year and a half ago) and could be done 

Not if you want to use FIPS certified hardware you can't.

The FIPS 140 boxes VeriSign currently buys cost $35K list (I would expect
we get a discount but I doubt that even we can buy one for $10K).

They do not perform at speeds remotely comparable to workstation or
server class hardware. 

The killer operational issue is the data volume, not the signing time.

		Phill

---

From: "Jörg Bauer/Denic" <[email-masked]>
Date: Thu, 20 Mar 2003 00:37:48 +0100

On Wed, Mar 12, 2003 at 11:01:05PM -0500, Ólafur Gudmundsson/DNSEXT 
> Please send explicit statements of support or disagreement.

I (and also speaking in the name of the .de registry, which is one of the 
"huge" problematic registries)
also prefer OPT-IN.

Joerg

--
--------------------------------------------
Joerg Bauer                     Denic eg 
[email-masked]          Wiesenhuttenplatz 26
fon: +49.69.27235180    60329 Frankfurt
                                Germany
--------------------------------------------

---

From: David Blacka <[email-masked]>
Date: Thu, 27 Mar 2003 18:44:23 -0500

I apologize for not catching this earlier...

On Friday 14 March 2003 01:16 am, David Conrad wrote:

> > And we have had some experience that it interoperates
> > Nominum to
> > comment on how much more "complex" it is to add opt-in support.
> 
> I'm told that
> - implementation of the validator turns out to be easy

Yay!

> - implementation of the authoritative side is harder

Ok, I think I understand that, at least in the context of how I think BIND 
9 works.

> - figuring out what needs to be cached is the hard bit

Somebody absolutely needs to explain this, as Opt-In does not envision any 
new caching requirements.  Well, the draft does talk about needing to 
fetch NXT records from the cache in an additional case, but that doesn't 
cover this statement.