Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt

From: "Scott Rose" <[email-masked]>
Date: Thu, 19 Dec 2002 09:30:33 -0500

I think we're in agreement here.  The KSK is for the admin and signer
software and not for the resolver or server.  The KSK has no protocol value,
only some operational value to help differentiate it from any ZSKs in the
zone.

Though technically, a key with the KSK bit set could be used as a ZSK, and
the only KEY in the zone.  It is silly to do that, but for the protocol, it
should be acceptable.  I don't think there should be language in the spec
saying that if a KEY RR has the KSK bit set, there MUST be another ZSK in
the zone.  It should only have a software/admin meaning, not a protocol
meaning.

The main thing I am against is assigning a more stringent (i.e. RFC2119)
meaning to the bit.
Scott

----- Original Message -----
From: <[email-masked]>
To: "Scott Rose" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 19, 2002 8:44 AM
Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt

>
> > If I remember the discussions that brought the KSK draft out:  It was
never
> > meant to be a protocol relevant bit, but a administrator/human readable
bit.
> > The problem found during the workshops was the inability to distinguish
> > between keys just by their fingerprint.  So a bit was proposed to
signify
> > which KEY RR held the KEY signing key.
> >
> > A conscious decision was made to make this a "human readable only" bit
in
> > the flags and not assign any protocol value to it.  It would have lead
to
> > more complexity for the resolver and the spec that is unnecessary.  Not
all
> > zones will have KEYs and KSKs and should not be made to have them.   A
> > resolver shouldn't care if the KSK bit is one and it is still used to
sign
> > the zone.
> >
> > Scott
>
> The resolver doesn't care.  The signer however does.  Signing
> the entire zone with a KSK defeats the purpose of having a
> KSK.  No one is saying that you have to have a KSK but if
> you have a KSK you need a ZSK (Zone Signing Key)
> key as well otherwise you have to sign the whole zone with
> a key that is tagged as KSK but is being used as a ZSK.
>
> You should be able to take a zone with multiple keys and
> just be able to sign it and have everything work.  By that
> I mean KSKs sign just the KEY RRset.  The ZSKs sign the
> entire zone including the KEY RRset.  If you don't have
> a KSK then the zone just gets signed with ZSKs
>
> The KSK flag can also be used to seperate out the KSKs,
> if there are both types of keys, to send to the parent
> otherwise it defaults to all the keys.  Note not all key
> may want to be sent at key rollover.
>
> The KSK flag is being used to identify a key that is being
> used to perform a certian role.  Both humans and software
> need to look at the flag.  While I can sign a zone with a
> non tagged KSK and a ZSK it's much easier and less error
> prone to just tag the key and let the software handle it.
>
> Mark
>
>
> > ----- Original Message -----
> > From: <[email-masked]>
> > To: <[email-masked]>
> > Sent: Wednesday, December 18, 2002 10:51 PM
> > Subject: Re: draft-ietf-dnsext-keyrr-key-signing-flag-04.txt
> >
> >
> > >
> > > There are multiple conflicting definitions of what a KSK is.
> > >
> > >    With the DS record [5] the concept of key-signing and zone-signing
> > >    keys has been introduced.  Key-signing keys are the keys that sign
> > >    the keyset only.  In general, key-signing keys are the keys that
are
> > >    pointed to by DS records and are the first keys to be used when
> > >    following a chain of trust into the zone.  The key-signing keys
only
> > >    sign the KEY RRset at the apex of a zone, zone- signing keys sign
all
> > >    other data in a zone.  We propose a flag to distinguish the key-
> > >    signing key from other keys in the KEY RR set during DNSSEC
> > >    operations.
> > >
> > >    By setting the KSK flag on a particular key, zone administrators
> > >    indicate that that key SHOULD be used as the secure entry point for
> > >    their zone.  Therefore zone administrators SHOULD set the bit only
> > >    for zone keys that are used to sign the KEY RRset and are intended
to
> > >    act as the first link in the chain of trust for their zone.
> > >
> > > The last sentence should be changed to:
> > >
> > > Therefore zone administrators SHOULD set the bit only
> > >    for zone keys that are used to sign the KEY RRset only and are
intended
> > to
> > >    act as the first link in the chain of trust for their zone.
> > >
> > > to bring the definitions into alignment.
> > >
> > > There should be a note that if KSK is set on a key that there
> > > MUST be other keys without KSK set to sign the rest of the zone's
> > > contents as KSK's are restricted to only signing the KEY RRset.
> > >
> > > Mark
> > > --
> > > Mark Andrews, Internet Software Consortium
> > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > PHONE: +61 2 9871 4742          INTERNET: [email-masked]
> > >
> > > --
> > > 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/>
> >
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Thu, 19 Dec 2002 16:04:13 +0100

Does this text address both your concern? It uses SHOULD instead of MUST. 

<section title="Operational Guidelines">

<t>
By setting the KSK flag on a particular key, zone administrators
indicate that that key SHOULD be used as the secure entry point for
their zone. Therefore zone administrators SHOULD set the bit only for
zone keys that are used to sign the KEY RR set only and are intended
to act as the first link in the chain of trust for their zone. If KSK
is set on any KEY in the apex KEY RR set, there SHOULD be other keys
without KSK set to sign the rest of the zone's contents as key signing
keys are restricted to only signing the KEY RR set.
</t>

--Olaf

On Thu, 19 Dec 2002 09:30:33 -0500

> > > > archive: <http://ops.ietf.org/lists/namedroppers/>

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

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 19 Dec 2002 12:36:06 -0500

This sounds like a good section to add.  I think it addresses the concerns
without calling for a spec change.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Fri, 20 Dec 2002 18:08:29 -0500

>	a key that is tagged as KSK but is being used as a ZSK.

Agggh NO!!!
Agggh NO!!!
Agggh NO!!!

(But I say it with love.)

In the verifier, the bit must be ignored.

In the signer, the bit must only be used to prepare the key for 
exposure to the parent for DS RR processing.  (Note: I do not mean 
the signer must use the bit to prepare the key for sending to the 
parent.  I mean that the signer, if the implementation chooses to do 
so at all, must *only* use the bit for that purpose.)

In the key generator, the bit can be set.

In "whatever-generates the DS RR from the KEY RR" may read the bit to 
determine that this is a key for which a DS is desired.

As for why "Agggh NO!!": what if the child zone has just one key? 
That key is both the KSK (needs DS) and ZSK.

Another reason to not do this: Please don't repeat the mistake of the 
A/C bits of the 2535 flags field - the "authentication prohibited" 
and "confidentiality prohibited" goof ups.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer