Subject: Re: Opt-in wg last call

From: Mats Dufberg <[email-masked]>
Date: Wed, 3 Apr 2002 13:12:33 +0200 (CEST)

On Apr 3, 2002, 11:25 (+0200) Olaf M. Kolkman <[email-masked]> wrote:

> I'm afraid I have been one of the persons voicing "moral"
> objections. I will not repeat them here. But I still would like to see
> the strongest possible recommendation not to use opt-in and sign zones
> completely.

I agree that we should recommend signing of all data.

> That goes for me too. We should move forward. I would like to have
> DNSSEC in production by the end of the year :-).

Yes, I'd like to see DNSsec used and recommended for ENUM.

Mats

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

--
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: Wed, 3 Apr 2002 08:21:45 -0500

During the IETF meetings, I was told about "typo" attacks being a threat.
I'm not sure I've seen them in a message yet though.  If you know what
these attacks are, the only benefit to reading the rest of this is to make
sure I've stated the problem accurately.

Before I describe them, my stance is that opt-in makes sense from the point
of view that it makes transitioning from insecure to secure more natural.
Mind you, this is just a "warm and fuzzy" feeling, there isn't a real
technical reason for this.

The typo attacks consist of someone taking advantage of "similar" names.
E.g., If I want to serve monopoly.int and there is a common mispelling of
m0n0p0ly.int, someone else could register that name and take advantage of
client mistakes.

If the alternate spelling is registered and evil is afoot, then there will
be authorities available to deal with the evil doer.  To find the evil
doer, one begins with the registration.

If opt-in is in use, then there may be no registration, one less means by
which to locate the evil doer.

What makes this troublesome is that the victim, in this case monopoly.int,
is at risk becuase of a policy decision made by some one else (.int).  It
is not a matter of .int shooting themselves in tht foot, but .int shooting
one of the legitmate delegations in the leg.

So, it seems that opt-in allows one organization to put another at risk.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Thu, 11 Apr 2002 16:09:54 -0400

Rob Austein wrote:
> 
> Do we have a worked example of opt-in applied to a zone that's more
> than one label deep?  This seems like the place where weakening of the
> "secure zone" model is most likely to make life confusing for the
> resolver.
> 
> Apologies if this has already been discussed and I missed it, but I
> saw no such example on a quick re-read of the draft.
> 

We just encountered a similar thing in our work and I was scanning
for answers, but didn't see anything posted to the list....

In particular, we're looking at what happens if a resolver gets:

   www.foo.bar.nge.isi.edu A 1.2.3.4 
   a.nge.isi.edu NXT c.nge.isi.edu
   SIG(NXT) by nge.isi.edu.

I don't think this is a possible response under regular NXT
or Opt-In delegation only.  But with unrestricted Opt-In, the 
following nge.isi.edu zone file would produce that response:
   <snip>
   a.nge.isi.edu. A ..., SIG, NXT-OPT c.nge.isi.edu, SIG(NXT-OPT)
   www.foo.bar.nge.isi.edu. A
   d.nge.isi.edu. A ..., SIG, NXT-OPT ..., SIG(NXT-OPT)
   <snip>

My question is whether this is a bad thing??  In the example,
the resolver can not distinguish between the case where 
 1) www.foo.bar.nge.isi.edu is in the nge.isi.edu zone file
and the case where 
 2) nge.isi.edu zone file has an NS record for bar.nge.isi.edu but 
    this child did not list a DS record.

In the first case, the NXT applies to nge.isi.edu's authoritative
data and says nge chose not to sign this name.  In the second case, 
the NXT from nge.isi.edu just proves some the child zone is not 
providing a DS record.  

But in both cases, no chain of trust leads from nge.isi.edu to 
www.foo.bar.nge.isi.edu so should I care if it case 1 or case 2?  
 
Dan

---

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

> www.foo.bar.nge.isi.edu so should I care if it case 1 or case 2?

I do not think you should care. In both cases the name
www.foo.bar.nge.isi.edu is unsigned, and unsecured. In regular DNS you do
not care which zone www.foo.bar.nge.isi.edu belongs to, you just use its
data.  Data from a node to which we have no chain of trust (and no broken
ditto) should be taken as regular DNS.

Mats

---

From: David Blacka <[email-masked]>
Date: Thu, 11 Apr 2002 17:41:54 -0400

[ post by non-subscriber ]

>>>>> "Daniel" == Daniel Massey <[email-masked]> writes:

 Daniel> In particular, we're looking at what happens if a resolver gets:

 Daniel> www.foo.bar.nge.isi.edu A 1.2.3.4 
 Daniel> a.nge.isi.edu NXT c.nge.isi.edu
 Daniel> SIG(NXT) by nge.isi.edu.

