Subject: Redux: Why I want to remove the null key (SIG)

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Jun 2000 11:26:28 -0400

In a confernce call yesterday with members of ISC, we hit upon a situation
in which the current use of the NULL key is a bad idea.  (This is in light
of the Signing Autority draft.)

As the spec currently stands, a secured parent is not required to hold a
key for a secured child, but is required to hold a NULL key (signed by the
parent) for an unsecured child (that is not able to hold it's own NULL key).

The situation that has arisen in the implementation is this:

Given a secured parent zone and a delegated child zone that uses zone keys
which are validated off-tree (i.e., not by the parent) the following
happens:

In the parent zone:

         child    NS
         child    KEY  null
                  SIG  KEY ...
                  NXT
                  SIG  NXT

In the child zone:

         child    SOA
                  SIG  SOA
                  NS
                  SIG  NS
                  KEY
                  SIG  KEY (signed by Mars Certification Agency)
                  NXT
                  SIG  NXT

The problem that arises is the conflicting KEY sets, particularly when the
two zones share an authoritative name server.

This was legal under the policy in RFC 2535, section 6, but is not legal
given the updating draft.  According to 2535, the credibility of the
child's KEY would force a "hiding" of the parent's NULL key, and
certification chains would be formed to the certifying authority.  The
Signing Authority does not account for off-tree certification, not at least
until we understand it better.

This will be fused into the promised and oft delayed update to the Zone
Status Clarification draft.  I just figured I'd air this for comments now.

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

"It takes years of training to know when to do nothing" - Dogbert

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.

---

From: Bill Manning <[email-masked]>
Date: Mon, 12 Jun 100 05:46:04 -0700 (PDT)

% As the spec currently stands, a secured parent is not required to hold a
% key for a secured child, but is required to hold a NULL key (signed by the
% parent) for an unsecured child (that is not able to hold it's own NULL key).
% 

	How does the parent learn that the child isnow secure
	and is can drop the NULL key?

--bill

---

From: Bill Manning <[email-masked]>
Date: Mon, 12 Jun 100 05:42:38 -0700 (PDT)

% In case you are wondering - I don't think the addition of the
% aforementioned record is a foregone conclusion.  I am trying to identify
% ways that reduce the amount of information a parent must know and hold
% about a child.
% 

I'm coming to the conclusion that operationally we are faced w/ the following:

DNSsec
COTS (common, off the shelf) technology
large flat spaces

... pick two.

We can have DNSsec with COTS but then large flat name spaces become untenable.
We can have DNSsec w/ large flat spaces, but then have to have special hw
or we can have large flat spaces & COTS, giving up DNSsec.

-- 
--bill

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 12 Jun 2000 23:19:56 +0200

>         and is can drop the NULL key?

when it decides to sign the child's key, that seems an obvious conclusion 
to draw.
if it doesn't want to sign the child's key, why should it consider it 
secure, or ask anyone else to do that?

             Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Bill Manning <[email-masked]>
Date: Tue, 13 Jun 100 08:30:10 -0700 (PDT)

% 
% On Mon, 12 Jun 100, Bill Manning wrote:
% 
% > % As the spec currently stands, a secured parent is not required to hold a
% > % key for a secured child, but is required to hold a NULL key (signed by the
% > % parent) for an unsecured child (that is not able to hold it's own NULL key).
% > % 
% > 
% > 	How does the parent learn that the child isnow secure
% > 	and is can drop the NULL key?
% 
% The child asks the parent to remove the null-key, the parent can (should
% ?) verify the child's (null) KEY to make sure that the child has a valid
% (null) KEY.

	How does the child ask?

-- 
--bill

---

From: Roy Arends <[email-masked]>
Date: Tue, 13 Jun 2000 16:17:02 +0200 (CEST)

> 	and is can drop the NULL key?

The child asks the parent to remove the null-key, the parent can (should
?) verify the child's (null) KEY to make sure that the child has a valid
(null) KEY.

Removing the NULL-key at parent simply indicates that the child handles
their own keys. This implies that the child is responsible for it's own
security, and NOT that the child is secure.

-roy

---

From: Bill Manning <[email-masked]>
Date: Tue, 13 Jun 100 08:27:56 -0700 (PDT)

%     We can have DNSsec with COTS but then large flat name spaces
%     become untenable.  We can have DNSsec w/ large flat spaces,
%     but then have to have special hw or we can have large flat
%     spaces & COTS, giving up DNSsec.
% 
% 
% On what grounds do you come to this conclusion? Do you have any
% data to support this?
% 
% 	jaap

Ok, I'll admint some unlisted assumptions. 
	) zones should be signed in a timely manner e.g. less than 4hours
	) COTS technologies today are represented by 1 or 2 G of memory,
	  subGhz processors.
	) large flat name spaces have around 1 million entries

