A Framework for DNSSEC Policies and DNSSEC Practice Statements
draft-ietf-dnsop-dnssec-dps-framework-11

[Ballot comment]
From the shepherd writeup:
> There was a concern about a possible copyright issue, but only in
> respect to a pre-RFC5378 RFC.  Parts of RFC 3647 have been used in the
> draft, so the authors have contacted the authors of RFC 3647 requesting
> permission to use text from it.  All who have replied (four out of five)
> have given that permission.

Response from Tomofumi Okubo:
"We received the permission from the 5th author of RFC3647 shortly after
the writeup was submitted."
So this former DISCUSS is now cleared.

[Ballot discuss]
From the shepherd writeup:
> There was a concern about a possible copyright issue, but only in
> respect to a pre-RFC5378 RFC.  Parts of RFC 3647 have been used in the
> draft, so the authors have contacted the authors of RFC 3647 requesting
> permission to use text from it.  All who have replied (four out of five)
> have given that permission.

The document doesn't have the pre-5378 boilerplate and, unless the fifth 3647 author replies, it needs it.  This DISCUSS is a reminder to make that change.

[Ballot discuss]
Having written a couple of CPs and CPSs (and depending on how you look at it that's either ;) or :( )

1) Is it purely political that you're including the following "There are no agreements with the relying parties."

Is the "yet" coming once a DPS is written?  It can be pretty easily argued that publishing a DPS is a form of agreement.  Those that use the signatures are relying on them to do x and y but not z.  Or are you simply trying to telling people to not write RP agreements?

2) So I hope I'm not stepping in it here, but there's a couple of places where the draft discusses TA distribution. Isn't that already addressed with adequate documentation - and can't you just point to that?  I.e.: https://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.txt.

Further, I thought the goal of DNSSEC was to encourage IANA as *the* TA.  Some of the wording seems to not entirely support that.  Was this done purposely?

3) This ought to be easy to clear up but I wanted to check on this:

s4.6.1: Are the changes to the algorithms performed according to IETF process?  Should this section explicitly call that out?

[Ballot comment]
This so short for a policy document! :)  I also saw that Russ had a lengthy set of comments, and I apologize for not having time to skim through them and look for duplicates.  These are primarily based on a review by Steve Kent.

1) s1: Do you want to also be able to check that the data hasn't been verified while in the cache:
      r/that it has not been modified in transit/
        /that it has not been modified in transit or in storage (e.g., caching).

      r/comprising statements of critical
        /comprising statements describing critical

2) About the differences between a PKI and DNSSEC:

2a) There is also no central control of assurance or trust levels in a PKI either ;)

2b) You could argue that in PKIX each CPS defines their own way of managing keys - i.e., the same PKIs.

2c) Weakest link the certification path is akin to the weakest link in the DNS link.

I'm not sure you need the whole justification for why we're different bit.  Just say you borrowed from it and move on -that way you'll avoid all the but this is the same arguments/confusion.  How about:

This document is heavily inspired by the Internet X.509
Public Key Infrastructure Certificate Policy and Certification
Practices Framework [RFC3647].

and r/Consequently, a/A

3) s1.2: You will do it ;)
      r/aims to explain/explains
      r/aims to present/presents

4) s2, Compromise: I guess you can define this however you want, but normally wouldn't include loss, modification, or unauthorized use in key compromise.  I mean the result revocation is the same as key compromise.

5) s2, DNSSEC: I guess it could hurt to repeat the suite of RFCs here:
    r/IETF specifications that
      /IETF specifications [RFC4033][RFC4034][RFC4035] that

6) s2, key rollover: Need to be more precise about which keys you're rolling over (both KSKs (which sign keys, not zones) and ZSKs?).

7) s2, PKI: I'd just copy the definition from RFC 5280 to avoid comments :)
 
    the hardware, software, people, policies, and procedures needed to
    create, manage, distribute, use, store, and revoke public key
    certificates [RFC5280].

8) s2, PA:

8a) Is there a PA for every DP or is this an optional element of this architecture?

8b) Later you use the term formal and informal PA.  These should be explained here.

9) s2, repository (boarding on discuss) if you don't keep the TA public how is this supposed to work?
    r/should be kept public/must be made publicly available

10) s2: I think you're also missing a definition for multi-party.  It's one step farther than separation of duties - and you do use the term later ;)

11) s2: Now that I'm thinking about it should you also have a definition for assurance, DNSSEC participants (does this include both RPs and signers?), DNSSEC stateholders?

12) s3.1: r/The DNSSEC/A DNSSEC - there will be more than one right
          r/determined/specified
          r/levels/levels of assurance
          r/The DPs constitue/A DP also constitues
          r/it is recognized as implementing/it claims to implement

13) s3.2: Assume participant is signer?
          r/participant/signer

14) s3.3: Unclear what "interoperation of a level of trust between zones" means.  Does it mean a DP may serve as a basis for establishing a common basis of trusted operation throughout a set of zones, or something like that?

15) s3.3: r/one or more zones/one or more zones subordinate to that TLD

          r/ A zone operator may be required to write its own
  Practice Statement to support the Policy by explaining how it meets
  the requirements of the Policy.
          / A zone operator may be required to write its own
  Practice Statement to support the Policy, explaining how the operator meets
  the requirements of the Policy.

          r/Alternatively, a zone operator that
  is also the manager of that zone and not governed by any external
  Policy may still choose to disclose operational practices by
  publishing a DPS for the purpose of providing transparency and to
  gain community trust in the operations.
            /Alternatively, a zone operator that
  is also the manager of that zone, and not governed by any external
  DP, may choose to disclose operational practices by
  publishing a DPS. The zone operator might do so to provide transparency
  and to gain community trust in its operations.
       
          r/level of detail in their provisions
            /level of detail each expresses

        r/processes and controls
          /processes and controls, absent a controlling Policy.
 
16) s3.4: In b and c, when you say contains do you mean the
   
        r/implemetor/implementer
        r/regardless/independent
        r/generally must not conflict with the
          /generally they must not conflict with the stipulations

17) s3.4/4: So many people got confused by whether they had to include the sections in the CPS (and presumably in the DPS) that it is a really good idea to specify whether "no stipulation" and clause title should be included instead of omitting the clause.  It stops people from asking: did you mean to say something about X.

18) s4.1.4: /administration Specification/Administration Specification

19) s4.4:

  r/the DNSSEC related functions such as physical access, key
  management, disaster recovery, auditing, and archiving.
    /DNSSEC related functions. Such controls include physical access, key
  management, disaster recovery, auditing, and archiving.

  r/These non-technical security controls are critical for trusting
  DNSSEC signatures, since lack of security may compromise DNSSEC operations.
  For example, it could result in the creation of signatures with
  erroneous information or in the compromise of a Signing Key.
  Within each subcomponent, each type of control will usually need to
  be described separately.
    /These non-technical security controls are critical for trusting the
  signatures since lack of security may compromise DNSSEC operations.
  For example, it could result in the creation of signatures with
  erroneous information or in the compromise of the Signing Key.
  Within each subcomponent, separate consideration will usually need to
  be given to each entity type.

20) s4.4.1: Includes the term "entity system".  I understand that it's from 3647 and that might refer to the RA or CA or whatever, but what's it refer to here?

21) s4.4.4: r/and provide/and to provide

22) s4.4.4: The phrase "access the systems" is from 3647 and it refers to a CA/RA, what's it refer to here? Is it the entire DNS?

23) s4.5: r/to the DNSSEC/to DNSSEC

24) s4.5: 1st mention of secret keys.  Ought it be defined earlier?

25) s4.5.1: For question 3, if the entity is not a TA, isn’t there just one answer for the RP part of this question?

26) s4.5.1: For question 5, Isn’t this subsumed by DNSSEC documents?

27) s4.5.2: Bullet 2, r/n out of m/"n of m"

28) s4.5.5: Point to ISO 15408:2009?

29) s4.6.1: r/and the key length used to create the keys/and key lengths

30) s4.8: r/liability assummed/liability asserted/

31) s7: r/The sensitivity of the information protected by DNSSEC on all levels
  in the DNS tree will vary significantly.
    /The sensitivity of the information protected by DNSSEC at different tiers
  in the DNS tree varies significantly. 

  r/information/information (i.e., DNS records)

r/Entities must evaluate their own environment and the
  chain of trust originating from their Trust Anchor, the associated
  threats and vulnerabilities, to determine the level of risk they are
  willing to accept.
  /Each relying party must evaluate its own environment and the
  chain of trust originating from a Trust Anchor, the associated
  threats and vulnerabilities, to determine the level of risk it is
  willing to accept when relying on DNSSEC-protected objects.

[Ballot discuss]

  It seems that a DNSSEC signer can start out under one set of policy
  documents, and then for whatever reason the policy changes and the
  DNSSEC signer starts using a revised policy.  In this situation, the
  parties validating the signature have no means to determine that the
  signer is following a different policy.  Please explain the value of
  the policy to the parties that rely on these signatures.  At a minimum
  this possibility needs to be explained in the Security Considerations.

[Ballot comment]

  These comments come from a discussion with one of the authors of
  RFC 3647:

  DNSSEC Policy definition seems off target to me.  Are these all of the
  requirements or just the security requirements?

  The definition of PKI is not wrong, but it misses an important element
  that is important in the DNSSEC context too.  That is, the system
  depends on trusted distribution of public keys.

  The definition of Signing Key is incomplete.  The private key is used
  to sign.  The corresponding public key is used to validate the
  signature.  This is especially important when this definition is
  used in conjunction with the definition of Trust Anchor.  A Trust
  Anchor only includes the public key.  One way to resolve this is
  to define Key Pair or Asymmetric Key Pair.

  I think that Page 7 and 8 could be more clear.  A DP is a statement of
  security requirements (not principles).  The DP is best used to
  communicate requirements that must be met by complying parties; as
  such it may also be used to determine or establish equivalency between
  policies associated with different DNS zones.  A DPS describes the
  actual controls employed to meet the requirements of applicable DP.

  In Section 4.4.2, please consider the addition of a crypto officer
  that controls the private keys.  Also, which of the listed admin
  roles is responsible for the DNS and the network?

  In Section 4.4.4, please consider other records that may need to be
  kept for a period of time, such as records of key roll over, the
  personnel assigned to various roles, child zone manager verification,
  and so on.

  On Page 18, two person control is a special case of n out of m, where
  n = 2 and m is >= 2.

  In Section 4.5.2, please consider moving items 3 and 5 to another
  section.  The points are not about the signing environment; they are
  about the recovery of the signing private key after a failure of some
  sort.

  *****

  These comments are a portion of the Gen-ART Review by Peter Yee:

  Section 4.4.5 discusses how to handle key compromise.  It might be
  useful to discuss here or somewhere else in the document how the
  compromise is prevented from recurring if there were no attenuating
  measures in place beforehand.  That might well lead to a revision of
  the DP or DPS.  The draft doesn't really discuss under what
  circumstances a document should be iterated or amended.

[Ballot comment]

- 1.1: Is this really for "users" to evaluate the strength of
DNSSEC? I don't know any users who'd do that.  Maybe admins
of some sort.

- PKI definition: I'd love if you deleted non-repudiation
since a PKI, and DNSSEC in particular, doesn't get you that.
(By itself.)

IANA has reviewed draft-ietf-dnsop-dnssec-dps-framework-08, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A Framework for DNSSEC Policies and DNSSEC Practice Statements) to Informational RFC


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'A Framework for DNSSEC Policies and DNSSEC Practice Statements'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-07-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document presents a framework to assist writers of DNSSEC
  Policies and DNSSEC Practice Statements, such as Domain Managers and
  Zone Operators on both the top-level and secondary level, who are
  managing and operating a DNS zone with Security Extensions (DNSSEC)
  implemented.

  In particular, the framework provides a comprehensive list of topics
  that should be considered for inclusion into a DNSSEC Policy
  definition and Practice Statement.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework/ballot/


No IPR declarations have been submitted directly on this I-D.

PROTO write-up for draft-ietf-dnsop-dnssec-dps-framework-08.txt
===============================================================

> (1) What type of RFC is being requested (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic)?  Why
> is this the proper type of RFC?  Is this type of RFC indicated in
> the title page header?

This document is being proposed as an Informational RFC as it provides
a list of suggestions that zone operators may choose into include in
their DNSSEC Policy and/or DNSSEC Practice statement.

The type of RFC is stated in the document header.


> (2) The IESG approval announcement includes a Document Announcement
> Write-Up. Please provide such a Document Announcement Write-Up.
> Recent examples can be found in the "Action" announcements for
> approved documents. The approval announcement contains the
> following sections:
>
> Technical Summary
>
> Relevant content can frequently be found in the abstract and/or
> introduction of the document. If not, this may be an indication
> that there are deficiencies in the abstract or introduction.

This document presents a framework to assist writers of DNSSEC
Policies and DNSSEC Practice Statements, such as Domain Managers and
Zone Operators on both the top-level and secondary level, who are
managing and operating a DNS zone with Security Extensions (DNSSEC)
implemented.

In particular, the framework provides a comprehensive list of topics
that should be considered for inclusion into a DNSSEC Policy
definition and Practice Statement.

> Working Group Summary
>
> Was there anything in WG process that is worth noting? For
> example, was there controversy about particular points or were
> there decisions where the consensus was particularly rough?

No.  The discussions were relatively low-key.

> Document Quality
>
> Are there existing implementations of the protocol? Have a
> significant number of vendors indicated their plan to implement
> the specification? Are there any reviewers that merit special
> mention as having done a thorough review, e.g., one that resulted
> in important changes or a conclusion that the document had no
> substantive issues? If there was a MIB Doctor, Media Type or other
> expert review, what was its course (briefly)? In the case of a
> Media Type review, on what date was the request posted?

To assess the applicability and usefulness of the document, a survey
about DNSSEC policy and practice statements was conducted by the authors
amongst members of CENTR (Council of European National  Top Level Domain
Registries). Among the questions were some asking whether they had heard
about draft-ietf-dnsop-dnssec-dps-framework (then at version -03).

Of the 19 respondents, 17 had heard about the draft and 13 had used it
as a check list of DNSSEC readiness and/or an outline to create such a
document.

> Personnel
>
> Who is the Document Shepherd? Who is the Responsible Area
> Director?

Stephen Morris is the document shepherd.
Ron Bonica is the responsible Area Director.


> (3) Briefly describe the review of this document that was
> performed by the Document Shepherd.  If this version of the
> document is not ready for publication, please explain why the
> document is being forwarded to the IESG.

The content of the document has been reviewed a number of times by the
document shepherd during its development.


> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed?

No.

> (5) Do portions of the document need review from a particular or
> from broader perspective, e.g., security, operational complexity,
> AAA, DNS, DHCP, XML, or internationalization? If so, describe the
> review that took place.

No


> (6) Describe any specific concerns or issues that the Document
> Shepherd has with this document that the Responsible Area Director
> and/or the IESG should be aware of? For example, perhaps he or she
> is uncomfortable with certain parts of the document, or has
> concerns whether there really is a need for it. In any event, if
> the WG has discussed those issues and has indicated that it still
> wishes to advance the document, detail those concerns here.

There was a concern about a possible copyright issue, but only in
respect to a pre-RFC5378 RFC.  Parts of RFC 3647 have been used in the
draft, so the authors have contacted the authors of RFC 3647 requesting
permission to use text from it.  All who have replied (four out of five)
have given that permission.


> (7) Has each author confirmed that any and all appropriate IPR
> disclosures required for full conformance with the provisions of
> BCP 78 and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that there are no IPR issues.


> (8) Has an IPR disclosure been filed that references this document?
> If so, summarize any WG discussion and conclusion regarding the IPR
> disclosures.

N/A


> (9) How solid is the WG consensus behind this document? Does it
> represent the strong concurrence of a few individuals, with others
> being silent, or does the WG as a whole understand and agree with
> it?

The discussions took place between a limited number of individuals, with
seven people at WGLC formally supporting the document and believing it
should proceed.


> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in
> separate email messages to the Responsible Area Director. (It
> should be in a separate email because this questionnaire is
> publicly available.)

No.


> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the
> Internet-Drafts Checklist). Boilerplate checks are not enough;
> this check needs to be thorough.

No nits have been found in the document.


> (12) Describe how the document meets any required formal review
> criteria, such as the MIB Doctor, media type, and URI type
> reviews.

N/A


> (13) Have all references within this document been identified as
> either normative or informative?

Yes.


> (14) Are there normative references to documents that are not
> ready for advancement or are otherwise in an unclear state? If
> such normative references exist, what is the plan for their
> completion?

No.


> (15) Are there downward normative references references (see RFC
> 3967)? If so, list these downward references to support the Area
> Director in the Last Call procedure.

No.


> (16) Will publication of this document change the status of any
> existing RFCs? Are those RFCs listed on the title page header,
> listed in the abstract, and discussed in the introduction? If the
> RFCs are not listed in the Abstract and Introduction, explain why,
> and point to the part of the document where the relationship of
> this document to the other RFCs is discussed. If this information
> is not in the document, explain why the WG considers it
> unnecessary.

No.


> (17) Describe the Document Shepherd's review of the IANA
> considerations section, especially with regard to its consistency
> with the body of the document. Confirm that all protocol
> extensions that the document makes are associated with the
> appropriate reservations in IANA registries. Confirm that any
> referenced IANA registries have been clearly identified. Confirm
> that newly created IANA registries include a detailed specification
> of the initial contents for the registry, that allocations
> procedures for future registrations are defined, and a reasonable
> name for the new registry has been suggested (see RFC 5226).

N/A - no IANA actions are required.


> (18) List any new IANA registries that require Expert Review for
> future allocations. Provide any public guidance that the IESG
> would find useful in selecting the IANA Experts for these new
> registries.

N/A


> (19) Describe reviews and automated checks performed by the
> Document Shepherd to validate sections of the document written in
> a formal language, such as XML code, BNF rules, MIB definitions,
> etc.

N/A