Subject: [Gen-art] Gen-ART review of draft-ietf-dnsop-dnssec-dps-framework-08

From: "Peter Yee" <[email-masked]>
Date: Sat, 14 Jul 2012 18:01:57 -0700

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

This draft is ready for publication as an Informational RFC.

Document: draft-ietf-dnsop-dnssec-dps-framework-08
Reviewer: Peter Yee
Review Date: 14-July-2012
IETF LC End Date: 17-July-2012
IESG Telechat date: Pending

Summary: This draft provides a framework for the creation of DNSSEC Policies
and Practice Statements. 

Major Issues: None

Minor Issues: 

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.  Of course, that might be considered a meta issue
and outside of the scope of the DP or DPS proper.

Nits/editorial comments: 

In Section 4.6, "behaviour" is spelt in the British manner.  While
most assuredly not incorrect, you may wish to spell it in the
American manner.

Serial commas are used inconsistently.  Nothing as egregious as the
following
example, however. ;-)
http://grammarnowtips.wordpress.com/2011/01/08/a-case-for-the-serial-comma/

---

From: Russ Housley <[email-masked]>
Date: Sun, 15 Jul 2012 11:39:12 -0400

Peter:

Thanks for the review.  I've not read this document yet, but you review raises a question in my mind.

If a DNSSEC policy or practice statement is revised or amended, what actions are needed make other aware of the change?

Russ

On Jul 14, 2012, at 9:01 PM, Peter Yee wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Joe Abley <[email-masked]>
Date: Mon, 16 Jul 2012 18:33:52 -0400

Hi Russ,

> If a DNSSEC policy or practice statement is revised or amended, what actions are needed make other aware of the change?

Each DPS contains these kinds of details. Guidance for how to write the corresponding DPS sections is included in this draft:

4.2.  Publication and repositories

   The component describes the requirements for an entity to publish
   information regarding its practices, public keys, the current status
   of such keys together with details relating to the repositories in
   which the information is held.  This may include the responsibilities
   of publishing the DPS and of identifying documents that are not made
   publicly available owing to their sensitive nature, e.g. security
   controls, clearance procedures, or business information.

4.2.1.  Repositories

   This subcomponent describes the repository mechanisms used for making
   information available to the stakeholders, and may include:

   o  The locations of the repositories and the means by which they may
      be accessed;

   o  An identification of the entity or entities that operate
      repositories, such as a zone operator or a TLD Manager;

   o  Access control on published information objects.

   o  Any notification services which may be subscribed to by the
      stakeholders;

Joe

---

From: Russ Housley <[email-masked]>
Date: Tue, 17 Jul 2012 19:06:44 -0400

Joe:

I think you missed my point.  In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier.  I do not see a similar concept here.

Russ

---

From: Joe Abley <[email-masked]>
Date: Tue, 17 Jul 2012 19:32:16 -0400

Hi Russ,

> I think you missed my point.  In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier.  I do not see a similar concept here.

You're right, I did miss your point, quite thoroughly :-)

I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendant CA policy and hence perhaps am still misunderstanding what you're looking for. 

Joe

---

From: Russ Housley <[email-masked]>
Date: Wed, 18 Jul 2012 11:49:02 -0400

> I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendant…

So a DNSSEC signer starts under one set of documents, and then for whatever reason, the policy changes and the parties validating the signature have no means to determine that the signer is following a new policy.  So I am missing the value of the policy to the parties that rely on these signatures.

Russ

---

From: Stephen Kent <[email-masked]>
Date: Wed, 18 Jul 2012 11:55:28 -0400

Joe
>> I am guessing that the answer is that there's no corresponding facility in DNSSEC to for a policy identifier to be published with a DNSKEY RR, but I say that largely ignorant of X.509 and attendan…

In X.509 each cert can contain a policy OID that indicates the policy 
under which the cert was issued. Thus, when a CA changes it's policy it 
can issue certs under the new policy with the new policy OID. This makes 
it clear to relying parties what policy is in effect, and when a CA 
changes its policy, irrespective of
other changes, e.g., key rollover.

Steve

---

From: Joe Abley <[email-masked]>
Date: Wed, 18 Jul 2012 14:09:26 -0400

On 2012-07-18, at 11:49, Russ Housley wrote:

> So a DNSSEC signer starts under one set of documents, and then for whatever reason, the policy changes and the parties validating the signature have no means to determine that the signer is following a new policy.

They have means, they just don't have a way of deriving a specific policy from a specific DNSKEY. The available means are documented in the DPS.

> So I am missing the value of the policy to the parties that rely on these signatures.

Your suggestion is that if there's no way to the policy just from the contents of a DNSKEY RR, there's no point publishing a policy at all?

Joe

---

From: Fredrik Ljunggren <[email-masked]>
Date: Thu, 19 Jul 2012 09:42:11 +0200

> I think you missed my point.  In a PKI, when the issuer significantly changes the policy, subsequent certificates have a different policy identifier.  I do not see a similar concept here.

Russ, you are right. There is no such concept in DNSSEC (yet). Simply by looking at the signed data, there is no way of determining under what policy the data has been signed. Interested parties must stay informed using the process specified in section 1.4.3 (Specification change procedures) of the DPS.

Generally speaking, DNSSEC signatures are short-lived. From the time a new policy is in effect, old signatures will be flushed out within days. However, if there are significant changes made to the policy which materially affect the security posture of the zone, there may be several reasons to roll the signing key(s) and to indicate this in the DPS. This way, the validating party will be able to determine under what policy a signature has been generated, and act accordingly.

- Fredrik