Subject: Re: DNSEXT WGLC: DNSSEC Opt-in

From: Paul Vixie <[email-masked]>
Date: Tue, 04 Feb 2003 20:37:13 +0000

> Q: Is the description in the document of Opt-In complete ?

i believe that the current version of the specification is complete.

> Q: Does this document satisfy people as being implement able and testable
> specification ?

yes.

> Q: Are there implementations of opt-in and have there been any tests ?

yes.  (notes to be posted here shortly, so they tell me.)

--
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: Tue, 11 Mar 2003 21:15:06 +0000

> > >> DS RRsets MUST NOT appear at non-delegation points or at a zone's apex.
> >
> >why not?  i think you can say they are irrelevant elsewhere, but i don't
> >think there's a way to show that they are in any way harmful elsewhere.
> 
> Well the record is called "Delegation Signer".  IMHO this is a record
> for DNS consumption, and only for DNS, it makes limited sense to have
> DS record at non delegation points within the context of current
> DNSSEC specification.

that's all true but does not mention the harm in allowing them to
exist at other than zone boundaries.  

> In addition there are DS rules specify that it resides on the upper
> side of delegation.  Does allowing DS to reside at normal node require
> more special cases?

nope.  it's just data unless the delegation logic is being invoked.

> If someone figures out other uses for the DS concept that is not
> related to standard DNSSEC, lets define a new record for that.  If the
> new usage is to somehow improve/add on DNSSEC then the use of DS
> should be considered.

you have not yet shown any possible harm in letting DS RR's exist at
places other than zone boundaries.

> >as a simple document quality issue, there is no way to enforce this
> >requirement and no reliable way to even know when it has been violated.
> >so at best it would be a SHOULD not a MUST.
> 
> This is a real good argument, and I would be happy to make the change
> base on this, if the working group says so.

i hope it's the default unless the working group decides to make a change
like "it's ok to specify nonenforceable requirements in a standards doc."

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Mar 2003 16:48:20 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "mundsson" == mundsson  <lafur> writes:
    mundsson> delegation.  Does allowing DS to reside at normal node require
    mundsson> more special cases?

  No. 
  If there is any issue, you have to code for that case anyway, since you can
rely upon the network or software to behave properly.
 
    >> requirement and no reliable way to even know when it has been
    >> violated.  so at best it would be a SHOULD not a MUST.

    mundsson> This is a real good argument, and I would be happy to make the
    mundsson> change base on this, if the working group says so.

  I'd agree with Paul.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Mar 2003 23:19:11 -0500

> places other than zone boundaries.

and no one has shown the benefit.  so why add bangles to an already
complex world for unknown uses?  simplicity, please.

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 12 Mar 2003 13:50:16 -0500

The robustness principal probably applies here.  DS is a DNS
infrastructure RR type, we know of no useful purpose that DS RRs
anywhere other than at delegation points would serve, and at least
some of us think that reusing existing RR types for fundamentally
different purposes is a risky thing to do, therefore:

a) Zones either SHOULD NOT or MUST NOT include DS RRs anywhere but at
   delegation points;

b) Software MUST cope if a zone violates (a).

I tend to think that (a) should be MUST NOT, on the grounds that it
probably simplifies the implementation of (b) slightly (software must
not fall on its face, full stop, but don't expect an implementation to
do anything useful with a non-delegation DS RR).

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 06:09:49 +0000

> Q: Is there consensus by the WG, to allow Opt-in zones?
> 
> Please send explicit statements of support or disagreement.

as an individual, i support this.

if organizational support matters, isc supports this too.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 06:10:51 +0000

> This document defines a new KEY RR flag that is used to identify keys that
> are used to sign KEY RRset. The flag is not used by the DNSSEC resolution
> process. The main purpose of this flag is to ease administration of DNSSEC
> signed zones.

i support this.

---

From: Roy Arends <[email-masked]>
Date: Thu, 13 Mar 2003 12:11:38 +0100 (CET)

On Wed, 12 Mar 2003, Ólafur Gudmundsson/DNSEXT co-chair wrote:

>
> This starts a two week working group last call,
> concluding on March 28'th 2003.
>
> The document to base this discussion on is
>      http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt
>

I support opt-in.

Roy

---

From: Matt Larson <[email-masked]>
Date: Thu, 13 Mar 2003 07:52:03 -0500

> Please send explicit statements of support or disagreement.

I support Opt-In.

Matt

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 13 Mar 2003 15:09:14 +0100

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

