Subject: the topic change RE: ...

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Apr 2002 17:16:00 -0400

At 4:48 PM -0400 4/11/02, Loomis, Rip wrote:
>  <TOPIC CHANGE>
>Have any of the people advocating Opt-In ever tried to
>explain *basic* DNSSEC to a *basic* DNS administrator?
>I have, and it's not pretty.  Opt-in adds another layer
>of complexity.  I fear complexity.

Opt-In began as an optimization to ease the adoption of DNSSEC into large
zones.  By their very nature, optimizations are complications.  So I think
I am seeing the same dilemma that Rip mentions.  I like what opt-in does,
becuase it does some optimization - making the workload in transitioning
from unsigned to signed to be intuitively incremental.  But as we delve
into the details, the complexity introduced is rapidly becoming evident.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Last day is Wednesday, April 24, 2002...

Opinions expressed are property of my evil twin, not my employer.

--
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: Edward Lewis <[email-masked]>
Date: Thu, 11 Apr 2002 17:16:16 -0400

At 4:48 PM -0400 4/11/02, Loomis, Rip wrote:
>> What is needed is a term that captures:
>>
>>   "...means that the resolver should expect to get a
>>    signature with this data set.  Failing to do so means
>>    that the data set in hand is to be disposed of and
>>    every effort made to retrieve a new one."
>
>I'm not sure why--can you give a specific example of
>why we need such a term (and to whom might it be useful?)

Given that there are non-DNSSEC aware caches in existence and that DNSSEC
does not provide message integrity, it is possible that an answer might
contain an RRset but not its associated signature.  (I'm assuming there is
an associated signature.)  In this instance, the resolver should a) reject
the unsigned answer, b) request the SIGs at the name, or c) restart the
query to avoid the cache in question.  Whether a, b, or c is chosen is up
to the implementation's requirement for robustness and whether c is even
possible (think firewall).

Whether or not the resolver gets a signature with the data, the resolver
needs to know whether one is expected.  If a sig arrives and none is
expected, the sig may be ignored.  If one arrives and one is to be
expected, then the resolver is happy.  If no sig arrives, the resolver
needs to know whether or not one is to be expected.

This "concept" isn't about whether the data is secure, but rather what the
resolver should expect to be processing.

>In the opt-in New World Order, it seems that every data set
>has to be handled on a case-by-case basis in most situations.

That has always been the case, but in the Old World Order, the status of a
piece of data was the same as anything else in the zone - so I got lazy and
just assigned the term to the whole zone.

>The best phrases I could use to describe the above
>situation are "possibly signed" or "signature expected"
>and I'm not sure either has enough semantic content to
>be useful.

That's on the right track.  It's about what the resolver should expect to
see.  It's not about the validity of the data.

---

From: Mats Dufberg <[email-masked]>
Date: Thu, 11 Apr 2002 23:30:09 +0200 (CEST)

On Apr 11, 2002, 16:48 (-0400) Loomis, Rip <[email-masked]> wrote:

> More importantly:  We're changing the goal of
> DNSSEC from what was clearly stated in the past--providing
> a method so that *all* DNS data could be clearly verified.
> I can believe that for large zones that primarily consist
> of delegations, Opt-in is useful and perhaps financially
> necessary.  I *don't* like the "full opt-in" that seems to
> now be the sense of the WG, because it makes it *less* likely
> that every node in DNS will ever be signed.

I think that we all agree on the goal, but not on the road to get there. I
think it is unlikely that we will get all nodes signed until DNSsec is
mandatory (and maybe not even then), but think it is *more* likely that
DNSsec will roll out in some quantity if opt-in is accepted. And in ten
years time we will have a larger percentage of all nodes signed with
opt-in, than without.

> I'm normally a libertarian, but as a security weenie I want
> to force DNSSEC to be available.  I don't want security to
> only be applied to a small subset of DNS data (...)

Neither do I, but even without opt-in that will happen. If you do not want
to sign all the host names of your office work stations you can just move
those to a subzone, and let that be unsigned.

Mats

----------------------------------------------------------------------
Mats Dufberg				             Registry TeliaNet
[email-masked]                                  Skanova/AO Networks
+46 8 456 7274                                               Box 10707
+46 70 258 2588                                    SE-121 29 Stockholm
----------------------------------------------------------------------

---

From: Roy Arends <[email-masked]>
Date: Fri, 12 Apr 2002 00:30:46 +0200 (CEST)

> >of complexity.  I fear complexity.

You can explain it as complex as you desire, you govern your own fear.

I have explained DNSSEC to several folk with different cluefullness, in
the end, opt-in is the easy explanation.

> into the details, the complexity introduced is rapidly becoming evident.

I completely disagree.

