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

From: Roy Arends <[email-masked]>
Date: Fri, 14 Mar 2003 14:22:17 +0100 (CET)

Some of my views re: opt-in and this whole last call process:

Re: The Security Model:

Opt-in does not alter the security model, since there is no static
security model defined.  Some form of trust model may be implied by
2535, but this asserted model has already been altered numerous times by
subsequent documents.

Re: Layer 8 Arguments.

The cost to manage a signed zone is substantial.  Deploying DNSSEC on
large delegation centric zones is substantial.  Using Opt-In on the latter
does ease deployment costs.  The cost of adding and mainting Yet Another
Code Path is also substantial.  What I've seen is that there exist code in
the field to handle opt-in for delegations only on all sides of the
query/resonse end.  It is hard to quantify and compare all costs.
Downplaying concerns by bluntly comparing cost are layer 9 tactics.

Re: Again Changing the Specs:

This document originated in 2000, the current suggested changes to dnssec
originated in 2001. We saw numerous updates to 2535 since 2000:  Key-
restrict, DNSSEC-OK, delegation signer, ad-bit, so on and so on.  I do not
suggest changing specs Ad-Hoc is a good thing.  This proposed change to
the spec originated some time ago, and is not some last moment hack.  As I
see it, this change to the spec is minor.  Opt-In is not rocket science.

Re: Opt-in for Delegations Only.

One cryptographically signs that a subzone is not cryptographically
signed.  Opt-In for delegations requires all authoritative data in a zone
signed.  Glue records and delegation NS records are not authoritative
data, and possibly signed elsewhere.  Proving a subdomain exist can be
done by signing the subdomain.  Pushing the burdon of proof up the tree
without signing the subtree does not scale well. Simply signing stuff
because 'We Dit It On A Laptop' does not scale well either.

Re: This Last Call Process.

The authors of this document have tried to address the concerns and
alledged technical problems.  The draft has been changed a few times
to reflect and constrain the 'damage' that is perceived.  There have been
several last calls.  The last last call [sic] on technical matter showed
consensus (see below). I perceive the current last call as inapropriate.

I see yet another last call coming with the question "Are we really
really really sure ?"   ;-)

Sadly we've come to the point that integrity of people publicly supporting
the draft is questioned by those who so passionately do not care what
decision is made.  That is deliberately polarising the discussion.

Roy

    Date: Fri, 28 Feb 2003 09:10:14 -0500
    From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
    To: [email-masked]
    Subject: DNSEXT WGLC summary: OPT-in

    This last call has completed.

    The result of the last call was that there is consensus the technical
    specification was almost ready. Authors have worked with this chair to
    create a new version of the document that addresses the issues raised
    in the last call and have submitted a new version. The message below
    contains the list of changes to the document:
    http://psg.com/lists/namedroppers/namedroppers.2003/msg00489.html
    Due to the expected delay in posting the new version as a ID here is
    a pointer to the new version:
    http://www.logmess.com/~roy/draft-ietf-dnsext-dnssec-opt-in-05.txt

    The chair would like to thank the working group members that responded
    to the message below and engaged in one of the better technical
    debates the mailing list has seen.

         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: Roy Arends <[email-masked]>
Date: Sat, 15 Mar 2003 00:13:35 +0100 (CET)

On Fri, 14 Mar 2003, David Conrad wrote:

> Roy,
>
> On Friday, March 14, 2003, at 05:22  AM, Roy Arends wrote:
> > Re: The Security Model:
> > security model defined.
> Perhaps I am mistaken, but in 2535, or at least as it has commonly been
> interpreted, without opt-in, all names within a zone can be
> authenticated or they can't.

Authenticated as in sig(ownername+class+type+ttl+rdlen+rdata), yes, the
same is true with opt-in.

2535 does not sign delegation point NS record and does not sign glue, same
with opt-in.

> There is no middle ground, i.e., the name does exist but it isn't
> authenticatable.  With opt-in, individual names within a zone may or may
> not be authenticatable, depending on whether the name has opted in.
>
> It is hard for me to see this not being a change in the security model.

What "the security model" ? If there exist a static model I'd like to
know. As with any security model, it's a defense against some form
of threat. Merely defining a set of rules and following them blindly is
not enough to form a security model.

