This is a discussion on Re: WGLC on trustudpate-timers - DNS ; First, my appreciation to MSJ for the excellent editting job. I found a couple of minor things in the doc that I'd like to see clarified. While it would be better to do that before sending the doc to the ...
First, my appreciation to MSJ for the excellent editting job.
I found a couple of minor things in the doc that I'd like to see
clarified. While it would be better to do that before sending the doc
to the IESG, my only objection to advancing the doc now is the
discrepancy in section 2.3 identified by Wouter and Lindy. In
particular, the second sentence of 2.3 seems inconsistent with the
rest of the doc.
I'll start with the disucssion of how I think this technique stacks up
against the requirements (identified by the section number in the
requirements draft), then I'll list the textual clarifications I'd
like to see.
I think this doc satisfies these requirements:
5.3. General Applicability
5.4. Support Private Networks
5.7. Planned and Unplanned Rollovers
5.10. New RR Types (unclear requirement, but no new RR type needed)
5.11. Support for Trust Anchor Maintenance Operations
(accomplishes replace w/ separate add/delete)
5.12. Recovery From Compromise
5.13. Non-degrading Trust
I think both of the following are satisfied, though more text about
them would be good:
5.5. Detection of Stale Trust Anchors
5.6. Manual Operations Permitted
I'm concerned that limits on the size of the apex DNSKEYset will
prevent keeping around a sufficient number of revoked DNSKEYs to fully
5.9. High Availability
(but I don't think we need to do anything about this now)
I make no comment on this requirement:
5.2. No Intellectual Property Encumbrance
2535 is listed as a normative reference, but it's obsolete. Remove it
As above, considering adding more text re: how to satisfy requirements
5.5 and 5.6. That said, if it weren't for reading both this doc and
the requirements doc in one sitting, I wouldn't think this document
needed such text.
Section 6: "The stand-by key will not normally sign this RRSet, but
the resolver will accept it as a trust anchor if/when it sees the
signature on the trust point DNSKEY RRSet."
Which signature? It's own? The "NewKey" event description makes it
sound like just adding the SEP key to the signed DNSKEYset is enough
to get resolvers to pick it up. Once it's picked up, it could even be
used to sign data in the zone (used as a ZSK) even without
self-signing the DNSKEYset, right?
How about: "Even though the stand-by key will not normally sign this
RRSet nor any other data in the zone, but the resolver will accept it
as a trust anchor. Accordingly, it could be used to sign the DNSKEY
RRset or any other zone data." ?
The phrase "SEP key" is used, with a reference to 4034, but 4034
doesn't define "SEP key". It would be more correct, and perhaps less
confusing, to say "a DNSKEY with the SEP bit set". Make that
In the "Valid" state: "If the RRSet ..." Which RRset? How about "If
a DNSKEY RRset..." Yes, it's slightly redundant.
"Alternately, a trust point which is subordinate to another
configured trust point MAY be deleted by a resolver after 180 days
where such trust point validly chains to a superior trust point.
The decision to delete the subordinate trust anchor is a local
configuration decision. Once the subordinate trust point is
deleted, validation of the subordinate zone is dependent on
validating the chain of trust to the superior trust point."
The word "to" in the above assumes a "bottom-up" logical model of
validation, which is not the one I'm most familiar with seeing in
writing. Perhaps a change is in order?
The abstract says "the method provides protection against single key
compromise", but 8.2 says "This scheme permits recovery as long as at
least one valid trust anchor key remains uncompromised." While these
aren't necessarily contradictory, they come close.
Section 1: "a resolver may need to know literally thousands of trust
anchors to perform its duties." is inconsistent with the requirements
doc: "never expected to be as high as one thousand." I prefer this
version; change the other doc.
Section 8.1: "This implies the decision update trust anchor keys based
on trust for a current trust anchor key is also the resolver owner's
There's something missing in that sentence.
The doc still flags as a "discussion item": "Should a missing key be
considered revoked after some period of time?" Might want to remove
that before sending it to the IESG.
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.