Subject: Re: Transition from 2535 to opt-in

From: [email-masked] (Ted Lindgreen)
Date: Wed, 5 Dec 2001 11:50:53 +0100

[Quoting Paul A Vixie, on Nov 30, 21:33, in "Re: Transition from  ..."]
> i keep looking at opt-in and DS and asking "how many more years will it take
> before we get the complexity managed in dnssec and have widely deployed it?"

Hi,

There are two issues here on which timely deployment, or
deployment ever depends, first the conclusions:

DS: we need it.
OptIn: if OptIn, why not just forget NXT?

Let me explain:

- DS:
      There is a real issue with the parent-child communication
      in 2535, which must be resolved, before TLDs can deploy it.
      Result: no solution no deployment.
      On the other hand, there are quite a number of (TLD-)people
      that are both ready and anxious to start deploying DNSSEC,
      but just waiting for DS (or any other solution to deal with
      the parental SIG over the childs KEY) to be accepted.

- Opt-In:
      Opt-In will help superlarge TLDs, but IMHO it also changes
      the basic idea of DNSSEC from:
       "securing the DNS infrastructure"
      into:
       "securing small parts of the tree or even single RRsets"
      From recent discussions, I have learned that many people
      think that doing that is reasonable (although I personally
      do not agree), because:
      1. the DNS infrastructure is not that vulnarable anymore;
      2. only few people believe full DNSSEC will ever be deployed;
      3. there is real value in securing only the RRsets that
	 matter (KEYs, APPKEYs, CERT, www.bank.tld, etc.);
      so, secure only what needs to be secured, and forget the rest.

      My personal conclusion from this line of thinking is:
      If ("IF") we go for Opt-In, then go for it all the way, and
      just forget authenticated denial. This will really make
      implementation and deployment much simpler, and thus speed
      it up.

Regards,
-- ted

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Dec 2001 09:24:38 -0500

>OptIn: if OptIn, why not just forget NXT?