tests done in the US on some large zones (com.) and some tests done in 
Europe (de.) indicate that with current COTS and these zones, the time
test fails. 

-- 
--bill

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 13 Jun 2000 14:44:51 +0200

[Bill Manning]

    I'm coming to the conclusion that operationally we are faced
    w/ the following:
    
    DNSsec
    
    ... pick two.
    
    We can have DNSsec with COTS but then large flat name spaces
    become untenable.  We can have DNSsec w/ large flat spaces,
    but then have to have special hw or we can have large flat
    spaces & COTS, giving up DNSsec.

On what grounds do you come to this conclusion? Do you have any
data to support this?

	jaap

---

From: Bill Manning <[email-masked]>
Date: Tue, 13 Jun 100 08:17:15 -0700 (PDT)

% >% As the spec currently stands, a secured parent is not required to hold a
% >% key for a secured child, but is required to hold a NULL key (signed by the
% >% parent) for an unsecured child (that is not able to hold it's own NULL key).
% >         How does the parent learn that the child isnow secure
% >         and is can drop the NULL key?
% 
% when it decides to sign the child's key, that seems an obvious conclusion 
% to draw.
% if it doesn't want to sign the child's key, why should it consider it 
% secure, or ask anyone else to do that?

	How does the parent learn the child has a key that it should
	sign?

-- 
--bill

---

From: Roy Arends <[email-masked]>
Date: Wed, 14 Jun 2000 09:52:44 +0200 (CEST)

> % ?) verify the child's (null) KEY to make sure that the child has a valid

There is no security involved here as the parent can check the validity of
the request.

---

From: Roy Arends <[email-masked]>
Date: Wed, 14 Jun 2000 14:31:17 +0200 (CEST)

On Wed, 14 Jun 100, Bill Manning wrote:

> % > % > 	How does the parent learn that the child isnow secure
> % > % > 	and is can drop the NULL key?
> % > % 
> % > % The child asks the parent to remove the null-key, the parent can (should
> % > % ?) verify the child's (null) KEY to make sure that the child has a valid
> % > % (null) KEY.
> % > 
> % > 	How does the child ask?
> % 
> % There is no security involved here as the parent can check the validity of
> % the request.
> 
> What triggers the parent to check?  

The child's request ...

---

From: Bill Manning <[email-masked]>
Date: Wed, 14 Jun 100 05:27:55 -0700 (PDT)

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Wed, 14 Jun 100 05:41:34 -0700 (PDT)

%>%>% The child asks the parent to remove the null-key, the parent can (should
%>%>% ?) verify the child's (null) KEY to make sure that the child has a valid
%>%>% (null) KEY.
%>%> 	How does the child ask?
%>% There is no security involved here as the parent can check the validity of
%>% the request.
%> What triggers the parent to check?  
% The child's request ...

Again, How does the child ask the parent?  via some DNS protocol feature?
Registered postal mail?    

-- 
--bill

---

From: Roy Arends <[email-masked]>
Date: Wed, 14 Jun 2000 14:50:55 +0200 (CEST)

