On Thu, Aug 4, 2016 at 1:16 PM, Paul Hoffman <[email protected]> wrote:
> Greetings again. There are six terms that are commonly used when we talk > about DNSSEC: > - validation and validate > - authentication and authenticate > - verification and verify > Are they defined in any RFCs that we can use for the terminology-bis > document? As far as I can see (but I could be blinded), they are not > defined in RFC 403[3-5]. > > Suggestions? > > Here are some suggestions for validation and authentication, based both on RFCs and other observed usage. Validation, in the context of DNSSEC, refers to either (1) checking the validity of DNSSEC signatures; (2) checking the validity of DNS responses, such as those including (hashed) authenticated denial of existence; or (3) building an authentication chain from a trust anchor to a DNS response or individual DNS RRsets in a response. Definitions (1) and (2) consider the only validity of individual DNSSEC components (e.g., RRSIG validity or NSEC proof validity), whereas definition (3) considers the components of the entire DNSSEC authentication chain. Thus definition (3) requires "configured knowledge of at least one authenticated DNSKEY or DS RR" (RFC 4035, Section 5). RFC 4033, Section 2, indicates that a "Validating Security-Aware Stub Resolver... performs signature validation" (1) and uses a trust anchor "as a starting point for building the authentication chain to a signed DNS response" (3). The process of validating an RRSIG RR is described in RFC 4035, Section 5.3. RFC 5155 refers to validating responses (2) throughout the document, in the context of hashed authenticated denial of existence. Authentication is used interchangeably with validation definition (3). RFC 4033, Section 2, describes the chain linking trust anchor to DNS data as the "authentication chain". A response is considered to be authentic if "all RRsets in the Answer and Authority sections of the response [are considered] to be authentic" (RFC 4035). DNS data or responses deemed to be authentic or validated (3) have a security status of "secure" (RFC 4035, Section 4.3; RFC 4033, Section 5). "Authenticating both DNS keys and data is a matter of local policy, which may extend or even override the [DNSSEC] protocol extensions" (RFC 4033, Section 3.1). Casey
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
