[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DNSKEY flags field

At 21:03 +0200 6/14/04, Olaf Kolkman wrote: 
 Hmm, well in this case, the validator can tell that there's a problem.  It
knows, verifiably, that data in the child is unverifiable even though the
parent is.  We've definitively hit the end of an island of security.


Before even responding to Olaf, I just went back over the intro document and noticed that it defines "island of security" a bit differently than I do - but not in a contradictory way. I've always thought of an island as being a subtree whose members are all linked through secure delegations with the root being a secure entry point. The docs say only the root of such a subtree is an "island of security."

I think this is incorrect, let me try to explain,

The validator MUST not use proto=4 keys for validation. So the DNSKEY set
cannot be validated, hence the self signature cannot be validated and the
DNSKEY RRset  should be marked as bogus.  (That is how I read the scripture, I
hope there is no ambiguity)

For DNSSECbis, this is clear.

DS does not have a proto field that could have been used to indicate that one
is pointing to a proto 'n' key. So we cannot use DS to make the transition.

If I said otherwise, I was confusing the protocol field with the algorithm field.

If we allow proto=4 to be used for DNSKEY validation than we are fine we could
'hack' around this.

It wouldn't be so much of a hack if we defined protocol 42 to be DNSSECter. DNSSECbis would simple be unable to deal with these keys, letting them fall into the bogus category.

Going back to the assumption that I am dealing with a zone that is written in DNSSECbis and DNSSECter, and I only understand DNSSECbis, I should still see a DS RRset signed with a key designated as DNSSECbis protocol. I then have hashes that I ought to be able to apply to the the set of keys at the child, even if they are written in DNSSECter. I should be able to validate them via the hash, therefore concluding what I read is true - that these are all DNSSSECter keys.

At that point, I think it's safe to conclude that I've hit the boundary of a DNSSECbis island of security (my version), to use the -intro, I've fallen from a DNSSECbis island of security through some zones, into a zone with no security.

Instead of SERVFAIL, I return this as unsigned data to someone asking for verified data.

If this approach can stand up, I'd prefer it than having to deal with the bits of the key flags, for the sake of simplicity. (Lot of if's there.)
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer

"I can't go to Miami.  I'm expecting calls from telemarketers." -
Grandpa Simpson.

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>