> Again, How does the child ask the parent?  via some DNS protocol feature?

Anyway the child desires and parent accepts. Not particular via some DNS
protocol feature. This can be done out of band.

Registered postal mail will do.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 14 Jun 2000 10:57:03 -0400

I've iidentified this as a remaining issue.  Since I'm
operationally-challenged (having no real network to run) I would like to
hear other opinions.

If you were to ask me my idea on this (or not ask) - some RPC-like / (I
hate to say it) Web-CGI-Applet interface where upon a client does:

   http(s)://www.WeSignKeys4You.sec/keysigningform.pl

The front end accepts keys and returns results.  The back end records the
action and sees to it that the result is reflected in the delegating zone.

Now, I've left out a heck of a lot of details (e.g., trans. sec.) and
options...

PS - Yeah, my scenario above assumes a largely delegated zone, yadda, yadda.

---

From: Bill Manning <[email-masked]>
Date: Wed, 14 Jun 100 11:04:34 -0700 (PDT)

Thanks. That the notification method is not specified should be made clear.

% 
% On Wed, 14 Jun 100, Bill Manning wrote:
% 
% > %>%>% The child asks the parent to remove the null-key, the parent can (should
% > %>%>% ?) verify the child's (null) KEY to make sure that the child has a valid
% > %>%>% (null) KEY.
% > %>%> 	How does the child ask?
% > %>% There is no security involved here as the parent can check the validity of
% > %>% the request.
% > %> What triggers the parent to check?  
% > % The child's request ...
% > 
% > Again, How does the child ask the parent?  via some DNS protocol feature?
% > Registered postal mail?    
% 
% Anyway the child desires and parent accepts. Not particular via some DNS
% protocol feature. This can be done out of band.
% 
% Registered postal mail will do.
% 
% 

-- 
--bill

---

From: Edward Lewis <[email-masked]>
Date: Fri, 23 Jun 2000 11:03:31 -0400

>Again, How does the child ask the parent?  via some DNS protocol feature?

With regards to getting a child key signed, recognized, and reflected in
the parent zone - is the onus on the child or parent to make sure things
are correct?

Would this answer change if we are talking .de or .com vs.
netsec.tislabs.com (i.e., a lower in the tree "small" delegation)?

---

From: Bill Manning <[email-masked]>
Date: Fri, 23 Jun 2000 21:56:14 -0700 (PDT)

% >Again, How does the child ask the parent?  via some DNS protocol feature?
% >Registered postal mail?
% 
% With regards to getting a child key signed, recognized, and reflected in
% the parent zone - is the onus on the child or parent to make sure things
% are correct?
% 
% Would this answer change if we are talking .de or .com vs.
% netsec.tislabs.com (i.e., a lower in the tree "small" delegation)?
% 
% -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
% Edward Lewis                                                NAI Labs
% Phone: +1 443-259-2352                      Email: [email-masked]
% 

See recent post on presumptions on zone state change wrt its being "secure".
I expect that zones like de. or com. will be be -very- busy dealing w/
the state change in their sub-delegations while netsec.tislabs.com. might
be lucky and have fewer and less volitile children.  
A good chunk of this comes from what peoples expectations are set to.

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Fri, 23 Jun 2000 21:40:16 -0700 (PDT)

Ed, Roy,
	One thing we have run into here is the trap of presuming that
once a zone is "secure" that it remains so. i.e. the transition from
non-secure to secure is one-way and occurs once.  I have come to
the realization that the security of the zone is time dependent and
it will flip between states on a regular basis over time. So the ability
to have the child inform the parent of its particular state at any
given time is important. This is easy, since there exists a well-known
and used method for doing this today.  The harder part is to have the
parent take appropriate, automated actions based on the state change,
e.g. signing the child keys and handing them back to the child.

