Subject: DNSEXT WGLC: Key-Signing Key (KSK) Flag

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 12 Mar 2003 22:59:30 -0500

This starts a 2 week Working Group last call on this document,
concluding on March 28'th 2003.

This document defines a new KEY RR flag that is used to identify keys that
are used to sign KEY RRset. The flag is not used by the DNSSEC resolution
process. The main purpose of this flag is to ease administration of DNSSEC
signed zones.

This document is on standards track and is available via following URL:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag-06.txt

Silence on this document during the last call will interpreted by chairs
as instruction to drop this document.

	Olafur

--
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: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 06:10:51 +0000

> process. The main purpose of this flag is to ease administration of DNSSEC

i support this.

---

From: Roy Arends <[email-masked]>
Date: Thu, 13 Mar 2003 13:08:17 +0100 (CET)

> as instruction to drop this document.

I support this draft

Roy

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 13 Mar 2003 08:02:53 -0500

I support this document.

Scott

----- Original Message -----
From: "Ólafur Gudmundsson/DNSEXT co-chair" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 12, 2003 10:59 PM
Subject: DNSEXT WGLC: Key-Signing Key (KSK) Flag

> This document is on standards track and is available via following URL:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-keyrr-key-signing-flag
-06.txt

---

From: Matt Larson <[email-masked]>
Date: Thu, 13 Mar 2003 07:49:56 -0500

I support this document.

Matt

---

From: [email-masked]
Date: Fri, 14 Mar 2003 12:36:05 +1100

> as instruction to drop this document.

	As currently specified this is going to result in operational
	problems.

	We really need to specify key functionality at key creation time.
	This way signer and DS key generation can be well defined.
	
	I propose two bits:

	DSK (DS Key)
	ZSK (Zone Signing Key)

	I'm discussing this with Olaf face to face.

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 17 Mar 2003 18:32:27 +0100

In response to

 * > This starts a 2 week Working Group last call on this document,
 * > concluding on March 28'th 2003.

 [email-masked] writes:

 * 	As currently specified this is going to result in operational
 * 	problems.
 * 
 * 	We really need to specify key functionality at key creation time.
 * 	This way signer and DS key generation can be well defined.
 * 	
 * 	I propose two bits (...)

In somewhat more detail:

Based on experiences during the recent workshop we came to the
conclusion that a signer (either the off-line or the on-line, in the
case of dynamically updated signer) needs to know which key is to be
used for signing the zone data. This can be done by using a second
bit.

With this bit and some definition on the behaviour of the signer based
on the settings of the bit signers can do their work automatically.

The behaviour of the signers given the states of the bit needs to be
clearly specified.

 KSK  ZSK
  0    0       Signers treat this as an undefined state.
  1    0       The Key is used to sign the apex key set only.
  0    1       The Key is used to sign all zone date except the apex key set.
  1    1       The Key is used to sign all zone and apex key data.

As in the current version of the draft the bit provide operational
hints and MUST not be used in resolving and verification.

If during the working group meeting on Tuesday supports this idea I'd
like to modify the draft to incorporate these ideas and push a new
version in order 1-2 weeks.

---

From: Roy Arends <[email-masked]>
Date: Mon, 17 Mar 2003 20:14:37 +0100 (CET)

> used for signing the zone data. This can be done by using a second

Just curious, but why not use the key with KSK bit = 0 ? Or maybe the
signer can use the set of private keys available online in case of dynupd
? (I assume hygiene insists private ksk and the private zsk are not in the
same room). Also, imho a ZSK is a subset of the KEY RRset, which in itself
is a subset of zone data. The ZSK bit does the trick of making the KEY
distinct from other keys in the apex RRset. The distinction is that the
KSK is typically used for authentication of other keys.

Anykey, just mey .02 euros.

Roy

---

From: David Blacka <[email-masked]>
Date: Mon, 17 Mar 2003 19:27:07 -0500

> version in order 1-2 weeks.

I don't think I agree with this.

The reason why the KSK bit is a good idea is primarily that is has an on the 
wire use.  Specifically, with the KSK bit, it is possible for the parent to 
query the child in-band to determine from which key(s) DS records should be 
calculated.  The fact that it can also be used by the signer to 
automatically determine which keys are KSKs versus ZSKs might be a nice 
thing, but IMHO not the real reason for the bit.

I agree that both humans and zone signing tools should be crystal clear 
about which keys are KSKs, ZSKs or both.  But this can be done locally (for 
instance, by adding this information to the key file names).  I cannot 
think of a wire use for the ZSK bit.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: [email-masked]
Date: Tue, 18 Mar 2003 12:02:37 +1100

> think of a wire use for the ZSK bit.

	Remote debugging.  If the intent of the key is clear/visble
	this is relatively easy.

	Mark

