Re: [DNSOP] Definitions of basic DNSSEC terms

[Edward Lewis <[e-mail]>]

On 8/10/16, 20:55, "Paul Hoffman" <[e-mail]> wrote:

>    That seems like a categorization, not a definition. Or are there 
>    definitions that involve "local policy" you or Ed can propose?

I've given this some thought and am a bit conflicted.

On the one hand, the intent of DNSSEC way-back-when was that the goal was protecting the receiver of the information and how the receiver choose to protect itself was strictly a matter of local policy.  Hence, there was no definition given to what validation or verification meant, not in any sense that was to be held as a standard.  Trying now to give these terms definitions under DNSSEC would be a significant change to the architecture.

Then again, in a world where operators rely on tools someone else writes, establishing an understanding of what a validated or verified answer "means" is desirable.  I still am not convinced that there is an impact on interoperability, meaning different caches can verify according to different local policy and the protocol could carry on.  For the sake of a DNSSEC "buyers guide" establishing some minimum guidelines would be beneficial.

I'd start with the "mechanical" algorithm for evaluating a signature, meaning, how to manipulate the DNSKEY, RRSIG and relevant data records.  I'd include evaluating the absolute times in the RRSIG, and what to do if the DNSSEC security algorithm is not locally available.

I'd include the implications of the chain of trust and trust anchors - how the set of trust anchors is managed.  ("Trust Anchor Hygiene" has been a working title for that.)

I'd include the various concerns, like replay attacks, ersatz revocation of signatures or a key's status.

The sticky issues are deciding what is apparently a permanent situation - meaning that an administrator would have to intervene to fix something - versus a temporary situation.  An example of a temporary situation is a network link or service failure preventing a trust chain element being retrieved.

All of this is written off the cuff.  It's been a long time since I rigorously looked at this.  My failing memory recalls there being many possible return codes from the validator I wrote in the 90's, suggesting that there are a lot of details in defining what is "verification and validation" in the sense of DNSSEC.

So in some sense, I don't think finer definitions are to be given.  If one really wants to codify finer detailed definitions, write it up as a draft and study it carefully.

Ed

PS - This comes from sage advice I was given about the Section "Algorithm" in "Domain Concepts and Facilities".  That section was not intended to be code, not intended to be pseudo-code, rather it guides what code is supposed to do.  This came from Rob Austein when I asked about difficulties in interpreting step 3's a, b, and c and the order in which they would be evaluated.

I.e., "back in the day" the documents were not trying to be specifications but descriptions of the protocol with the goal of leading to interoperable implementations.  The ramification is, if one wants more detail now, one might be challenging the basic assumptions of the protocol.  I am not saying that that would be a bad thing, just that it means a considerable amount of work.

Is a "Clarification on DNSSEC Verification and Validation" needed?  Or are we just trying to supply definitions to words?