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: David Conrad <[email-masked]>
Date: Fri, 14 Mar 2003 10:53:53 -0800

Roy,

On Friday, March 14, 2003, at 05:22  AM, Roy Arends wrote:
> 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.  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.

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

> 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.  Perhaps you have 
seen something else.  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 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?

> 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).  In any event I certainly intended no questions of integrity and 
if such were perceived, I apologize.

Rgds,
-drc

---

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

On Fri, 14 Mar 2003, David Conrad wrote:

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

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

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

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

> > 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.
>
> 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: Sam Weiler <[email-masked]>
Date: Thu, 27 Mar 2003 01:51:00 -0500 (EST)

Summary:

I still oppose opt-in, but for the moment I'm willing to step aside
and let it advance.  I am, though, going to send out a proposal to
mitigate some of the damage opt-in causes.  I'm also wondering if
opt-in (and DS) should be held back until we fix the problem described
in draft-weiler-dnsext-dnssec-2535-compat-00.txt.

I would be happier if other uses for opt-in were documented.  If
nothing else, they would help shoot down my forthcoming proposal.  I
also suspect a good argument could be made for the utility of opt-in
without the delegation-only restriction, though I'm not willing to
wait to beat all the corner cases out of another change.

I would also be more comfortable if I saw hard numbers of signing
costs with and without opt-in; the fact that .com has been signed
without opt-in in testbeds makes me leery of claims that it's
impractical, especially with non-testbed hardware.  Joerg and
Frederico, can you provide more details of your analysis?  (Yes, I
know the list has talked about it for years, but I'm a relative
newcomer, and hardware keeps getting cheaper.)

Irrelevant details:

First, I applaud the chairs' decisions to split this last call into
two parts and then extend the last call past IETF56.  I still had (and
have) issues with the document, and I appreciate the extra time.  And
I disagree with Roy re: the appropriateness of this second last call
-- mere technical completeness does not justify the advancement of a
document.

Second, as for consensus, the Religious Society of Friends (Quakers)
have some interesting ideas about it, and I've used the phrase "step
aside" as a Quaker might.  Quakers, while they let one person block
consensus, provide a number of ways for people to implicitly or
explicitly register disapproval, discomfort, or other opposition to an
action without blocking consensus and standing in the way of progress.
For the moment, and this may change, that's what I'm doing.  Another
interesting custom during Quaker "meetings for worship with an
attention to business" is that each person is expected to speak no
more than once on a given topic (unless they're the chief stuckee or
have peculiar specialized knowledge) -- if something more needs to be
said, then the spirit will lead another to say it.  Perhaps we could
learn something from them.

Slightly more relevant detail:

Paul's 14 May message helped reframe the debate for me.  He reminded
me that opt-in really is optional -- a zone owner can ignore it and
keep the stronger security guarantees.  If that were the end of the
story, I'd say we should rely on financial and political pressure, not
standards process pressure, to make zone owners behave the way we
want.  Unfortunately, opt-in also adds resolver complexity, which
means that the proponents need to justify the change.  I'm not sure
they've done that adequately, but I'm willing to quit fighting.  They
have contributed to the implementation and testing to show that the
complexity is manageable, and I thank them for that.

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Thu, 27 Mar 2003 02:01:52 -0500 (EST)

This proposal addresses one of the technical concerns re: opt-in.

Two of the objections to opt-in are that it 1) reduces security and 2)
adds complexity.  As time and technology make signing whole zones less
expensive, we might get the stronger security guarantees back.  We do
not, however, ever get to remove the opt-in code from resolvers unless
we can guarantee that ALL opt-in zones are gone.  As such, the
complexity cost of opt-in will stay with us eternally, long after the
justification for it has passed by.

If we could somehow limit the number of zones that use opt-in, we
might eventually be able to obsolete opt-in and remove the opt-in code
from resolvers, saving that ongoing complexity cost.

The proposal: limit opt-in to TLDs.  Since TLDs are relatively few in
number, it's tractable to track all the operators down and beat them
up.  Once none use opt-in, opt-in code can be removed from resolvers.
Specific text: "TLDs MAY use opt-in.  Deeper delegations MUST NOT use
opt-in.  Resolvers SHOULD reject opt-in delegations from non-TLDs."

Technically, it's still better to not do opt-in.  The objections I've
heard to this planned obsolescence proposal, though, aren't technical.
We shouldn't put on our technical blinders just because financial and
political issues are forcing us down the opt-in road -- we should
still try to make the technical best of the situation.

Olaf's and Scott's May 13th messages reminded me to dig this proposal
up.  Remember to thank them when you next see them.

-- Sam

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 27 Mar 2003 10:09:10 +0100

> adds complexity.  

Short comment: Solving complexity by adding more complexity? 

Longer comment:

- Having OPT-IN over delegation points only and noticing that most of
  the zones in the world do not have very deep delegation trees I think
  that OPT-IN will be limited to TLDs de-facto.

