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

From: [email-masked]
Date: Thu, 19 Dec 2002 14:51:43 +1100

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/>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Thu, 19 Dec 2002 08:46:37 +0100

> 	There are multiple conflicting definitions of what a KSK is.

Ack, addressed. I will wait for other comments before pushing 05.txt.

--Olaf

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

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 19 Dec 2002 07:41:07 -0500

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

---

From: [email-masked]
Date: Fri, 20 Dec 2002 00:44:22 +1100

> resolver shouldn't care if the KSK bit is one and it is still used to sign

	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

---

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

> > >    for zone keys that are used to sign the KEY RRset only and are
intended
> > to

---

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

---

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
----- Original Message -----
From: "Olaf M. Kolkman" <[email-masked]>
To: "Scott Rose" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, December 19, 2002 10:04 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.
> > > > 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
> > > > resolver shouldn't care if the KSK bit is one and it is still used
to
> > sign
> > > > >    the keyset only.  In general, key-signing keys are the keys
that
> > are
> > > > >    sign the KEY RRset at the apex of a zone, zone- signing keys
sign
> > all
> > > > >    for zone keys that are used to sign the KEY RRset and are
intended

---

From: Randy Bush <[email-masked]>
Date: Thu, 19 Dec 2002 12:06:50 -0600

> which KEY RR held the KEY signing key.

exactly

> the flags and not assign any protocol value to it.

thank you

randy

---

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

---

From: [email-masked]
Date: Mon, 23 Dec 2002 08:45:40 +1100

> That key is both the KSK (needs DS) and ZSK.

	Then you don't set KSK in the first place or you tell the
	signer to ignore the KSK and use the key to sign all the
	data sets.

	A KSK key is by definition a KEY that *only* signs the zone
	key.

	There is no benefit in a KSK if a KSK signs the entire zone.
 
> and "confidentiality prohibited" goof ups.

	This a flag to tell the signer what to do.  It is NOT
	enforced by the resolver.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Dec 2002 09:08:02 -0500

>	There is no benefit in a KSK if a KSK signs the entire zone.

The topic here isn't a "KSK" but a "bit to indicate that this is 
intended to be a key-signing key."

I've not been persuaded to make a formal distinction between a ZSK 
and KSK within the protocol.  I have been persuaded to indicate the 
intent of the key manager to use a key as "one that is to be 
referenced by a DS RR."

 From discussions held over the past year, the sentiment has been that 
this bit is intended to help applications differentiate on key 
management and to help the manual process of key management.  The bit 
is not intended as a in-protocol policy tool.  I.e., as far as the 
in-band protocol is concerned, the distinction between KSK and ZSK is 
not made.

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 24 Dec 2002 14:27:38 +0100

* 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.)

Bind's dnssec-signzone now uses -k <KSKs> to indicate which keysigning
keys. I would love  to see the bit used so that  <KSKs> do not need to
be specified and  the -k flag (or whatever letter  you want to assign)
only is sufficient. As a result  of using the flag you would have your
pre-prepared   keysets,   epp  encapulation   or   registry  form   as
output... but that is up to the implementor and it's clients.

The draft does specifically say that the bit does NOT modify the
protocol and MUST NOT be used during verification.

 * In the key generator, the bit can be set.

That would be  handy :-).

--Olaf

---

From: "Scott Rose" <[email-masked]>
Date: Mon, 23 Dec 2002 09:12:58 -0500

<snip>
> There is no benefit in a KSK if a KSK signs the entire zone.

Correct, but if the admin is stupid enough to sign a zone with a KSK, and
not include a zone key (ie. the zone key has the KSK bit set).  The admin
shouldn't be punished.

After the signer is done - the KSK bit loses all meaning.  The resolver,
verifier and servers should not assigning any specially meaning to the KSK
on a KEY RR.

> enforced by the resolver.

Correct again.  This bit is signer-meaningful only.

Scott