Subject: [DNSOP] Definitions of basic DNSSEC terms

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 04 Aug 2016 10:16:56 -0700

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?

--Paul Hoffman

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 04 Aug 2016 15:34:32 -0700

"Paul Hoffman" <[email-masked]> writes:

> Greetings again. There are six terms that are commonly used when we
> talk about DNSSEC:

I think they do exist in documents, but may not be defined in that exact
conjugation for each word in a terminology section.  EG:

  # rfcfind -n 4034 -m | grep validate | wc -l
  6

  # rfcfind -n 4034 -m | grep validation | wc -l
  2

But, no, 4033 defines terminology with the "validating" thingies.
-- 
Wes Hardaker
Parsons

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 04 Aug 2016 15:39:28 -0700

>   # rfcfind -n 4034 -m | grep validation | wc -l

We are OK with conjugation changes.

> But, no, 4033 defines terminology with the "validating" thingies.

Not sure what this means. All the definitions of terms with "validat.*" 
in them seem circular, but maybe I'm missing the core one.

--Paul Hoffman

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Aug 2016 10:55:03 +0000

On 8/4/16, 10:16, "DNSOP on behalf of Paul Hoffman" <[email-masked] on behalf of [email-masked]> wrote:

    Suggestions?

Writing based on possibly undocumented (read: oral) history, those terms fell under the category of "local policy" in the earlier DNSSEC documents (such as "Domain Name System Security Extensions" [RFC 2535]).

When the first proof-of-concept DNSSEC validator was written there was a definite and deterministic set of tests implemented but there was no intention to codify that into an IETF document for a number of reasons.  At the time the documents had a goal of defining what was needed for interoperability, as opposed to be prescriptive.  And it wasn't clear that local matters of what an instantiation would trust would necessarily be significant to what another instantiation would choose.

There once was a long thread on whether an authoritative server should perform cryptographic checking of all loaded signature before adding in the AD bit.  Ultimately it was decided to not require that (because, for one, load time was too long for large zones). Authenticated Data meant "the server is happy with the data" and not that any level of computation (signature checking) had been done.  The result of this is in "Redefinition of DNS Authenticated Data (AD) bit".

Subject: Re: [DNSOP] Terry Manderson's Discuss on draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)
From: Wes Hardaker <[email-masked]>
To: Terry Manderson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Wes Hardaker <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Spencer Dawkins at IETF" <[email-masked]>, The IESG <[email-masked]>
Date: Wed, 3 Aug 2016 15:53:08 -0700
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

Terry Manderson <[email-masked]> writes:

> Hi Spencer,
>
> On 14/07/2016, 12:57 PM, "Spencer Dawkins at IETF"
> <[email-masked]> wrote:
>>
>>Terry, I like where you're headed, but just to ask the obvious question,
>>are you thinking the draft would, or would not, also contain something
>>like "at the time this document was approved, a domain used for this test
>>was $someactualworkingdomain.com <http://someactualworkingdomain.com>"?
>
> Sorry I didn't make it obvious, yes I would like to see text like this,
> and I think it makes an easy path for the less adventurous in addition to
> supplying more in depth guidance.

How does this text work to be dropped into the end of the
"Implementation experiences" section (1.3):

      <section title="Test Zone Implementation">
	      <t>In this document, the "test.example.com" domain is
	      used to refer to DNS records which contain test records
	      that have known DNSSEC properties associated with them.
	      For example, the "badsign-a.test.example.com" domain is
	      used below to refer to a DNS A record where the
	      signatures published for it are invalid (i.e., they are
	      "bad signatures" that should cause a validation
	      failure).</t>

	      <t>At the time of this publication, the
	      "test.dnssec-tools.org" domain implements all of these
	      test records.  Thus, it may be possible to replace
	      "test.example.com" in this document with
	      "test.dnssec-tools.org" when performing real-world
	      tests.</t>
      </section>

And then everywhere that test.dnssec-tools.org exists in the document,
I'll replace it with "test.example.com".
-- 
Wes Hardaker
Parsons

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Tony Finch <[email-masked]>
Date: Tue, 9 Aug 2016 12:05:39 +0100

>     document?

RFC 4949 - Internet Security Glossary

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Southeast Iceland: Variable 3 or 4, but westerly or northwesterly 4 or 5 at
first in north. Moderate, occasionally rough at first. Occasional rain. Good,
occasionally poor.

---

From: william manning <[email-masked]>
Date: Tue, 9 Aug 2016 14:56:19 -0700

must be mass hallucination.   My memory concurs with Ed on the history.
If you MUST define authentication, validation, and verification, I would
place them under, "local policy"

/W

On Tue, Aug 9, 2016 at 3:55 AM, Edward Lewis <[email-masked]> wrote:

> On 8/4/16, 10:16, "DNSOP on behalf of Paul Hoffman" <
> [email-masked] on behalf of [email-masked]> wrote:
>
> talk
> Writing based on possibly undocumented (read: oral) history, those terms
> fell under the category of "local policy" in the earlier DNSSEC documents
> (such as "Domain Name System Security Extensions" [RFC 2535]).
>
> When the first proof-of-concept DNSSEC validator was written there was a
> definite and deterministic set of tests implemented but there was no
> intention to codify that into an IETF document for a number of reasons.  At
> the time the documents had a goal of defining what was needed for
> interoperability, as opposed to be prescriptive.  And it wasn't clear that
> local matters of what an instantiation would trust would necessarily be
> significant to what another instantiation would choose.
>
> There once was a long thread on whether an authoritative server should
> perform cryptographic checking of all loaded signature before adding in the
> AD bit.  Ultimately it was decided to not require that (because, for one,
> load time was too long for large zones). Authenticated Data meant "the
> server is happy with the data" and not that any level of computation
> (signature checking) had been done.  The result of this is in "Redefinition
> of DNS Authenticated Data (AD) bit".
>
>
>
>
> ---------- Forwarded message ----------
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, Wes Hardaker <[email-masked]>, "
> [email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Spencer Dawkins at
> IETF <[email-masked]>, The IESG <[email-masked]>
> Subject: Re: [DNSOP] Terry Manderson's Discuss on
> draft-ietf-dnsop-dnssec-roadblock-avoidance-04: (with DISCUSS and COMMENT)

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 10 Aug 2016 17:54:05 -0700

> RFC 4949 - Internet Security Glossary

I looked there, but the terms don't fit well for DNSSEC. If there are 
bits below that we can pick out, great, but it seems like a stretch.

--Paul Hoffman

    $ validate
       1. (I) Establish the soundness or correctness of a construct.
       Example: certificate validation. (See: validate vs. verify.)

       2. (I) To officially approve something, sometimes in relation to 
a
       standard. Example: NIST validates cryptographic modules for
       conformance with [FP140].

    $ authenticate
       (I) Verify (i.e., establish the truth of) an attribute value
       claimed by or for a system entity or system resource. (See:
       authentication, validate vs. verify, "relationship between data
       integrity service and authentication services" under "data
       integrity service".)

       Deprecated Usage: In general English usage, this term is used 
with
       the meaning "to prove genuine" (e.g., an art expert authenticates
       a Michelangelo painting); but IDOCs should restrict usage as
       follows:
       -  IDOCs SHOULD NOT use this term to refer to proving or checking
          that data has not been changed, destroyed, or lost in an
          unauthorized or accidental manner. Instead, use "verify".
       -  IDOCs SHOULD NOT use this term to refer to proving the truth 
or
          accuracy of a fact or value such as a digital signature.
          Instead, use "verify".
       -  IDOCs SHOULD NOT use this term to refer to establishing the
          soundness or correctness of a construct, such as a digital
          certificate. Instead, use "validate".

    $ authentication
       (I) The process of verifying a claim that a system entity or
       system resource has a certain attribute value. (See: attribute,
       authenticate, authentication exchange, authentication 
information,
       credential, data origin authentication, peer entity
       authentication, "relationship between data integrity service and
       authentication services" under "data integrity service", simple
       authentication, strong authentication, verification, X.509.)

    $ verification
       1. (I) /authentication/ The process of examining information to
       establish the truth of a claimed fact or value. (See: validate 
vs.
       verify, verify. Compare: authentication.)

       2. (N) /COMPUSEC/ The process of comparing two levels of system
       specification for proper correspondence, such as comparing a
       security model with a top-level specification, a top-level
       specification with source code, or source code with object code.
       [NCS04]

    $ verify
       (I) To test or prove the truth or accuracy of a fact or value.
       (See: validate vs. verify, verification. Compare: authenticate.)

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 10 Aug 2016 17:55:21 -0700

> place them under, "local policy"

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

--Paul Hoffman

---

From: Tony Finch <[email-masked]>
Date: Thu, 11 Aug 2016 11:09:20 +0100

Paul Hoffman <[email-masked]> wrote:

> I looked there, but the terms don't fit well for DNSSEC. If there are bits
> below that we can pick out, great, but it seems like a stretch.

Hmm, yes, much less useful than my vague memory suggested. And I'm not
sure some of its recommended usage is actually sane, e.g. people talk
about authenticated crypto (as in AES-CGM etc.) not verified crypto.

It's probably worth explicitly describing how DNS usage differs from RFC
4949.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
North Fitzroy: Northerly 4 or 5, becoming variable 3 or 4. Slight or moderate.
Fair. Good.

---

From: Casey Deccio <[email-masked]>
Date: Thu, 11 Aug 2016 11:21:57 -0400

> document? As far as I can see (but I could be blinded), they are not
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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 15 Aug 2016 15:29:00 +0000

>    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?