> I have no comment on whether this change is good or bad, I am merely
> stating that it exists and has implications.

Sure, opt-in changes the spec. But that change should not be overrated.
The change is marginal in code-path. I am not downplaying implications of
this change. I've spent a considerable amount of time researching
corner-cases, and they turn out the be part of the general DNSSEC case.

> > Re: Layer 8 Arguments.
> > What I've seen is that there exist code in
> > query/resonse end.
> What I've seen is a pre-release, not generally available, of code that
> has had some preliminary testing in a lab setting.

Same here. I've seen the pre-release stuff. Pre-release code testing was
not the main goal, but the change to the protocol was what was tested.

> Regardless, at this stage of protocol development, this is not
> unexpected.
>
> > As I see it, this change to the spec is minor.
>
> People who have implemented opt-in appear to differ with this
> assertion, but such evaluations are, of course, subjective.

The change to the spec is minor. I did not talk about code. It is
not rocket-science, though.

> > The last last call [sic] on technical matter showed
> I also will admit some surprise that this issue has yet again come up.
> Perhaps the chairs can provide details on the process they are
> following here?
>
> > Sadly we've come to the point that integrity of people publicly
> > supporting the draft is questioned by those who so passionately do not
> > care what decision is made.
>
> Presumably, given my stated position on the issue, this was directed at
> me.  I would be interested to see where I have questioned _anyone's_
> integrity in this discussion (I have, on the other hand, seen
> suggestions that anyone claiming complexity is a concern is spreading
> FUD).

My 'integrity' wording was too strong. You at least 'challenged'
others in a way that i interpreted as ad hominem, which was at least odd
given that you 'did not care what decision' in the same message.

I do care.

Roy

---

From: Daniel Massey <[email-masked]>
Date: Fri, 14 Mar 2003 23:23:25 -0500

On Friday, March 14, 2003, at 06:13  PM, Roy Arends wrote:
<snip>
> corner-cases, and they turn out the be part of the general DNSSEC case.

I think this is a key point. I was also one of the people concerned 
about the security model impact of opt-in, but in my view this was 
addressed.   Paraphrasing what I learned from Roy and others is that 
the DNS really deals with signed RRsets.  A model of signed zones 
quickly starts to lose meaning from the perspective of a resolver, 
cache, etc, and not an even authoritative server really must check that 
a zone is properly signed.   In terms of security model, for reasons 
other than opt-in we should focus on signed RRsets and not signed zones.

Although I will not go as far as saying opt-in has no impact on 
complexity and security model, it seems much of the added complexity 
and security model is really due to DNSSEC itself and opt-in has a 
small impact at most in that regard.

Dan

---

From: [email-masked] (Ted Lindgreen)
Date: Thu, 27 Mar 2003 12:18:41 +0100

[Quoting Rob Austein, on Mar 27, 11:14, in "Re: DNSEXT WGLC: To  ..."]
> I oppose opt-in, but would be willing to stand aside if the WG were to
> approach consensus in favor of opt-in, because I strongly agree that
> we need to make a decision and put this behind us.

This is exactly also my position.  I strongly feel that the problems
that OptIn may or may not solve or impose are dwarfed by the problems
we still have to face to get DNSSEC widely deployed. Most of the
work sofar has been done from the viewpoint of the DNS-administrator,
we still have to do a lot of work to make DNSSEC understood, working,
and useful for the user.

-- ted (NLnet Labs)

---

From: David Blacka <[email-masked]>
Date: Thu, 27 Mar 2003 17:55:34 -0500

On Thursday 27 March 2003 10:09 am, Sam Weiler wrote:
> On Thu, 27 Mar 2003, Sam Weiler wrote:
> 
> > I still oppose opt-in, but for the moment I'm willing to step aside
> > and let it advance.
> 
> Actually, I do have a minor issue with the document itself.
> 
> This sentence in the abstract is grossly overbroad: "Maintaining this
> cryptography is not practical or necessary."  The document also does
> not address why signing insecure delegations is unnecessary.  There
> are, in fact, reasons for doing so, as documented in the security
> considerations.  Perhaps the entire sentence should be dropped?

At this point, you are going to have to send text, I think.  I can no 
longer guess what people actually want this document to say.

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