Subject: comments on rollover-requirements-02

From: Wes Hardaker <[email-masked]>
Date: Tue, 11 Jul 2006 11:42:39 -0700

Section 3, paragraph 1, 2nd-to-last-sentence, nit-level: *very minor*
  You are not trusting a RR.  You're trusting the keying material or a
  hash of it.  There isn't a requirement that you need to trust an RR
  per say, but instead you trust the contents of what an RR embodies.
  You trust the key and associated parameters with how to use it.
  note nit-level: very minor.

Section 3, paragraph 2:

  OLD:
     be used as a Trust Anchor.  Thus the signed zone operation that
     created and/or published a DNSKEY RR (or DS RR) will likely not know
     if any of the DNSKEY RRs or DS RRs associated with their zone are

  NEW:
     be used as a Trust Anchor.  Thus the signed zone operation that
     created and/or published a DNSKEY RR (or DS RR) will may not know
                                                          ^^^
     if any of the DNSKEY RRs or DS RRs associated with their zone are

  I don't like being presumptive about what an operator may or may not
  experience.  "likely" makes a prediction that may or may not fall
  true.  I'd even argue that if I was going to make a prediction I'd
  actually predict that a large percentage of zone operators will know
  that they're keys are being used as trust anchors.

Section 4: entirety
  I really don't think that an alphabetically ordered list is as
  useful as an ordered list. I'd put terms that depend on other terms
  last.  (eg, the emergency terms should appear after the
  non-emergency equivalents).

  It makes reading it much easier when someone is not as familiar with
  the material.  I can offer an ordering suggestion if you want it.

Section 4: trust anchor
  I'm not happy with the wording in the first sentence as it was hard
  to parse, but I don't have a suggested replacement.  It looks better
  now, but in my first reading it confused me.

Section 5.1 Scalability:

  The two paragraphs sort of define two requirements.  I'd prefer the
  second one be separately numbered (5.1.1 and 5.1.2 would be
  better).  This makes referring to half of the issue a bit easier.

  The second one is a different scalability problem and could be
  easily retitled "Support for a Large Number of Trust Anchors"

Section 5.1 Scalability, second paragraph;

    "The number of Trust Anchors that might be configured into
    any one validating security-aware resolver is not known with
    certainty at this time but in most cases will be less than 20 and
    never expected to be as high as one thousand. "

  I'm not sure I hold this to be true or not.  I don't honestly know
  what the outcome of deployment will be.  If a single high-level TLD
  fails to deploy (cheap) DNSSEC support to its children I could very
  easily see a large number of leaf-of-faith style key-adoption that
  could extend to a large number of trust anchors being used.

section 5.3:
  Does this include complex split-view scenarios?

section 5.5:
  OLD:
   The Trust Anchor Rollover solution MUST allow a validating security-
   aware resolver to be able to detect if the DNSKEY or DS RR(s) can no
   longer be updated given the current set of actual trust-anchors so
   that initial trust may be re-established

  NEW:
   The Trust Anchor Rollover solution MUST allow a validating security-
   aware resolver to be able to detect if the DNSKEY or DS RR(s) can no
   longer be updated given the current set of actual trust-anchors so
   that it is known that initial trust must be re-established
        ^^^^^^^^^^^^^^^^               ^^^^

section 5.10:
  I think you actually want to talk about weighing general
  modification to the protocol, not just RR types.

section 6 (sec considerations):
  Maybe add something like "Solutions built based on these
  requirements will tackle a security problem, but this document does
  not guarantee that building a solution that solely solves these
  requirements alone will be secure"

  I don't like that wording either, but hopefully you'll understand
  the point?
-- 
Wes Hardaker
Sparta, Inc.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>