- This is difficult to enforce because of TLDs that have a two level
  structure like "co.uk."

I do not think that this is very practical. I do not think that the
protocol should enforce limited use. I do think that operators should
think twice before deploying an OPT-IN zone.

--Olaf

--------------------------------------------| Olaf M. Kolkman
                                            | www.ripe.net/disi

---

From: Rob Austein <[email-masked]>
Date: Thu, 27 Mar 2003 04:57:43 -0500

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.

I've posted enough on this subject in the past that the reasons why I
oppose opt-in should be clear by this point (for an example, see my
message to this list on 4 February 2003).  The summary version is that
opt-in trades some near-term pain (cost) for operators of large
servers against some ongoing pain (cost and complexity) for developers
and resolver operators, and while I have some sympathy for the large
server operators, I don't think that this is a good tradeoff for the
Internet as a whole.

Thanks to Sam Weiler for reminding me of appropriate terminology
(having spent four years at a Friend's school, I should know this
stuff, but it's been a while...).

---

From: Miek Gieben <[email-masked]>
Date: Thu, 27 Mar 2003 13:02:42 +0100

[On 27 Mar, @10:57, Rob wrote in "Re: DNSEXT WGLC: To OPT-IN or  ..."]
> we need to make a decision and put this behind us.

I totally agree with this. That is: I oppose opt-in, but ...

grtz  Miek

--
:wq!

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Mar 2003 13:55:18 +0000

> think twice before deploying an OPT-IN zone.

<AOL>
Me, too.
</AOL>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 Mar 2003 14:15:59 +0000

> complexity is manageable, and I thank them for that.

i think that with that as your reason for thinking it's a bad idea, that
standing aside is the right thing to do.  the loss of security to opt-in
is optional, and represents the possibility that some other zone operator
may not want as much security in their zones as you want in yours, and we
would normally say that it's their zone and they should be able to decide
without help from outsiders how secure their zone ought to be.

now as to whether the zone security flexibility being desired is worth,
or not worth, the resolver complexity that's required, we've all been down
that thread and there's apparently nothing new on this controversial topic.
i just want to say: it appears not to be a given, either way.

---

From: Sam Weiler <[email-masked]>
Date: Thu, 27 Mar 2003 10:09:15 -0500 (EST)

On Thu, 27 Mar 2003, Sam Weiler wrote:

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

-- Sam

---

From: Sam Weiler <[email-masked]>
Date: Thu, 27 Mar 2003 10:00:42 -0500 (EST)

>   that OPT-IN will be limited to TLDs de-facto.

I suspect that even very small zones will find some creative uses for
opt-in, and you'll see it at more places in the tree.

> - This is difficult to enforce because of TLDs that have a two level

I did, in fact, mean "resolvers SHOULD reject opt-in delegations from
zones other than the root" or perhaps even "resolvers SHOULD reject
opt-in delegations more than one label in length".  Which leaves co.uk
out in the cold.  Having co.uk speak up or having some of the bizarre
uses for opt-in documented would help persuade me that this limitation
is a bad idea.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Mar 2003 10:20:15 -0500

>from resolvers, saving that ongoing complexity cost.

You do realize that if just one zone runs this legally, 1,394,782 
resolvers need to have the code.  If 1,394,782 zones run this 
legally, 1,394,782 resolvers need to have the code.  Worse, limiting 
the scope is one more rule the 1,394,782 resolvers need to enforce.

(About the 1,394,782 - we know who you are. ;) )
(Just kidding - the number *is* meaningless, btw.)

>Since TLDs are relatively few in number

That's for ICANN (et.al.) to decide, not us.  (PS - what about 
.co.jp, .co.uk, and the like?)

>it's tractable to track all the operators down and beat them up.

