Subject: Re: KSK Flag could have a better name

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Mar 2003 22:56:59 -0800

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

>>>>> "David" == David Blacka <[email-masked]> writes:
    David> My belief is that the confusion here is caused by the fact that
    David> the term "Key Signing Key" or KSK is used so heavily in discussion
    David> of a particular key management technique (i.e., a separate KSK and
    David> ZSK) that the use of the name in the flag implies (rightly or
    David> wrongly) that this technique is in use.

    David> So, I think we need a separate term for this flag and the keys
    David> that use it.  Perhaps "Security Entry Point Key (Flag)", or
    David> "Introductory Key (Flag)".  I might also be a good idea for the
    David> KSK flag draft to be a bit more explict about how a zone signer
    David> should and shouldn't use this flag.

  okay, so this sounds like a fine idea to me.

  I *think* that part of the difficulty is: what does it mean when the flag
is off? It was assumed by some software that if the "flag" was off, then
it must be a ZSK. In fact, this isn't the case. 

  Previously, it was believed that if:
      KSK = true     key was Introductory key
      KSK = false    key was zone signing key

  leaving no value for the person (me, in the workshop) who was too lazy
to generate two keys on the first day. I wanted to use one key for both,
but the tool tried to outsmart me.

  I am amenable to the concept that this is all a local matter. Particularly,
to your view that bits on the wire that aren't important get set wrong.

  Except, as I said at the Mike, when I'm supposed to reverse engineer what
my ISP, or worse, *YOUR* ISP has done wrong, while determining why we can not
communicate/do DNS resolution.

  I *regularly* get calls from sites that complain I'm attacking them.
Each time, it has turned out I'm *attacking* them either ICMP port
unreachables, or DNS *replies*. I.e. they are soo clueless that they didn't
notice they had a compromised/broken host which was initiating connections to
me. This is state of the art. Getting remote debugging is really important to
me. 
  I need to write a draft that perhaps provides for more diagnostic options,
cause "SERVFAIL" is just not enough when DNSSEC fails.

]       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"); [

--
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: Miek Gieben <[email-masked]>
Date: Thu, 20 Mar 2003 10:12:46 +0100

[On 20 Mar, @05:06, David wrote in "KSK Flag could have a better n ..."]
> My belief is that the confusion here is caused by the fact that the
> term "Key Signing Key" or KSK is used so heavily in discussion of a
> particular key management technique (i.e., a separate KSK and ZSK)
> that the use of the name in the flag implies (rightly or wrongly) that
> this technique is in use.

maybe "DS key" is good name, because this is the key of which the parent
has the corresponding DS,

regards, 
    Miek

---

From: Edward Lewis <[email-masked]>
Date: Thu, 20 Mar 2003 14:23:19 -0800

I thimk [sic] that David is onto something.

I have never liked 'SEP' though, and something close to Miek's is 
probably a better name - DSR (Delegation Signer Request[ed]).

Or, perhaps SEP is the right one.

There are two things that would make use of the bit:

    the gorp that sucks in keys from the child server to given them to the
    signing process of the parent zone

    the gorp that sucks in keys to prepare attestations that these are the
    genuine keys and that they ought to be configured in resolvers of interest

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer