Subject: Re: comments on rollover-requirements-02

From: Robert Story <[email-masked]>
Date: Wed, 12 Jul 2006 13:58:35 -0400

On Tue, 11 Jul 2006 11:42:39 -0700 Wes wrote:
WH> section 5.5:
WH>   OLD:
WH>    The Trust Anchor Rollover solution MUST allow a validating security-
WH>    aware resolver to be able to detect if the DNSKEY or DS RR(s) can no
WH>    longer be updated given the current set of actual trust-anchors so
WH>    that initial trust may be re-established
WH> 
WH>   NEW:
WH>    The Trust Anchor Rollover solution MUST allow a validating security-
WH>    aware resolver to be able to detect if the DNSKEY or DS RR(s) can no
WH>    longer be updated given the current set of actual trust-anchors so
WH>    that it is known that initial trust must be re-established
WH>         ^^^^^^^^^^^^^^^^               ^^^^

I think the original wording is fine, but the fact that Wes read it
differently than is indicative that it should be make clearer. Wes'
rewording is fine (if you add a comma):

    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

Or a slight re-org of the sentence preservers the original idea without
the ambiguity.

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

-- 
Robert Story
SPARTA

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Fri, 14 Jul 2006 18:40:56 -0400

On Jul 11, 2006, at 2:42 PM, Wes Hardaker wrote:

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

Um. The current text is in keeping with RFC 4033 (definition for  
Trust Anchor). I can make the change if required although I feel that  
folks reading the document will know what we're talking about.

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

Will change this.

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

I've re-ordered this to:

o Trust Anchor
o Initial Trust Relationship
o Trust Anchor Distribution
o Trust Anchor Maintenance
o Trust Anchor Revocation and Removal
o Trust Anchor Rollover
o Normal or Scheduled Trust Anchor Rollover
o Emergency Trust Anchor Rollover
o Emergency Trust Anchor Revocation

Reasonable?

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

I could include text from RFC 4033 to make it look like this:

    Trust Anchor: From RFC 4033, "A configured DNSKEY RR or DS RR  
hash of
       a DNSKEY RR.  A validating security-aware resolver uses this
       public key or hash as a starting point for building the
       authentication chain to a signed DNS response. "
       Additionally, a DNSKEY RR or DS RR hash of a
       DNSKEY RR is associated with precisely one point in the DNS
       hierarchy, i.e., one DNS zone.  Multiple Trust Anchors MAY may be
       associated with each DNS zone and MAY be held by any number of
       security-aware resolvers.  Security-aware resolvers MAY have  
Trust
       Anchor(s) from multiple DNS zones.  Those responsible for
       operation of security-aware resolvers are responsible for
       determining which RRs will be used for Trust Anchors by that
       resolver.

Is this better?

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

I'm hesitating to make any changes to the requirement identifiers at  
this stage (unless of course the WG decides to replace or drop any of  
the requirements) since much of the comparison/evaluation of  
proposals has already taken place based on them. Since the general  
idea being conveyed in this requirement is that of 'scalability' do  
you think you could live with the existing text?

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

Is the suggestion, then, to drop this portion (which could be easily  
done, of course)?

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

yes, presumably.

> section 5.5:
>   OLD:
>    longer be updated given the current set of actual trust-anchors so
>    that initial trust may be re-established
>
>   NEW:
>    longer be updated given the current set of actual trust-anchors so
>         ^^^^^^^^^^^^^^^^               ^^^^

I've used Robert's suggestion of using the punctuation after 'trust- 
anchors'.

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

Is the following text reasonable?

5.10.  New RR Types

    If a Trust Anchor Rollover solution requires new RR types or  
protocol
    modifications, this should be considered in the evaluation of
    solutions.  The Working Group needs to determine whether such  
changes
    are a good thing or a bad thing or something else.

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

I think I understand your point but I'm not exactly sure why we're  
trying to say this :)

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