The question of whether "authenticated denial is desired" has been answered
"yes" a number of times over the past year or so  The question has been
raised by the WG chair on the list and in person at London.  So it appears
that there is a desire to provide the service.  (Why?  I don't know.)

Opt-In allows those who want authenticated denial to have that service.
Because opt-in has a means to indicate when it is in use, there is no
ambiguity on the part of the resolver when it comes to understanding the
situation.  Signalling opt-in is done by the lack of the NXT bit in the NXT
RRDATA's type bitmap.  I think this is a solid but expensive way to
indicate the status.

Solid in terms of its indication - there is only one bit involved to
comunicate yes/no, so there is no conflict possible in the resolver's
processing.  Unlike trying to tag the zone key set to indicate the way a
zone operates, which means multiple bits indicating a yes/no status, this
indication leave no room for ambiguity.

Expensive in that this mechanism can only be done once.  If we use the NXT
bit in the bitmap for this purpose, it can't be done again.

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

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

---

From: Daniel Massey <[email-masked]>
Date: Wed, 05 Dec 2001 09:42:57 -0500

>       in 2535, which must be resolved, before TLDs can deploy it.

Ted is exactly right.  We need DS to make wide scale deployment  
feasible. The only thing I would add is that the need for DS is not 
just limited to just TLDs.  Based on our test deployment and related 
work we have been doing, DS is essential for anyone that has to deal 
with multiple organizations (i.e. anyone with one or more child zones 
that are run by someone other than you).    

Dan

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 05 Dec 2001 09:36:56 -0800

>       1. the DNS infrastructure is not that vulnarable anymore;

i challenge this.  the dns infrastructure is as vulnerable as it ever was.
in bind8/contrib we ship several "contributed" spoofage tools that work just
as well now as the day they were written, and are not BIND specific at all.

>       2. only few people believe full DNSSEC will ever be deployed;

opt-in doesn't change this.  right now we need to get "." signed and then any
subdomain who publishes a key can be signed and so on.  "opt-in" is for
partial signing of large zones -- only those who have published keys.  what
we need to do is sign the whole thing, including keys when present.  opt-in
is a crutch for COM, which is "hard" to sign.

>       so, secure only what needs to be secured, and forget the rest.

i challenge this.  SSL is non-universal and even so depends on trusting small
numbers of signing authorities.  DNS is universal and depends only on getting
one's key signed by the parent domain's administrator, of whom there can be an
unlimited number (though only one per domain).  

we need universal capability for certainty across all RR types.  things like
A and PTR are no less authenticity-critical than KEY and CERT and so on.

>       implementation and deployment much simpler, and thus speed

my own conclusion from this is that since arguments for authenticated denial
were made years ago and are still quite compelling, there's no reason to do
opt-in except as a crutch for COM.

---

From: Mike Schiraldi <[email-masked]>
Date: Wed, 5 Dec 2001 14:18:44 -0500

>       implementation and deployment much simpler, and thus speed

Without NXT records and authenticated denial, there is no security. Imagine
the following subset of the COM zone, in an Opt-In world:

; foo1.com is secure
foo1.com  NXT foo3.com NS SIG KEY
foo1.com  NS  ns.foo.net
foo1.com  KEY ...
foo1.com  SIG KEY ...
foo1.com  SIG NXT ...

; foo2.com is not secure
foo2.com  NS  ns.xyz.net

; foo3.com is secure
foo3.com  NXT foo4.com NS SIG KEY
foo3.com  NS  ns.abc.net
foo3.com  KEY ...
foo3.com  SIG KEY ...
foo3.com  SIG NXT ...

Let's say you do a query for www.foo3.com, and your ISP wants to hijack the
query and make it appear that foo3.com is not secure and has a nameserver of
ns.yourisp.nl.

Without NXT records, it can formulate a response like

FOO3.COM.      NS  NS.YOURISP.NL
NS.YOURISP.NL  A   1.2.3.4

But with NXT records, that doesn't work. As shown in the example section of
the Opt-In draft, a response for an insecure domain would have to include a
NXT record showing it was not secure. In other words, it would have to look
something like:

FOO3.COM.      NS  NS.YOURISP.NL
NS.YOURISP.NL  A   1.2.3.4
FOO1.COM.      NXT FOO4.COM. NS SIG KEY ; this record proves that there is
                                        ; no secure domain between foo1
                                        ; and foo4; in other words, it 
                                        ; shows that foo3 is not secure
FOO1.COM.      SIG NXT ...
; [some other RRs omitted for simplicity]

And your ISP can't do this, because it can't create the SIG record.

-- 
Mike Schiraldi
VeriSign Applied Research

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 05 Dec 2001 12:34:50 -0800

> bit in the bitmap for this purpose, it can't be done again.

sure it can.  we can continue discussing the whichness of what in our ivory
tower for another five years (it's already been five years; what's five more?)
three years from now we'll have opt-maybe, opt-in, opt-out, and who knows what
else.

---

From: Derek Atkins <[email-masked]>
Date: 05 Dec 2001 20:33:05 -0500

Paul A Vixie <[email-masked]> writes:

> i challenge this.  SSL is non-universal and even so depends on
> trusting small numbers of signing authorities.  DNS is universal and
> depends only on getting one's key signed by the parent domain's
> administrator, of whom there can be an unlimited number (though only
> one per domain).

It's even worse that you say, Paul...  First, SSL only protects
TCP-based protocols.  That limits it to a subset of existing protocols
(a rather large subset, mind you, but a subset nonetheless).  Second,
using SSL doesn't help you at all when you try to use DNS indirection
pointers (CNAME, SRV, AFSDB, etc.)  Only 2535+ DNSSec can protect
blind[1] DNS "delegations" in this manner.

-derek

[1] by "blind" I mean that the end-host doesn't know about all the
potential delegations that may point to it.  In the SSL sense, what
this means is that I may have a CNAME from hostX.foo.com pointing to
hostY.bar.net; for SSL to work, hostY would need to have a certificate
for "hostX.foo.com" whereas with DNSSec it would not need to know
about this delegation.

-- 
       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: Olaf Kolkman <[email-masked]>
Date: Thu, 06 Dec 2001 10:57:46 +0100

Ed wrote:
 * The question of whether "authenticated denial is desired" has been answered
 * "yes" a number of times over the past year or so  The question has been
 * raised by the WG chair on the list and in person at London.  So it appears
 * that there is a desire to provide the service.  (Why?  I don't know.)
 * 
 * Opt-In allows those who want authenticated denial to have that service.
 *
 * (... technical bit skipped ...)

To me this is almost a paradox :-) 

I am still trying to get to a opinion about opt-in. A few thoughts on
the subject;

If you say "Opt-In allows those who want authenticated denial to have
that service" you only refer to the "server" side of the problem. As a
client or as a user of the system I have little choice.

If opt-in is adapted the zone owner will decide to which granularity
authenticated denial of existence is in place:
  - In a verifiable insecure zone  there is no such thing as authenticated
    denial.
  - In a RFC2535 zone authenticated denial is available for all records 
    in the zone.
  - In an OPT-IN zone the authenticated denial is granular.

IMHO DNSSEC can only be a success if it is widely deployed over the
DNS tree and it easy for end users to understand they are in a secure
zone or not. Adding granularity makes understanding the security in
the tree much harder for end users (i.e. troubleshooting sysadmins). I
am concerned about OPT-IN becoming a widely deployed mechanism because
it adds complexity to the secure DNS tree that is expensive for the
end-user. In other words, I understand that opt-in allows for
reasonable (and billable) costs on the server side. I am worried about
the costs of opt-in on the client side prohibiting deployment.

AFAIK .com is one of the few (and maybe the only) zone(s) that has
scaling problems when using a non granular (rfc2535) approach. What I
understand from the NLnet Labs folk is that it is technically possible
to sign and serve relatively big TLDs such as .de (on a desktop PC)
and even .com (on a $5000 alpha).

Since I think the opt-in is only useful for HUGE delegation zones I
would like the to see the last line of the security section changed
from:

"Thus, it is recommended to use RFC 2535 [4] where possible and to use
Opt-In where necessary."

into:
"opt-in increases the complexity of the secure DNS tree, therefore
it's use should be very carefully considered. RFC 2535 NXT records
SHOULD be used in almost all zones. The use of opt-in SHOULD only be
considered in zones that mainly consist of delegation records and for
which inclusion of NXT for the whole zone is prohibitively
expensive."

--Olaf 

PS. One technical argument for authenticated denial of existence is a
counter measure against DOS attacks; I query for a RR in a secured
domain and I get a NXDOMAIN or NOANSWER back from a man in the
middle. Without authenticated denial of existence I will be lost.