Subject: Re: [dnsop] comments on draft...epp-secdns-05

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Nov 2004 21:43:21 -0500

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

>>>>> "Edward" == Edward Lewis <[email-masked]> writes:
    Edward> The first issue to hash out is - whether a registry needs
    Edward> the key or even if the registry should get the key.
    Edward> Remember that "key at parent" was ditched in favor of the
    Edward> delegation signer record.

  Availability of the DNSKEY in another database provides the ability to
easily create forests. While I can read the DS over the phone with
another zone owner, the parent may not be generating them yet.

  Given DNSKEY, we can create DS, but not the inverse.
  That makes the decision simple for me.

    Edward> The second issue is whether the protocol ought to even
    Edward> support a choice.  In my opinion, the DS option is required.

  No choices. DNSKEY required.
  Making DS optional is fine, but I see that as useless code.

- --
]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson,    Xelerance Corporation, Ottawa, ON    |net architect[
] [email-masked]      http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Michael Richardson <[email-masked]>
Date: Tue, 30 Nov 2004 21:46:01 -0500

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

>>>>> "Samuel" == Samuel Weiler <[email-masked]> writes:
    >> Why?  (The rest is just commentary on the DS option...)

    Samuel> Because it may be useful for the child to select the DS
    Samuel> digest algorithm, the DNSKEY option (in this draft) has no
    Samuel> way to specify the digest, and allowing the child to send DS
    Samuel> (by keeping the dsData element) seems simpler than adding a
    Samuel> new element to the key spec.

  Why does the child get to decide this?
  This seems wrong to me.

  Consider an attack on a signing algorithm where private data can be
revealed by careful selection of text to be signed.
  (To be clear, I don't know of such an exact attack, although I recall
there was an implementation bug that had a simliar effect. I'm sorry, I
don't recall the details)

- --

.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Wed, 29 Dec 2004 09:58:21 +0100

Skimming the archive after Ed posted a question, I noticed this
question was still hanging.

> > > operationaly does this presume that the parent
> > > can/MUST beable to do a zone transfer 
> > 
> > No need for that.
> 
> 	but that will work - yes?

Are you asking if 'dig @ns.secret-wg.org secret-wg.org DNSKEY +dnssec' works?

> 
> > > or will there
> > > be a mutually agreeable, common location where the
> > > parent can retreive the key via standard queries?
> > 
> > A query to the DNSKEY RR at the child's apex with the SEP bit set?
> 
> 	does that presume a single DNSKEY?

I read that question as "does that presume a signle DNSKEY with the
SEP flag set?"

Good point, the child may be rolling their keys and therefore have two
SEP keys at its apex. On the other hand, if I understand the context
correct, the query will only be done in certain special circumstances,
e.g. in order to recreate the hash. It can be assumed that using the
data the registry has on-file the registry can sort out which key to
pick if there are multiple SEP keys.

So I do not think that the child having multiple SEP keys is a problem
in a scenario where you have to re-generate DS RRs as long as you have
some record of which key to pick.

If you rely on the SEP flag to identified the key the DS should point
to and there are no keys with the SEP flag set you may find yourself
in trouble.

--Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

.