This response looks totally fine to a opt-in aware verifier: the NXT
record proves that www.foo.bar.nge.isi.edu is not supposed to be
signed, and it isn't.  It doesn't matter that "www", "foo", or "bar"
are or are not delegation points.

<snip>

 Daniel> In the first case, the NXT applies to nge.isi.edu's
 Daniel> authoritative data and says nge chose not to sign this name.
 Daniel> In the second case, the NXT from nge.isi.edu just proves some
 Daniel> the child zone is not providing a DS record.

 Daniel> But in both cases, no chain of trust leads from nge.isi.edu
 Daniel> to www.foo.bar.nge.isi.edu so should I care if it case 1 or
 Daniel> case 2?

No.

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

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Mon, 15 Apr 2002 10:59:04 -0400

>saw no such example on a quick re-read of the draft.

Great question Rob, this has not been discussed before.

After thinking about this, I have convinced myself that there is an
additional problem with opt-in and multi label names.
In general with Opt-in attacker can for unsecured name
         deny existence
         invent new name
         invent new RR
         change RR on the fly.

This is acceptable risk those that deploy Opt-in for as the secure names
can not be attacked.

In multi label names zones in the following case (only relevant names and 
types shown)
example  SOA
           SIG (SOA)
           NXT b.example ...

b.example  NXT f.e.d.c.example.

c.example.      A ...
d.c.example.   TXT ...

f.e.d.c.example A ....
                 SIG(A)

Now an attacker can invent a delegation for any label on the way to
f.e.d.c.example and answer with bogus data.

I think this can be addressed by requiring that c.example must exist
and be secured otherwise it is to hard for the resolver to find
the correct NXT record that proves that f.e.d.c.example.
is the next secured name.

         Olafur

---

From: Daniel Massey <[email-masked]>
Date: Mon, 15 Apr 2002 12:48:51 -0400

> f.e.d.c.example and answer with bogus data.

Yes, at a minimum this is going to add some complexity to the
resolver.      

> is the next secured name.

I'm not sure this fixes it....  would you allow the following:

    b.example.  NXT c.example.
    c.example.  A, SIG(A), NXT f.e.d.c.example, SIG(NXT)
    d.c.example.  TXT ...
f.e.d.c.example  A, SIG(A), NXT ..., SIG(NXT)

In this case, won't you have a still have a problem with an 
attacker inventing a delegation for d.c.example (or other labels 
on the way)?  

If I understand the fix, you change the opt-in NXT from:
   b.example. NXT f.e.d.c.example 
to
   c.example. NXT f.e.d.c.example

I'm not seeing how the complexity of the resolver gets 
improved...  

Dan

---

From: [email-masked]
Date: Tue, 16 Apr 2002 15:40:11 +1000

> But perhaps the lack of a delegation is implied by the next 
> signed name.  Suppose you have:
> 
>   anything.example NXT f.e.d.c.example.
> 
> Is it correct to say this proves there is no delegation 
> to c.example, d.c.example, and e.d.c.example?

	Yes.
 
> Reasoning:  if there was a delegation to any of the
> above, then the signed f.e.d.c.example record should
> not be in the example.com zone and should not be pointed
> to be the NXT in example.com.   

	Correct.

> I'm not sure this is right, but if it is right then you
> should be able to construct resolver rules that work.
> The drawback is make the resolver code looks more complex...
> 
> Dan
> 
> --
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Wed, 3 Apr 2002 21:05:40 +0200 (CEST)

On Wed, 3 Apr 2002, Olaf M. Kolkman wrote:

> Detail: It has been mentioned that we loose the concept of secured
> zones for the resolvers , I do not think that is true. Although the
> user's application is only interested in a name with associated data
> the resolvers will need to maintain state as to a zone is secured or
> not.  If the SOA is signed then names in that zone are either signed
> or opted-out.

No.

A domain indicates that a subdomain is considered signed (DS/KEY). A
preconfigured key (in the resolver) indicates a domain is considered
signed. Resolver considers world under a domain secured until a
"no-ds/key" or an opt-in NXT record states otherwise.

SOA has no involvement in indicating something is secured or not.

Roy

---

From: David Blacka <[email-masked]>
Date: Tue, 16 Apr 2002 16:52:28 -0400

