Subject: Re: Opt-in wg last call

From: Edward Lewis <[email-masked]>
Date: Mon, 8 Apr 2002 10:31:57 -0400

At 6:46 PM -0400 4/5/02, Daniel Massey wrote:
>is there a compelling reason to allow a SIG without a NXT?
>I don't see one...

Immaterial SIG resource records are (or were) a reason to allow SIGs to
exist without NXT.  There was a time when there was a desire to allow an
application to sign data, stick that SIG in DNS, and then have the
application's other end validate the data.  How the validating key was
distributed was not defined and might not have involved the KEY RR (hence
restricting KEY RR may not obviate this scenario).

As far as "compelling reason to allow" - there isn't any harm in a SIG
without NXT to the DNS protocol, so I wouldn't go about restricting it in
the specifications.  If the specifications restrict it, then you require
more code to be written.

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

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: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 9 Apr 2002 11:33:09 +0200

On Fri, 05 Apr 2002 17:46:36 -0500
Daniel Massey <[email-masked]> wrote:

> "Olaf M. Kolkman" wrote:
> > 
> > >
> > > Yes, either ALL RRsets at a particular name are signed, or NO 
> > > RRsets at a particular name are signed.
> > >
> > 
> > I am a still a little confused.
> >
> 
> I think part of the confusion is terminology.  

Correct, I was tought to think in 'zones'. Having to abandon that
concept takes a few days:-)

But the confusion also came from thinking about what could go wrong.

One of the things I considered is having secured records inside a
namespace that has been marked as verifiable unsecured by an opt-in
style NXT record (we call that opted-out for simplicity).

Based on the example of last week, I've added signed lambda an mu
inside an opt-out part of the zone.  What got me confused is that
there are now to NXT records saying something about the security
status of a zone and that introduces ambiguity. (Hence my poorly
phrased question on handing back the 'wrong' NXT record).

This (poorly configured) zone will only lead to problems if one caches
the security state of a zone in a similar way one caches the NXDOMAIN
state.  I do not know if caching verifyer implementations may/should
do that.

I am not trying to argue against opt-in, just go forward with the
thing. But we are about to sell bullets of new caliber and I am trying
to find out ways one can shoot oneself in the foot so that we can
provide the warning on the packs. 

--Olaf

 Example of 'wrong' mixing of opt-in and normal NXT records. 

$ORIGIN greek.
@       SOA
        SIG(SOA) greek. 1
        KEY 1
        SIG(KEY) greek. 1
        NXT alpha
        SIG(NXT) greek. 1

alpha   A 10.0.0.1
        SIG(A) greek. 1
        NXT-OPT omega.greek.                 (opt in style)
        SIG (NXT) greek. 1

lambda  A 10.0.0.4
        SIG(A) greek. 1
	NXT mu.greek.            
	SIG (NXT) greek. 1

mu	A 10.0.0.5
	SIG (A) greek. 1
	NXT omega.greek.
	SIG (NXT) greek. 1

omega A 10.0.0.6 
        SIG(A) greek. 1
	NXT greek.
	SIG (NXT) greek. 1

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

---

From: Derek Atkins <[email-masked]>
Date: 09 Apr 2002 11:21:06 -0400

>         NXT-OPT omega.greek.                 (opt in style)

With this zone data, an attacker do anything they wanted with responses
for lambda, mu, or anything else that exists between alpha and omega.
Even though lambda is signed, an attacker can still hand you bogus data
and supply the "alpha NXT-OPT omega" record to "prove" that their
response is ok.

Because lambda and mu are _not_ part of the NXT chain, they are
unverifiable by a resolver.  The only benefit you get from this is
that _iff_ there is no attacker, then a resolver can verify that
lambda and mu are correct.  But due to the NXT-OPT record at alpha,
the signatures at lambda and mu are almost useless, and the NXT
records are ABSOLUTELY useless.

This is some of the rope that I don't think we should be providing to
users.  The DNS is a critical infrastructure; without it the Internet
would fall apart (at least from the usability side -- who can remember
all those IP addresses? ;) The more rope you give users, the more
chance they have to screw up.  Sure, they are probably just screwing
themselves over, but still, why give them the chance?

-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: Olafur Gudmundsson <[email-masked]>
Date: Tue, 9 Apr 2002 15:19:59 -0400 (EDT)

> style NXT record (we call that opted-out for simplicity).

I agree we need a new terminology to describe DNSSEC zone with opt-in.
The indicator whether a zone is secure is the signing of the apex RRsets.

