Dear colleagues, Thanks to everyone who reviewed draft-ietf-dnsop-dnssec-trust-anchor-01.txt. In this one message I've replied to several of the emails with comments. A new version (-02) of the draft should appear shortly.
See you in Dublin! Matt On Wed, 20 Feb 2008, Suresh Krishnaswamy wrote: > Section 2, last para > > # A validating resolver MAY support > #configuration using a truncated DS hash value as a human-factors > #convenience: shorter strings are easier to type and less prone to > #error when entered manually. > > There should be some guidance on the amount of truncation allowed. > For instance, can the DS hash be truncated to a single byte? > (I assume not) I've included a reference to RFC 2104 (the HMAC RFC), which includes general language about truncation for HMAC. That's not a perfect reference, though. > Section 3 : > > I don't understand the usage of the word "priming" here. The steps > that are described are *exactly* what would need to happen during > the normal DNSSEC validation process. I can see the need for priming > DNSKEYs when trust anchors are also configured as DNSKEYs (in > which case priming helps the validator determine if the configured > DNSKEYs are the same as the ones published) but I don't see the need > for priming DNSKEYs when the trust anchors are specified as DS > records. I think the priming step is equally applicable for trust anchors specified as either DS or DNSKEY records: in either case, you want to make sure what's configured in your trust anchor store matches what's in the live zone. > Or, are we instead saying here that DNSKEYs fetched through > the priming process will not be subject to TTL expiration (which, > I think, shouldn't be the case either)? No, that's not the intent. > Also in Section 3, second-last para > > # A validating resolver should remove a trust anchor > # that has been revoked as indicated by the REVOKE bit in the > # corresponding DNSKEY record as described in RFC 5011 [6]. > > We may not want to necessarily combine resolver behavior with > trust anchor management. The two are different tasks and can be > accomplished using different tools. I'd suggest simply deleting this > sentence and modifying the para to read: > > "If there are multiple trust anchors configured for a zone, any one of > them is sufficient to validate data in the zone. For this reason, > old trust anchors SHOULD be removed from a validating resolver's > trust anchor list soon after the corresponding keys are no longer > used by the zone, as described in RFC 5011 [6]." Thanks for this text. It's better and I've changed the wording in the draft. On Thu, 21 Feb 2008, Scott Rose wrote: > Just an open suggestion, but should there be more text to clarify what > happens when a zone intends to delete it's outstanding trust anchors and > link its security through its parent by having a DS RR in the parent zone? > > There is text in RFC 5011 on how a zone operator does this, but there > isn't a lot of detail in this draft. Worst case scenario is that the > validator declares the zone responses bogus, which isn't good. Well, one could argue that this document is from the perspective of the validator, not the zone operator, and therefore 5011 is the right place for the text. Also, this scenario may be tied up in the parental DS vs. configured trust anchor issue referenced below in my response to your other email. For now, I've not added any text on this. On Tue, 25 Mar 2008, Matthijs Mekking wrote: > 1. In section 4 it says that trust anchors correspond to KSKs. My > understanding is that trust anchors correspond to both KSKs and ZSKs. > I also made this comment on my review of > draft-gudmundsson-life-of-dnskey-00. We're looking at this in terms of roles. If a single key is being used as KSK and ZSK, that one key has two roles. The trust anchor term applies to the key being used in its KSK role. > 2. Some must/should/SHOULD/MUST issues: > * page 6: > "A validating resolver *should* remove a trust anchor that has been > revoked as indicated by the REVOKE bit in the corresponding DNSKEY > record as described in RFC 5011." > : I argue if this 'should' should be a 'SHOULD' :), in order to > indicate the requirement level as described in RFC 2119. We think this SHOULD should retain its 2119 meaning. > * page 7: > "Validating resolver operators *MUST* ensure that configured trust > anchors remains current and does not go stale." > : This 'MUST' must be a 'must'. Well, at least I find it strange to > use a keyword for the work of (human) operators. > "each configured trust anchor *SHOULD* correspond to a DNSKEY RR in > the trust anchor zone's apex DNSKEY RRSet." We concur; changed. > : SHOULD -> should. I think this refers to 'ought to' and not the 2119 > definition. We think this SHOULD should retain its 2119 meaning. > 3. In section 5 it says that if multiple mechanisms are updating the > trust anchor list then there is the possibility of conflict, ... > So this setting is NOT RECOMMENDED? Maybe add such a sentence. I don't think we need to go as far as NOT RECOMMENDED: there's not an inherent problem with multiple mechanisms, just a need to be aware and cautious. > 4. If you're using RFC 2119 keywords, maybe a section 'requirements > language' should be provided. There's already the standard text listing the 2119 words at the end of the Introduction (Section 1). Are you referring to something else? On Wed, 04 Jun 2008, Scott Rose wrote: > 1. Introduction > A resolver might want to maintain a zone's key as a trust anchor even if the > zone has a signed delegation. Likewise a zone may wish to distribute it's > key for use as a trust anchor in addition to having a DS RR in the parent > zone. This really doesn't change things in the document as a whole, but > something to keep in mind. As evidenced by the discussion last month on namedroppers about the proper resolver behavior when both a trust anchor is configured a DS RRSet in the parent are found, we think this issue should be punted to the bis-updates document. > Last sentence in Section 3: Should the resolver really consider zone > responses as BOGUS? What if the zone is now provably unsecure? How would the resolver know its provably unsecure? Because of a parental DS? In that case, we're back to the issue described above (dualing DS and trust anchor). Or are you referring to something else? Note that a zone can use RFC 5011 signalling to go provably unsecure. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
