Subject: Keeping the KEY and SIG typecodes active

From: "Scott Rose" <[email-masked]>
Date: Tue, 17 Jun 2003 16:01:14 -0400

Not given a DNSSECbis Question number, as it isn't a DNSSEC question per se.
This came up at a meeting on Friday over wildcards, CNAME, and some corner
cases in DNSSEC at Olafur's house. The idea of removing the subtyping of
DNSKEY to be both zone keys and entity keys came up. The idea is to keep the
KEY RR for transaction authentication (entity keys) and DNSKEY for zone
keys.

Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction
authentication only.

With the typecode rollover of the KEY RR to the DNSKEY RR, we are left with
a three typecodes now retired. However, there is still a viable currently
deployed codebase and use for these record types.

The KEY RR would continue to be used for transaction authentication key
storage only (SIG(0) validating keys, TKEY operations). SIG would be used
only for SIG(0) operations. The only change that is necessary is that
servers/resolvers that use the new typecodes should recognize the old
typcodes in these functions.

The format of these records will remain largely unchanged from their current
specification. The KEY RR will be regarded as any other data RR with regards
to handling and placement in a zone. The definitions of the KEY RDATA fields
will be:

Flags: All flag bits are RESERVED and MUST be zero (especially bit 7, the
zone key bit). Changes to flag bit definition must be done by IETF
consensus.

Protocol field: MUST be 3 (old DNSSEC).

All other fields remain as they are described in RFC 2535 and subsequent
updates.

The SIG RR will remain as described in RFC's 2535, 2931 and 3008

Currently deployed code that recognizes and handles SIG(0)'s will be able to
function as before. New servers that see the new typecodes (DNSKEY, RRSIG,
etc) that choose to support SIG(0) MUST also be able to process the KEY and
SIG RRs during transaction authentication.

This will not go into the DNSSECbis specification drafts, as they deal with
transaction authentication, which is not one of the goals stated in the
DNSSEC specification. This will either be a new draft, or rolled into Sam
Weiler's typecode rollover draft.

--
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: Michael Richardson <[email-masked]>
Date: Tue, 17 Jun 2003 18:09:29 -0400

>>>>> "Scott" == Scott Rose <[email-masked]> writes:
    Scott> Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction
    Scott> authentication only.

    Scott> With the typecode rollover of the KEY RR to the DNSKEY RR, we are
    Scott> left with 
    Scott> a three typecodes now retired. However, there is still a viable
    Scott> currently 
    Scott> deployed codebase and use for these record types.

  Yes, please don't make DHCPD, etc. change.
  This is a sensible proposal.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Sam Weiler <[email-masked]>
Date: Tue, 17 Jun 2003 18:32:35 -0400 (EDT)

> Topic: Keeping the KEY (typcode 24) and SIG (25) for transaction

draft-ietf-dnsext-dnssec-2535typecode-change-02.txt (which finally
cleared the i-d editor queue late this afternoon after being sent in
on Thursday morning) keeps SIG for SIG(0), but still deprecates KEY.
I'd appreciate it if folks would review the new sections of the draft
-- there's a change list at the top of the document.

Keeping KEY worries me a bit more, since it will appear in-zone and
some 2535-aware things pay attention to it.  Must we really keep it?
Do any of the SIG(0) _clients_ actually look at KEYs?

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 18 Jun 2003 08:49:28 -0400

As long as the KEY RR does not have the zone key flag bit set, it should be
alright.  However, the KEY will be signed by a RRSIG in the zone, which
would cause old (RFC2535) validators to consider it unsigned.

As for SIG(0) clients, if they don't now, that doesn't mean they won't
later, especially since that was the idea of SIG(0).

Scott

---

From: Sam Weiler <[email-masked]>
Date: Wed, 18 Jun 2003 15:50:14 -0400 (EDT)

> Do any of the SIG(0) _clients_ actually look at KEYs?

In thinking about this more: if a zone includes KEY RRs,

    1) there should be no bad interactions with DS-aware (and
       DNSKEY-aware) code.  DS-aware code should do the right thing
       with KEYs.

    2) if there are bad interactions with 2535-aware code, then
       those interactions are already out there -- this draft isn't
       causing them.  And if things need to be fixed later, then they
       can be fixed later.

So I see no new harm in leaving KEY for SIG(0) use.  Absent further
commentary, -03 will retain KEY for SIG(0) use only.

-- Sam

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 19 Jun 2003 07:35:21 -0400

One thing I am unsure of:

Is there a widely deployed base of DS-aware resolvers out there now that
won't update with the typecode rollover?  I ask this because if a DS-aware
resolver/recursive server sees a DS, it will know to look for a KEY RR in
the child zone, and not a DNSKEY RR.

I don't think this will be a big problem at all, but thinking "that'll never
happen!"  usually comes right before the buglike alien starts chewing the
space crew...

Scott

---

From: Sam Weiler <[email-masked]>
Date: Thu, 19 Jun 2003 07:55:39 -0400 (EDT)

> the child zone, and not a DNSKEY RR.

As far as I know, no.  Besides, if there were, the problem would
probably not appear at a delegation; it would appear at a secure entry
point.  ("Hey -- I have a trusted key configured for .com and the zone
doesn't have an apex KEYset.  Or SIGs.  Maybe I should SERVFAIL now.")

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Thu, 19 Jun 2003 09:57:01 -0400

At 7:35 -0400 6/19/03, Scott Rose wrote:
>won't update with the typecode rollover?

The only versions of BIND that support DS have been snapshots.  I've 
not seen any other code (non-BIND) made public that did DS.

(Anyone who uses a snapshot version of BIND in production is likely 
to buy expired milk products on a regular basis.)

>happen!"  usually comes right before the buglike alien starts chewing the

That's it, no more MST3000 episodes for you until the Vienna meetings.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

...as graceful as a blindfolded bull in a china shop...