Subject: Re: DNSKEY flags field

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 14:39:35 -0400

At 16:13 +0000 6/15/04, Paul Vixie wrote:
>i think it's a problem, and it leads me to the opposite conclusion.  the
>proto field is worthless for -trans, simply because not every metadata rr
>has it.  by the time you've gone looking for the information you need to
>know to determine whether you should trust what you saw, you already had
>to trust it to do the looking, so what you find is a wider source of
>possible failures, but not a wider source of possible successes.

I'm not following your logic.

Let's say I start by getting an answer RR set and the RRSIG(s).  I go 
off and ask for the DNSKEY RR for each RRSIG interatively - let's say 
the retrieval is recursive.  So, when I get a return from the 
function to get the DNSKEY identified by the RRSIG, I get either 
success and then validate the signature, or I get a failure.  (If 
successful, I break the iterations.)  If there are no acceptable 
DNSKEYs to use after all iterations, there's no validation to be done.

(Note that the key specified in the RRSIG need not be in the same 
*domain* as the answer, I might "chase" it if my local policy so 
allows.)

But all is not lost, I perhaps there was no "security to be expected" 
to begin with.  So, I look to my trusted keys, choose the closest 
enclosing one for the query and follow it down the zone cuts to my 
data.  It makes no sense to go to a more general encloser as I 
presumably only configure keys I can make sense of.

(I'm not espousing this to be the way to write the code, it's just an 
algorithm.  The details between algorithm and implementation might 
hold the missing link that prevents me from following the logic 
above.)

What I would expect to find (looking at the closest trusted key to 
the answer) is an island of security "relative to me, my capabilities 
and policy."  There are keys of my chosen algorithms, and of my 
chosen protocol version(s), etc.  As I descend through or from 
(depending on what you consider the island to be) the island via zone 
cuts, I'll either get to the desired zone or find an "end of 
security" relative to me (the verifier).  If I get to the data I 
want, well something fubar'ed earlier and I might be able to do 
validation after all.  If I find the "end of security," I can 
conclude that finding no key for any signature wasn't a problem. 
"End of security" might be running out of protocol={me} or 
algorithm={what I can do} or just a NSEC saying there's no DS set.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 17:11:59 -0400

At 14:39 -0400 6/15/04, Edward Lewis wrote:
>(Note that the key specified in the RRSIG need not be in the same *domain* as
>the answer, I might "chase" it if my local policy so allows.)

When I wrote that - in the back of my mind is this in the -records
draft:

# 3.1.7  The Signer's Name Field
#
# The Signer's Name field value identifies the owner name of the DNSKEY
# RR which a validator should use to validate this signature.  The
# Signer's Name field MUST contain the name of the zone of the covered
# RRset.  ...

Zeroth - there's a should there, in small letters.  s/should/is supposed to/

First I can't believe that's in the records draft - it seems to be a
restriction on validation, which would be protocol.  (There are other
things that fall into the "why would this be a records consideration"
but aren't all that important.)

Second, aren't validators allowed to be bound by local policy in this
manner?  Can't we have out of domain signers of data?

(I know we've hashed this around before, but if there was a reason to
leave this restriction in, where's the summary text of the previous
rehashing?  Besides the archives, I mean.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer