On 8/10/16, 20:55, "Paul Hoffman" <paul.hoff...@vpnc.org> 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?
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