>>>>> "ogud" == lafur Guðmundsson <lafur> writes:

 >> saw no such example on a quick re-read of the draft.

 ogud> Great question Rob, this has not been discussed before.

 ogud> After thinking about this, I have convinced myself that there is an
 ogud> additional problem with opt-in and multi label names.

 ogud> In general with Opt-in attacker can for unsecured name
 ogud> deny existence
 ogud> invent new name
 ogud> invent new RR
 ogud> change RR on the fly.

 ogud> This is acceptable risk those that deploy Opt-in for as the
 ogud> secure names can not be attacked.

 ogud> In multi label names zones in the following case (only relevant names
 ogud> and types shown)
 
 ogud> example.       SOA
 ogud>                SIG (SOA)
 ogud>                NXT b.example ...

 ogud> b.example      NXT f.e.d.c.example. (opt-in)

 ogud> c.example.     A ...
 ogud> d.c.example.   TXT ...

 ogud> f.e.d.c.example. A ....
 ogud>                  SIG(A)

 ogud> Now an attacker can invent a delegation for any label on the
 ogud> way to f.e.d.c.example and answer with bogus data.

But a dnssec-aware resolver would know that this information is bogus,
ultimately.

Let's look at the "normal" query chain, starting at our fictionally
secured root:

  root:
  Q: 
     f.e.c.example. A
  A:
     ANS
     AUTH
        example. NS blah1
        example. NS blah2
        example. DS <stuff>
        example. SIG(DS) <stuff>
     ADD
         blah1 A <ip>
         blah2 A <ip>

So, we can cryptographically verify that example. is secure
(partially, whatever).

  example:
  Q:
     f.e.c.example. A
  A:
     ANS
        f.e.c.example. A <ip>
        f.e.c.example. SIG(A) <stuff>
     AUTH
        example. NS blah1
        example. NS blah2
        example. SIG(NS) <stuff>
     ADD
        example KEY ...
        example SIG(KEY) ...
        ...

So, we can cryptographically verify that f.e.c.example A is a valid
record.

But, some one has forged a bogus delegation at e.c.example, so instead
of the normal answer, we get this:

  example:
  Q:
     f.e.c.example. A
  A:
     ANS
     AUTH
        e.c.example NS bogus1
        b.example. NXT f.e.c.example (opt-in)
        b.example  SIG(NXT) ...
     ADD
       bogus1 A ...
       example. KEY
       example. SIG(KEY)...

The NXT RRset may or may not be a part of the answer.

The resolver now knows that this is bogus because AT EVERY STEP there
MUST be either: (1) a signed RRset (DS, or the answer), or (2) A
signed NXT proving either that the RRset doesn't exist (non-opt-in case),
or the name is not secure (opt-in case).

Since the attacker cannot create valid NXT records, he can only reuse
the ones that exist (namely, b.example. NXT f.e.c.example.).  This NXT
record will not validate.

Actually, a particularly astute resolver might be able to determine
that "e.c.example NS" should actually not exist at all.  But this is
probably above and beyond the call of duty for a verifier.

 ogud> I think this can be addressed by requiring that c.example must
 ogud> exist and be secured otherwise it is to hard for the resolver
 ogud> to find the correct NXT record that proves that
 ogud> f.e.d.c.example.  is the next secured name.

How so?  If a resolver queries the example nameserver for c.example,
or e.d.c.example, it will get back the correct NXT record.  If an
attacker is in a postion to remove this record from the response, then
the attacker can make anything in example disappear, regardless of
opt-in.

---

From: Randy Bush <[email-masked]>, Olafur Gudmundsson <[email-masked]>
Date: Wed, 17 Apr 2002 12:29:51 +0900

there are folk who can not live with unrestricted opt-in, and folk
who can not live without opt-in for at least delegation points.
after much discussion and struggle, it seems the closest we can get
to consensus is a compromise with which few if any can not live,
opt-in restricted to delegation points.

like ds, opt-in requires a flag day.  hence, many moons ago, the wg
decided that, if opt-in is to be done at all, it should be done
with ds.  as ds is cooked, the clock is ticking.

the wg chairs, after consultation with the area directors, believe
that opt-in restricted to delegations is as close as this wg can
get to a consensus this year.  hence we propose to move forward on
this basis.

but the document is first going to need updating, for the un-cut
sub-domain issue and maybe others.

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 03 Apr 2002 14:59:35 -0500

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 4 Apr 2002 09:09:17 +0200

On Wed, 3 Apr 2002 21:05:40 +0200 (CEST)

> "no-ds/key" or an opt-in NXT record states otherwise.

Correct... I was confused, others might think I was on drugs. :-)

Time to implement a verifier... that will teach me.

--Olaf

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