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

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:
> Re: The Security Model:
> Opt-in does not alter the security model, since there is no static
> 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
> the field to handle opt-in for delegations only on all sides of the
> 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.

> Re: This Last Call Process.
> The last last call [sic] on technical matter showed
> consensus (see below). I perceive the current last call as 
> inapropriate.

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

Rgds,
-drc

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

At 13:55 +0000 3/27/03, Paul Vixie wrote:
><AOL>
>Me, too.
></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: 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.