Although I would advise against its use in all other cases but the huge
zones out there, I do support the draft.

--Olaf

---

From: Mark Kosters <[email-masked]>
Date: Thu, 13 Mar 2003 10:07:33 -0500

I support opt-in.

Mark

-- 

Mark Kosters            [email-masked]       Verisign Applied Research

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 13 Mar 2003 10:47:08 -0500

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

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 08:54:01 -0800 (PST)

I oppose OPT-IN going forward as a proposed standard.  

It is very clear that there are some engineering trade-offs
here, and I'm very glad that we've taken the time to explore
them.  In this case, I would summarize a bunch of trade offs
by saying "ease of zone management for large zones" vs.
"complexity (both of code path, and, more generally,
the understanding of the states DNSSEC will imply)".
In a case where there are trade-offs of this type, I
think it is important to look both at where we are today
and where we are likely to be later.  My take is that
the deployment of DS for large zones today _is_ a
problem, but a tractable one given today's hardware and software
either present or far along the pipeline; more importantly,
I believe it will only get easier as the maturity of
those products increase.  The "complexity" side of the equation
doesn't seem to me to get much better as time goes on.

Based on that, I believe we would be making the wrong choice
to advance OPT-IN; if we allow it, it will be part of
the standard for a very long time, and we will be living
with its complexity well past the time horizon that the problems
it addresses have ceased to be an issue.

				regards,
					Ted Hardie

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Mar 2003 13:09:17 -0500

> if organizational support matters

<chair>

in the ietf it doesn't.  sorry to do this publicly, but we need
to be very clear on this.  such assertions are inappropriate and
damage one's position.

randy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Mar 2003 12:45:33 -0600

I support opt-in.   We've been playing around with DNSSEC for a long 
time, and we will still be playing with it (or have abandoned it) ten 
years from now if we don't adopt opt-in.

---

From: Mark Kosters <[email-masked]>
Date: Thu, 13 Mar 2003 14:58:22 -0500

I would prefer to see some hard numbers before I would agree with
this conjecture.

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Mar 2003 17:29:24 -0500

> I would prefer to see some hard numbers before I would agree with

just a sec.  years ago, we asked you for hard numbers on the problem
of large zones.  what you provided did not make your point.  you are
asking for a change to acommodate your needs.  the onus is on you to
justify that need, not vice versa.

randy

---

From: Mark Kosters <[email-masked]>
Date: Thu, 13 Mar 2003 18:19:21 -0500

On Thu, Mar 13, 2003 at 09:31:12PM +0000, Paul Vixie wrote:
> 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.

I agree that the complexity args on one side and additional operational 
requirements on the other can be colored by the type of glasses worn.

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

Is this a reasonable answer for Ted?

Mark

--

---

From: Bob Halley <[email-masked]>
Date: 13 Mar 2003 15:48:09 -0800

> based on either basis is just pure FUD.

I don't see how either can be written of as "pure FUD".  The OPT-IN
draft describes itself as a way to make a cost-benefit adjustment for
certain classes of zones.  It does not justify itself on the grounds
of zone administrators needing more knobs.  If the resource and
operational issues are significant, then they are fair game and not
FUD.  If they are not, then why do we have OPT-IN at all?

Likewise, complexity is a fair argument that isn't just FUD.  Just
because implementations can, and have, been made does not mean that we
should impose the complexity of OPT-IN on every subsequent
implementation, or on the system as a whole.  We also had multiple
implementations that did A6 records and bitstring labels, yet that
technology is no longer progressing (and rightfully so!).  Also,
because this is an area involving security, any increases in
complexity of validation must be taken seriously.  Complexity is often
the enemy of good security, making implementation errors more likely,
and more difficult to find.

/Bob

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 22:16:44 -0800

Mark,

On Thursday, March 13, 2003, at 11:58  AM, Mark Kosters wrote:
> completed.

I know of one implementation of a recursive server that does 
_delegation only_ opt-in.  I would, of course, be interested in hearing 
of another.

> And we have had some experience that it interoperates

I'm told that
- implementation of the validator turns out to be easy
- implementation of the authoritative side is harder
- figuring out what needs to be cached is the hard bit

Different server architectures make coming up with a consistent answer 
regarding complexity difficult.

Rgds,
-drc

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 19 Mar 2003 22:48:23 -0300

> Please send explicit statements of support or disagreement.

We strongly support OPT-IN. Today as the "standard" is we can't deploy
DNSSEC without OPT-IN.

Fred