% I've iidentified this as a remaining issue.  Since I'm
% operationally-challenged (having no real network to run) I would like to
% hear other opinions.
% 
% If you were to ask me my idea on this (or not ask) - some RPC-like / (I
% hate to say it) Web-CGI-Applet interface where upon a client does:
% 
%    http(s)://www.WeSignKeys4You.sec/keysigningform.pl
% 
% The front end accepts keys and returns results.  The back end records the
% action and sees to it that the result is reflected in the delegating zone.
% 
% Now, I've left out a heck of a lot of details (e.g., trans. sec.) and
% options...
% 
% PS - Yeah, my scenario above assumes a largely delegated zone, yadda, yadda.
% 
% At 8:50 AM -0400 6/14/00, Roy Arends wrote:
% >On Wed, 14 Jun 100, Bill Manning wrote:
% >> Again, How does the child ask the parent?  via some DNS protocol feature?
% >> Registered postal mail?
% >
% >Anyway the child desires and parent accepts. Not particular via some DNS
% >protocol feature. This can be done out of band.
% >
% >Registered postal mail will do.
% 
% 
% -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
% Edward Lewis                                                NAI Labs
% Phone: +1 443-259-2352                      Email: [email-masked]
% 
% "It takes years of training to know when to do nothing" - Dogbert
% 
% Opinions expressed are property of my evil twin, not my employer.
% 
% 
% 

-- 
--bill

---

From: Edward Lewis <[email-masked]>
Date: Sat, 24 Jun 2000 11:38:46 -0400

This is something I'm well aware of.  See detail below.  I'm glad to hear
real operations folks are concerned about this (well, not glad as in you
have a problem, but glad the issues have gained significance).

>e.g. signing the child keys and handing them back to the child.

Here's the kind of detail I've already thought over.

A child submits a set of (appropriate) keys for signing and requests that
the validity of the SIG record be the month of January.  The child then
sends another set for March (forgetting February).  Let's assume both
signing happen in December the year before.

So, is the parent going to say the child is secure in Jan and Mar, but not
Feb?  I mean, the spec calls for this, but will this happen in practice?
At issue is the policy a parent will have regarding the signing of keys for
children (must be for contiguous periods, etc.).

How will the parent "remember" what it has signed?  There isn't a data
structure or base in BIND that will manage this.  (Note, I am not asserting
that BIND is the only option for name servers, just that it is the most
prevalent.  I heartily endorse "competitors.")

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 24 Jun 2000 17:29:56 +0200

>netsec.tislabs.com (i.e., a lower in the tree "small" delegation)?

the *only* thing a signature proves is that a holder of the corresponding
private key signed the data.
At present, we generally assume that:
- only legitimate authorities for a zone hold the private keys involved
- they will only issue subzone key signatures when they believe that the
   child is secure.
If these assumptions hold, the SIG becomes a statement of belief by the
parent zone authorities.

How the child convinces the parent to hold that belief is not standardized.
In the .de case, the child and parent are different organizations; beliefs 
of one organization about another are generally based upon legally binding 
contracts.

In the case of netsec.tislabs.com, the usual reason for the zone owner to 
believe the child zone is secure is that he configured it himself, or that 
he knows and trusts the guy who did it.

The appropriate protocol for the two cases is probably different.

                  Harald

---

From: Roy Arends <[email-masked]>
Date: Mon, 26 Jun 2000 11:50:43 +0200 (CEST)

> the parent zone - is the onus on the child or parent to make sure things

Considering this child key is a real key (not a null key), this key will
probably never make it into the parent zone. The only thing that is
reflected in the parent zone is the absence of the null key. we think that
the onus is on the child. It has to make sure that it meets the demands of
the parent's policy.

> netsec.tislabs.com (i.e., a lower in the tree "small" delegation)?

No, probably not. If a child wants to be secured, it is dependant on the
parents policy.

Regards,

Roy

--
[email-masked]                NLnetLabs
tel +31208884551                Kruislaan 419
|\ ||   _  _|_  |   _ |_  _     1098 VA  Amsterdam
| \||__| )(-|_  |__(_||_)_)     The Netherlands