Opt-In is not an optimization nor a complication. 2535 was too anal to
begin with. Opt-In re-focussed the whole "denial" discussion. I strongly
disagree with folk who claim "authenticated denial" is the same as
"authenticated denial of unsigned material". I still believe strongly in
the fact that "authenticated denial of unsigned material" is useless and a
total waste of your and my resources, no matter how much you think how
little the extra cost to do so might be. You may call that an
optimization. I call it a better focussed design spec.

There is no way that 2535 will be adopted within the whole tree. Without
opt-in, DNS admins will use the ol' pandora's box to achieve the same
goal. Delegate unsigned material out of a secured zone. That is what
happens already with unsigned delegations. Now _that_ is a big rope.

The complexity introduced recently ("encapsulated NXT") is a non-issue. A
NXT chain is a chain that covers all signed names in a zone, regardless of
opt-in or 2535. This has not changed. If there exist some SIG in the zone,
there must be an associated NXT. If there is not, this is simply a
protocol violation, just as CNAME and other data.

I still see restricted opt-in or no opt-in arguments as _strictly moral_,
they bear no technical matter whatso-ever. The rope might be viewed as
somewhat longer as it used to, but in a few years, it will simply be a
rope.

Roy

---

From: David Blacka <[email-masked]>
Date: Thu, 11 Apr 2002 18:34:50 -0400

[ post by non-subscriber ]

>>>>> "Rip" == Rip Loomis <Loomis> writes:

 Rip> As an off-topic tangent, or possibly on-topic for the original
 Rip> topic above: For the record, I still disagree with opt-in since
 Rip> I don't agree that objections previously stated were "moral" in
 Rip> nature.  IMHO, adding granularity of security within a zone
 Rip> makes it more difficult to describe and understand security, and
 Rip> therefore makes it more difficult to maintain--and that's a
 Rip> technical problem not a moral one.

We do not know how much harder DNSSEC with opt-in is to explain.
Everyone here is coming from a position of being comfortable with
2535, so opt-in seems like a lot of additional complexity.  If you
were taught DNSSEC with opt-in initially, it might not seem like a big
deal.

 Rip> Have any of the people advocating Opt-In ever tried to explain
 Rip> *basic* DNSSEC to a *basic* DNS administrator?  I have, and it's
 Rip> not pretty.  Opt-in adds another layer of complexity.  I fear
 Rip> complexity.

I will agree the DNSSEC is hard to describe to the layman.  I have
tried and found it difficult.  I have not found opt-in significantly
more difficult to explain, however.

It could be argued that all your basic DNS administrator really needs
to know about opt-in is not to use it.

 Rip> More importantly: We're changing the goal of DNSSEC from what
 Rip> was clearly stated in the past--providing a method so that *all*
 Rip> DNS data could be clearly verified.  I can believe that for
 Rip> large zones that primarily consist of delegations, Opt-in is
 Rip> useful and perhaps financially necessary.  I *don't* like the
 Rip> "full opt-in" that seems to now be the sense of the WG, because
 Rip> it makes it *less* likely that every node in DNS will ever be
 Rip> signed.

IMO, it was never likely that every node in DNS would be signed.  To
do that, you would have to make DNSSEC mandatory.  However, if, in the
distant future, we should wish to make DNSSEC mandatory, opt-in does
not make it any harder.

Also, opt-in also could be used to solve other tricky problems that
DNSSEC poses, like record synthesis or wildcards.

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

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 12 Apr 2002 10:55:29 +0200

On Fri, 12 Apr 2002 00:30:46 +0200 (CEST)
Roy Arends <[email-masked]> wrote:

> the fact that "authenticated denial of unsigned material" is useless and
> a total waste of your and my resources, no matter how much you think how

You get me confused again :-)

What is the difference between 'authenticated denial of unsigned
material' and the 'authenticated denial'? Material that does not exist
is by nature unsigned. If unsigned material appears where it is
supposed to not exist there is 'a problem'.

Authenticated denial of existence is a requirement in a lot of zones.
e.g. in the in-addr tree you would like to have authentication on the
fact that some delegations do not exist (allocations that have not
been made). A number of registries in the forward zones have strict
regulations on names that can be registered. For those registries
authenticated denial of existence of unregistered names may be a
requirement as well.

> The complexity introduced recently ("encapsulated NXT") is a non-issue. 

Ceci n'est pas un pipe.

> A NXT chain is a chain that covers all signed names in a zone, regardless of

One suggested clarification, so that it is clear we have a protocol error and
encapulated NXTs are forbidden.

   Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records
   and RFC 2535 NXT records.  At each secure node, the NXT record within
   that node MUST either be RFC 2535 or Opt-In compliant.  If it is not
   Opt-In, there MUST NOT be any insecure nodes between it and the next
   node.

Remove ambiguity from last line:

   If it is not Opt-In, there MUST NOT be any insecure nodes between
   it and the node indicated by the 'next domain name' in the NXT
   rdata.

