Re: [DNSOP] [Ext] Working Group Last Call - draft-ietf-dnsop-rfc5011-security-considerations

[Edward Lewis <[e-mail]>]

On 10/18/17, 04:17, "DNSOP on behalf of tjw ietf" <[e-mail] on behalf of [e-mail]> wrote:

>This starts a Working Group Last Call for: draft-ietf-dnsop-rfc5011-security-considerations

I outright oppose publishing this document.

One, the audience of this document (namely the targetted operators) has not participated in the review of the document.  I should perhaps add "sufficiently" as I have made comments and my personal observation is that the document isn't all that helpful. No other operator, so far as I know (big caveat), has commented.

Two, the document perpetuates the mis-use the term "trust anchor".  To point to a specific place in the document:

## 3.  Terminology
##
##    Trust Anchor Publisher  The entity responsible for publishing a
##       DNSKEY that can be used as a trust anchor.

That is not a term I'd define.  Trust is gained, not read.  One cannot
"push" trust via publishing something.  What is published are secure
entry point keys:

>From "DNSSEC Resource Records", section "The Flags Field":

"Bit 15 of the Flags field is the Secure Entry Point flag, described
in [RFC3757]"

Note that it is not the "Trust Anchor flag."  I don't think that the working group should progress documents that lead to terminology confusion.

Three, the document beings to co-mingle validation with trust anchor management, which are two different concepts:

##    RFC5011 Validating Resolver  A DNSSEC Validating Resolver that is
##       using the RFC5011 processes to track and update trust anchors.
##       Sometimes referred to as a "RFC5011 Resolver"

Automated Updates is not part of the validation process, it is a part
of the trust anchor management function.  Whether the set of trust anchors
are managed in accordance to Automated Updates or not, the validation process
is the same.

Four...well, as I said, it's hard to justify spending time on a document that has a low ROI.  The equation for timing, which is the highlight of the document, is too complicated and includes an unsupported "safety margin."  The latter element throws out the window any reason to be so precise up to that point.

I appreciate the document's desire.  But it would be better written if it came from operator experience in implementing a key management scheme that is compatible with what is described in the Automated Updates of DNSSEC Trust Anchors document.  And it would be less harmful if the terminology stuck to the language used in developing the protocol, as opposed to the colloquial use that has emerged.  (Such as the notion that trust anchors "are published".)

The reason I'm opposing going forward without providing new text is that I don't feel that I can give new text until completing a process designed to be compatible with "Automated Updates".  I could envision a "Recommended Management of Secure Entry Points for Compatibility with Automated Updates" coming in the future, but not yet.