E.g., read NANOG, for just a taste of what it takes to lay a smack 
down (that's evidently what the kids call it these days) on just the 
operators just in North America.

>still try to make the technical best of the situation.

Frankly, I don't see a technical reason to avoid opt-in.  It 
accommodates a wider range of what operators want to offer in terms 
of DNSSEC while not compromising the overall operation of the DNS. 
Yes, descendent zones of an opt-in zone may have issues - but they 
choices.  Okay, this is another thread.

As far as code base, no implementer had said that opt-in is onerous, 
I've even heard that it's just a few lines of code.  As far as the 
protocol is concerned, it's one bit in the NXT that is redefined. 
'Course, signed wild cards and opt-in and dynamic update and opt-in 
don't mix and maybe that's a concern at some level, put pragmatically 
no one seems enough to care that there are really problems.

>up.  Remember to thank them when you next see them.

I'll deal with Olaf in May.  Scott, I'm coming over to your place in 
an hour.  I'm bringing my big stick. ;)  Sorry...couldn't resist.

>Short comment: Solving complexity by adding more complexity?

Yeah, what he said.

Oh, and:

></AOL>

<AOL> Me, too.</AOL>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 27 Mar 2003 12:32:00 -0500

>opt-in, and you'll see it at more places in the tree.

I'm not sure if the statement is meant as sarcasm, but in general, 
when a mechanism finds more usefulness than originally intended, 
that's a good thing.  Marketing folks label this organic growth.

You appear to be assuming that opt-in is dangerous.  At least that's 
what I assume you are thinking.  From my view point, opt-in is not 
dangerous.

If a zone chooses to use opt-in, the zone has some decisions to make. 
E.g., is the typo attack of interest?  Any zone delegated below an 
opt-in zone is impacted by the choices made.  All other zones are not.

How does opt-in impact DNS?  Outside of DNSSEC, not at all.  How does 
opt-in impact DNSSEC?  To answer this, think of the situation of the 
resolver.  Recall that DNSSEC is designed to permit a resolver to 
judge the authenticity of the response.  DNSSEC is not designed to 
make statements about a zone's security preferences.

Once a resolver has an answer in hand, in 2535-era DNSSEC, either the 
data is supposed to be unsigned or signed.  How the verifier 
distinguished the "supposed to" is through a diligent search of the 
configured keys and zone cuts.  All that opt-in does is allow a 
switch from signed to unsigned above the zone cut and not at the zone 
cut.

The FUD is that opt-in messes up zone management security.  With 
opt-in, a zone can't be sure that delegations are improperly 
inserted.  With opt-in, a zone can't be sure that a signed wild card 
will work properly.  With opt-in, we forbid dynamic update now 
because there hasn't been time to work it out.

But DNSSEC isn't about zone management security.  That's the prime 
defense of the opt-in supporters.  Opt-in is vulnerable to delegation 
insertions, but so is unsecured DNS.  Opt-in isn't causing a failure 
here.  But then, why bother doing opt-in?  With opt-in, I can set up 
a resolver to succeed in establishing some confidence in an answer in 
the instances that this can be done.  Yes, DNSSEC without opt-in 
increases the the percentages of these instances to 100, but at least 
opt-in gets it above the current level of 0 that DNS offers today.

>uses for opt-in documented would help persuade me that this limitation

What do you mean be "resolvers should reject"?  Why do you want to 
add such an artificial limitation?

#ifdef ietf-debate-society
Instead of asking to be persuaded that the limitation is a bad idea, 
you need to make a case that the limitation is a good idea.  Don't 
fight entropy unless the disorder is becoming a nuisance.
#endif

(Sorry, the html tag fad is still too new for me.)

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 27 Mar 2003 13:52:29 -0500

>server operators, I don't think that this is a good tradeoff for the

I agree on both points.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)

---

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

On Thursday 27 March 2003 01:51 am, Sam Weiler wrote:
> mitigate some of the damage opt-in causes.

Damage?

> newcomer, and hardware keeps getting cheaper.)

The amount of time and the cost of the hardware needed to *sign* .com
is a red herring.  Opt-In has never been about making the impossible
possible, or even making the impractical practical.  It is about
making the inefficient more efficient.

And for the zones for which Opt-In is appropriate, the gains in
efficiency are not temporary.  Even as the costs of not doing Opt-In
decrease, using Opt-In will still be better for them.  Remember that,
for these zones, Opt-In relieves signing, provisioning, distribution,
and serving costs.  Those different costs may all eventually shrink,
but they don't shrink at the same rate.

So I take issue with the assertion that Opt-In is all about relieving
"near-term pain" at the cost of inflicting "ongoing pain".  Both types
of pain are ongoing.

> story, I'd say we should rely on financial and political pressure,
> not standards process pressure, to make zone owners behave the way
> we want.  Unfortunately, opt-in also adds resolver complexity, which
> they've done that adequately, but I'm willing to quit fighting.
> They have contributed to the implementation and testing to show that
> the complexity is manageable, and I thank them for that.

What kind of justification are you looking for that hasn't been said?
Some zone owners have said they want it.  It very clearly solves a
problem.  It may not be a problem that *you* have.

Lets talk about the complexity for a bit.  While there certainly is a
theoretical fixed, absolute cost to implementing Opt-In, we don't
really know what that cost is yet.  I know that whatever the cost of
implementing it in BIND 9 was, the costs of implementing again in
other implementations are going to be less.  The more it is
implemented, the greater it will be understood, and the easier it will
be to implement the next time.  So I certainly believe that the
resolver cost is not going to be constant for the lifespan of DNSSEC.

That said, I have yet to hear anything from the resolver developers
why (or even if) implementing opt-in on the resolver side is hard.  In
fact, I have only heard (and only heard, mind you) that the resolver
side was fairly easy and the authoritative part was hard.  Which was
not what I expected given that I found that doing an authoritative
server fairly easy to implement, compared to making it do DNSSEC at
all.
-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

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

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 27 Mar 2003 19:41:44 -0800

> opt-in, and you'll see it at more places in the tree.

give weenies a gun and they will shoot themselves and their neighbors
in the feet.