Subject: Signature at parent (draft-ietf-dnsop-parent-sig-00.txt)

From: Edward Lewis <[email-masked]>
Date: Wed, 21 Mar 2001 17:50:06 -0500

I don't know what to think about this proposal.  It is counter to a lot of
background of DNS (e.g., the child's apex data being more credible than
that at the parent).  I see that this issue gives rise to a conflict of
credible vs. valid.

There are a number of cases to consider but are uninteresting (like the
parent and child having the same KEY RR set for the child).  The
interesting cases are when there are different data and when there is the
concern of liability.

When there are different data (probably just a different SIG RR) between
the child and the parent, it will probably be true that the  (parent) key
validating the SIG RR at the child is not available from an authoritative
source (just caches).  This means that unless there is a glitch, the
child's more credible key set won't be validated by a third party.
Question: is it acceptable to accept less credibile data if it validates
over more credible but unvalid data?  (Seems so.)

Note that there is that "glitch."  This is essentially the time that an
undesired key remains alive in a cache - up to a TTL value.  I don't think
there is a way around this, DNS is not real time and we don't have a way to
publish revokation lists.  (And I don't think that we want to define this.)

If someone has discovered the private key and this is the reason for the
key change, the attacker can get away with misuse of the key for only as
long as the discovered key is signed by its parent.  Again, for the same
reason above, I don't think we have a way to stop this period of
vulnerability.

In other words, so far, this new proposal doesn't generate any other
solvable problems.  (;))

Now, as far as liability - that the parent might present data that
invalidates a child or allows for a child to continue to fall prey to an
attack (because a key is not withdrawn), I don't think this is an area we
can engineer around.  Same arguement about the non-real time-ness and no
revokation list ability.

Finally, there is something that I am concerned about.  When a child
changes their key, the key is sent to the parent who then signs it.  If the
parent then publishes the key, the child hasn't had a chance to make sure
the key wasn't substituted on the way to the parent.

So, I suggest that if we accept parent publication of the child's
signature, then we require that in the key "rollover" process, there is
enough security to make it very hard to substitute keys in transit.  (This
is a rough statement written on the fly.)

Perhaps this should be in dnsop...but I wrote this in response to the
discussion in the in-person meeting.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

Dilbert is an optimist.

Opinions expressed are property of my evil twin, not my employer.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Dan Massey <[email-masked]>
Date: Wed, 21 Mar 2001 22:08:37 -0500

On Wednesday, March 21, 2001 at 05:50PM, Ed Lewis wrote:
| 
| When there are different data (probably just a different SIG RR) between
| the child and the parent, it will probably be true that the  (parent) key
| validating the SIG RR at the child is not available from an authoritative
| source (just caches).  This means that unless there is a glitch, the
| child's more credible key set won't be validated by a third party.
| Question: is it acceptable to accept less credibile data if it validates
| over more credible but unvalid data?  (Seems so.)
| 

Ed raises some good questions, but first some clarification on what is 
stored at the child would be helpful.  The proposal authors do not store 
the SIG from the parent at the child.  For example, look at the keys 
for stack.nl.nl:

At nl.nl you have:
  the stack.nl.nl KEY
  the SIG from nl.nl (parent signed key)

At stack.nl.nl you have:
  the stack.nl.nl KEY
  the SIG from stack.nl.nl (self signed key)

In this scheme, there is always a difference in SIG records between the 
parent and child.  A more fundamental question is which SIGs must be stored 
at the child and which SIGs may be stored at the child.

Dan

---

From: Miek Gieben <[email-masked]>
Date: Thu, 22 Mar 2001 15:54:16 +0100

> over more credible but unvalid data?  (Seems so.)
Dan also makes some good points, it is entirely true what he says
(at least in the way I see it)

> the key wasn't substituted on the way to the parent.
as it works now, the child puts the new key in its zone and signs the
whole thing and then triggers the parent. The parent will get the 
new key and a sig over the new key made with the old key. This sig
will be the safeguard against any substitution. The parent will also
have to check this sig with the old key from the child which it already
own.

> is a rough statement written on the fly.)
true :)

grtz Miek
NLnet Labs