Here is my take on the types of zones we may end up with:
	Unsecure zone:
		zone apex is not signed.

	Fully secure zone:
		KEY set at apex
		apex is signed by a zone key
		all names are signed by a zone key and covered by NXT.

	Partially secure zone:
		KEY set at apex
		apex is signed by a zonekey
		one or more names are omitted from NXT chain and
			not signed by a zone key.

In addition the locally and globally secure definitions from RFC3090
apply. A zone is
	Globally [Glob|loc]ally secure:
		KEY set at apex
		apex is signed
		all names are signed by a zone key and covered by NXT
		there exists a chain of KEY and DS records to the root
			validating the zone KEY set.

If zone is not globally secure then it is locally secure.

Imaterial signatures do not affect the security status at all.

	Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 9 Apr 2002 15:19:59 -0400 (EDT)

Fully secure zone:
		KEY set at apex

	Partially secure zone:
		KEY set at apex

	Olafur

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 10 Apr 2002 09:21:36 +0200

Change of subject; this not to delay the last call. 

On 09 Apr 2002 11:21:06 -0400
Derek Atkins <[email-masked]> wrote:

> lambda and mu are correct.  

lambda and my are _not_ part of the NXT chain but the NXT chain is not
used for positive verification isn't it? In other words if lambda and mu
are signed by a key that is part of the chain of trust then they are
securely verified. The NXT can also be used for the denial of existence of
types. 

Maybe the rewrite of the DNSSEC spec should specifically state that these
'encapsulated' NXT records are not allowed.

--Olaf

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 10 Apr 2002 09:21:36 +0200

--Olaf

---

From: Derek Atkins <[email-masked]>
Date: 10 Apr 2002 11:24:37 -0400

> securely verified. The NXT can also be used for the denial of existence of

Of course it is used for positive verification.  It was created for
that purpose (read: authenticated denial).  That's the point of the
NXT chain.

In 2535 (with or without DS) a response from a 'secure zone' would
have _either_ a response with a SIG _or_ a NXT.  With opt-in, you
sort-of have the same issue, except you can supply other data with the
NXT.

In the example given there are two overlapping NXT records, the NXT
chain and the 'standalone NXT'.  This provides an attacker with data
to replace one for the other in certain circumstances.

The real answer is that no, you SHOULD NOT have signed data outside
the NXT chain (even with opt-in).

This also means that if you use opt-in then if you sign a new piece of
data there is a window of opportunity for an attacker to use this
attack until the old NXT/SIG expires.

> 'encapsulated' NXT records are not allowed.

Agreed.  I'd also say that these 'encapsulated' SIG records are not
allowed, either.

-derek

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 5 Apr 2002 09:50:42 +0200

> 
> Yes, either ALL RRsets at a particular name are signed, or NO RRsets at
> a particular name are signed.
> 

It occurs to me that the concept of experimentally secured zones stops
to exist with OPT-IN. From the client view there is no such thing as a
(experimentally) secure zone with OPT-IN. I have not yet assessed if
that is a 'Bad thing (TM)'.

The draft does not describe that this obsoletes (parts of) RFC3090.

While thinking about this I came up with the following questions.

Is one allowed to have SIGs with names that are part of the zone that
is marked as unsecure by OPT-IN? If so, does the presence of a SIG
require the presence of a NXT record with the same name?  e.g. in the
example below 'lambda' is opted-out but it does have a signature;
Should/must/may lambda also have a NXT record?

If it Should/must/may have a NXT record we are in for more questions;
how does the nameserver know which NXT to return?  Is there a problem
if thw wrong one is returned?  (Possibly not.)

If you allow SIGs without NXTs will that lead to problems? I do not
think so, but I might be wrong.

The use for having SIGs on names that are marked as insecure by
NXT-OPT would be similar to having experimentally signed zones. A
resolver with the locally configured key would still be able to check
the records while a resolver that follows a chain of trust will
consider the names insecure. 

$ORIGIN greek
@	SOA
	SIG(SOA) greek. 1
	KEY 1
	SIG(KEY) greek. 1
	NXT alpha
	SIG(NXT) greek. 1

alpha   A 10.0.0.1
	SIG(A) greek. 1

lambda  A 10.0.0.4
	SIG(A) greek. 1

omega   A 10.0.0.5
	SIG(A) greek. 1
	NXT greek.

--Olaf

PS. While going over RFC3090 again I couldn't help but smile: 
   The goal of DNSSEC is to have each zone secured, from the root zone
   and the top-level domains down the hierarchy to the leaf zones.