And add:

   If it is OPT-IN, there MUST NOT be any signed nodes between it and
   the next node indicated by the 'next domain name' in the NXT rdata.

--Olaf

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 12 Apr 2002 07:36:51 -0700

> zones.

let's be clear.  it bagean as a hack to make a partially signed COM
zone smaller.  some folk are leery of the complexity and the change in
the signing model.  others like the change in signing granularity.  we
have on the table a compromise, to allow the change in granularity, but
restricted to delegation points.

> If you feel that you can not live with this compromise, then and
> only then, please explain why to the list.

randy

---

From: Derek Atkins <[email-masked]>
Date: 12 Apr 2002 10:49:31 -0400

> to know about opt-in is not to use it.

If this is the case, then why make it available to them?

My fear of opt-in is that it adds complexity to the protocol, it adds
complexity to the resolver, it adds complexity to the server, it adds
complexity to the administrator, and IMHO buys little.

I'm _NOT_ afraid of an administrator making a subzone and not signing
data within that subzone.  If an administrator REALLY REALLY REALLY
wants to keep some of their data unsigned, fine, but I don't want to
make it easy.  Opt-in certainly doesn't keep you from this loophole,
either, it just makes it easier for an administrator to shoot
themselves in the foot.

> distant future, we should wish to make DNSSEC mandatory, opt-in does

While I would _like_ to see all of DNS signed, I certainly don't
expect that will ever happen.  I certainly don't expect sexxxxx.com
to ever be signed.  (Perhaps I'm missing the market? ;)

I agree that opt-in helps .com and other large delegation-only zones.
I DO NOT agree that opt-in helps the average zone administrator, nor
do I believe that it SHOULD be available to the average user.

> DNSSEC poses, like record synthesis or wildcards.

I worked with Roy in Minneapolis to try to understand this problem,
and what I came away from this was it only really helps if you have
a zone with large number of subparts.  For example, if a domain
foo.com has entries like:

        a.b.c.d.foo.com.

then wildcards become an issue issue due to the lack of delegation
points.

I agree that synthesis is a problem, but I also feel synthesis is a
bad idea unless it is done by a "trusted" server.  If there is a TSIG
key between a resolver and its trusted nameserver, then that trusted
nameserver can perform the request, verification, and synthesis on
behalf of the resolver.  So I think that synthesis is a red herring.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Mark Kosters <[email-masked]>
Date: Fri, 12 Apr 2002 11:24:19 -0400

On Thu, Apr 11, 2002 at 05:16:00PM -0400, Edward Lewis wrote:
> But as we delve

I'm not sure what the real complexity is - perhaps you can give us some
technical details. IMHO, people seem to be getting wrapped around the axel 
over the difference of secured nodes (opt-in) vs secured zones (2535). As it 
has been said before the resolver is not zone-aware. Based off of this,
the resolver changes to BIND were not too complex. I think it took Nominum
one man month to do this with a developer who never had worked on the
BIND code base before.

Mark

-- 

Mark Kosters             [email-masked]       Verisign Applied Research

---

From: Mark Kosters <[email-masked]>
Date: Fri, 12 Apr 2002 13:05:43 -0400

> either, it just makes it easier for an administrator to shoot

I see this as a tools issue. If the tools are good, then the administrator
should not have a problem. With that in mind, I could imagine the same 
thing be said about dnssec in general if sigs and keys were to be calculated
by hand and placed in the zone with vi.
 
> to ever be signed.  (Perhaps I'm missing the market? ;)

I agree. 

> do I believe that it SHOULD be available to the average user.

Moral argument here that always seems to creep up.  On the flip side,
why can't an administrator have a choice of what they want to have
secured and not secured in-zone? 

Mark

--

---

From: Derek Atkins <[email-masked]>
Date: 12 Apr 2002 13:14:30 -0400

> secured and not secured in-zone? 

Contrary to popular belief, security is NOT a science; it is an art.
There is no magic security pixie dust that can be sprinkled on a
protocol to magically make it secure.  Security is also a very
pervasive thing -- the fingers of security get into EVERY part of a
system.  Process and Procedure are JUST as important to maintain a
secure system as cryptography.  In fact, I would argue that
cryptography is the LEAST important issue, and easiest one to solve.

The problem I see with this working group is that many people are
unwilling to accept process and procedural security requirements,
call them "moral arguments" and dismiss them out of hand.  Would
you also like to dismiss buffer overruns as not being important?
Clearly telling an implementor how to implement the protocol is
a moral argument, too!

-derek

---

From: Edward Lewis <[email-masked]>
Date: Fri, 12 Apr 2002 13:42:09 -0400

The complexity I'm sensing is the all the hub-bub trying to sort out the
NXT implications.  Perhaps it is the axel wrapping that's the problem, not
the code.