---

From: David Blacka <[email-masked]>
Date: Tue, 18 Mar 2003 00:09:08 -0500

> 	Remote debugging.  If the intent of the key is clear/visble

Remote debugging of what, exactly?

Trying to figure out what the zone signing key is has never been an issue in 
any of the workshops that I've attended, AFAIK.  Trying to figure out which 
key is the secure entry point HAS been an issue.
-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 09:41:16 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "David" == David Blacka <[email-masked]> writes:
    David> I don't think I agree with this.

  I don't agree that you don't agree!
  Your later text explains that you do.

  I claim you do agree. We (the humans) need to identify which is KSK and
which is ZSK. Sometimes humans will ask the computer to help them figure it
out, such as when the parent wants to know which key to download for offline
verification. It is also useful so that humans can more easily be told by
the tools, "I think that you made a mistake, add --I-really-mean-it if you
are sure".

]       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: Marc Blanchet <[email-masked]>
Date: Tue, 18 Mar 2003 13:11:47 -0500

I would like to suggest to add a section to this draft about how case
insensitivity is handled in idn, in order to get some references to
additional related work (idn) that have important impact on case
insensitivity for the user point of view.

Regards, Marc.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Mar 2003 10:52:24 -0800

-----BEGIN PGP SIGNED MESSAGE-----

    >> Remote debugging.  If the intent of the key is clear/visble

    David> Remote debugging of what, exactly?

    David> Trying to figure out what the zone signing key is has never been
    David> an issue in any of the workshops that I've attended, AFAIK.

  Have multiple keys been tested prior to last week?
  Certainly we did get the wrong keys sent to the parent. If we couldn't
talk across the table, then we would have had a problem debugging.

  So, I want those bits there - they are for the CPU in my head?

---

From: Paul Vixie <[email-masked]>
Date: Tue, 18 Mar 2003 22:50:03 +0000

> Have multiple keys been tested prior to last week?

yes.

> So, I want those bits there - they are for the CPU in my head?

i'm withdrawing my prior support for the KSK draft.  KSK vs ZSK should
either be two distinct RR types (possibly as part of a type code roll)
or the "key type" bit (KSK vs ZSK) should be used by validators.  this
is because of Orr's principle (data which is not used will be wrong)
and also because key management techniques such as rollover or parent
signing of child zone keys or DS RR generation and insertion are not
really practical as "operational sugar" and ought to be specified in
the basic protocol.

this does not bear on johani's "threshold validation", since there can
still be more than one key of any type (KSK vs ZSK) which needs more
than one key.

---

From: David Blacka <[email-masked]>
Date: Tue, 18 Mar 2003 17:52:03 -0500

On Tuesday 18 March 2003 12:41 pm, Michael Richardson wrote:

>   I don't agree that you don't agree!  Your later text explains that
>   you do.
> 
> which is ZSK. Sometimes humans will ask the computer to help them
> figure it out, such as when the parent wants to know which key to
> download for offline verification. It is also useful so that humans
> can more easily be told by the tools, "I think that you made a
> mistake, add --I-really-mean-it if you are sure".

I think that you have misunderstood my point.  

What I agree with is that it needs to be clear to the zone operator
and the zone signing tools which keys are key signing keys and which
keys are zone signing keys.

What I disagree with is that this information needs to be in the KEY
record itself.

I strongly believe that if we are going to define a bit in the KEY RR
(or any other field in any other RR for that matter), it should have
an _on_the_wire_ use.  I don't see one for the ZSK bit.  This
information is important to the zone signer and the human running the
zone signer, which are both located at the same place.  Thus this is
tools issue, albeit an important one.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Mar 2003 00:25:55 +0000

[david blacka]
> an _on_the_wire_ use.  ...

i agree with this, and it's a better way of putting it then i wrote earlier.

but wait, there's a reference:

> How can we control our data quality?
> 
> Ken Orr, (Data Quality and Systems Theory, CACM 41,2) puts forward a
> case that maintaining data quality is a "use based" issue and that, like
> all engineering control systems, this involves a steady stream of
> feedback in this case feedback from the data users. His exploration of
> the subject has led him to deduce certain rules regarding data quality:
> 
>    o Unused Data cannot remain correct for very long.
>    o Data quality if a function of its use, not its collection
>    o Data quality will be no better than its most stringent use
>    o Data quality problems becomes worse as the system ages
>    o If some data element is unlikely to change, when it does
>      change it will be traumatic for the data user
>    o Data quality applies to data AND to metadata.

so, far from removing the KSK bit, i'm in favour of using it in validation,
so that it will be nonoptional, and there will be instant feedback when it
is incorrect.