---

From: Randy Bush <[email-masked]>
Date: Fri, 05 Apr 2002 14:34:58 +0200

> It occurs to me that the concept of experimentally secured zones
> stops to exist with OPT-IN.

with opt-in, the concept of "secured zones" would no longer exist,
period.  zones could have a (possibly improper) subset (possibly)
secured.

randy

---

From: Roy Arends <[email-masked]>
Date: Fri, 5 Apr 2002 15:09:53 +0200 (CEST)

> The draft does not describe that this obsoletes (parts of) RFC3090.

Experimentally secured status is deprecated, i.e. there is 'No Such Thing
(TM)'

> Should/must/may lambda also have a NXT record?

Yes, it must have an associated NXT record.

> if thw wrong one is returned?  (Possibly not.)

Wrong one ? There is only one !

> think so, but I might be wrong.

Yes it would lead to problems. A secure resolver wants a conclusive signed
statement. If it does not exist, it expects a signed NXT. A NXDOMAIN with
no NXT info is simply marked as BAD.

> consider the names insecure.

experimentally secured is a case of "locally secured"

$ORIGIN greek
@       SOA
        SIG(SOA) greek. 1
        KEY 1
        SIG(KEY) greek. 1
        NXT alpha
        SIG(NXT) greek. 1

alpha   A 10.0.0.1
        SIG(A) greek. 1

lambda  A 10.0.0.4
        SIG(A) greek. 1

This is wrong. It is required that the existence of a Signed A record
and the SIG record is signalled in a NXT record.

roy

---

From: Daniel Massey <[email-masked]>
Date: Fri, 05 Apr 2002 17:46:36 -0500

> I am a still a little confused.

I think part of the confusion is terminology.  I agree with Randy 
that we need to drop the term "secure zone" with Opt-in.  Thinking
in terms of granularity, you can have:

1. Security is applied to the DNS and all records are signed
     nice idea but this is completely unrealistic

2. Security is applied to zones and all records in a zone are signed
     here it makes sense to talk about a secure vs. non-secure zone 

3. Security is applied to names and all RRsets at the name are signed
     here it makes sense to talk about a signed name, but it doesn't 
     really make sense to a talk about a secure zone.  if I chose to
     sign only www.nge.isi.edu and ftp.nge.isi.edu, is nge.isi.edu
     a secure zone?  I think the terminology just doesn't fit.  

4.  Security is applied to RRsets at name and all records in the 
    RRset is covered by the signature 
      this is possible, but no one is suggesting a level of 
      granularity below names.

5.  Security is applied to individual RRs. 
      no one is suggesting this and no one should suggest 4 or 5 :)   

So trying to answer your questions in terms of this "#3 - name based
granularity", I get the following answers:
 
> stops to exist with OPT-IN. From the client view there is no such 
> thing as a (experimentally) secure zone with OPT-IN. I have not 
>yet assessed if that is a 'Bad thing (TM)'.
> 

Experimentally secure zone is gone.  So is secure zone and unsecure 
zone. The granularity is secure names so implicitly anything "zone" 
is gone.     
 
> Is one allowed to have SIGs with names that are part of the zone 
> that is marked as unsecure by OPT-IN? 

Yes, the granularity is names.  You choose to sign or not sign any 
name.

> If so, does the presence of a SIG require the presence of a NXT 
> record with the same name?  <snip?
>

Yes.  Your level of granularity is names.  If you have a secure name, 
you MUST have a NXT stating the next secure name. 

> If it Should/must/may have a NXT record we are in for more 
> questions; how does the nameserver know which NXT to return?  Is 
> there a problem if thw wrong one is returned?  (Possibly not.)
>

For each name, there is only one next secure name so there is only
one NXT.  (there is some existing confusion with upper and lower 
NXT at a delegation  name but we already deal with that.) 

> think so, but I might be wrong.

I think it would be a problem.  If the granularity is names, a 
secure resolver needs to know what is the next secure name.  

> resolver with the locally configured key would still be able to 
> check the records while a resolver that follows a chain of trust 
> will consider the names insecure.
>

I never liked experimentally secure zones and experimentally secure 
names seem worse.   In terms of the granularity, it makes sense that 
NXT tells you the next secure name.  So if you want to sign a name, 
I think you MUST adjust your NXTs accordingly.  Or put another way,
is there a compelling reason to allow a SIG without a NXT?  
I don't see one...  

Dan