Last summer I believed that this draft was vitally important, but, and as the editor’s know, I am less optimistic.
Below is a minor nit to start and then trying to re-write (for my benefit) the protocol this is describing. I did the latter to try to clean up a lot of loose language and in the process found three red flags. I’m not saying don’t publish this - it isn’t standards track. (Is there still an experimental track?) But in the name of protocol specifications, there are a number of places this can be cleaned up. Even if it won’t scale (because not everyone cares about zones with over a million cut points), I can’t see who interoperable code can be written with so many loose ends. On Apr 2, 2014, at 15:07, Tim Wicinski <[email protected]> wrote: > Greetings, > > This is the starting of the WGLC on Automating DNSSEC delegation trust > maintenance. This was briefly covered in London and these are ready for > WGLC. The current versions of this documents can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/ > > http://www.ietf.org/id/draft-ietf-dnsop-delegation-trust-maintainance-03.txt >3. CDS / CDNSKEY (Child DS/ Child DNSKEY) record definitions > > This document specifies two new DNS RRtypes (CDS and CDNSKEY) that > indicates what the Child wants the parent's DS RRset to contain. ... Poorly written and leads to the wrong interpretation. I would read the above to say that SLD.example. will use these to types to indicate what it wants example./IN/DS to be. A suggested fix: "This document specifies two new resource records, CDS and CDNSKEY. These records are used to convey, from one zone to it’s parent, the desired contents of the zone’s DS resource record set residing in the parent zone." >4.1. CDS / CDNSKEY processing rules > > If there are no CDS / CDNSKEY resource records in the child, this > signals that no change should be made to the current DS set. This > means that, once the child and parent are in sync, the child DNS > operator MAY remove all CDS records from the zone. > > Following acceptance rules are placed on the CDS / CDNSKEY records as > follows: > > o Location: "the CDS / CDNSKEY record MUST be at the child zone > apex". > > o Signer: "MUST be signed with a key that is represented in both the > current DNSKEY and DS RRset's." > > o Continuity: "SHOULD NOT break the current delegation if applied to > DS RRset" > > If any these conditions fail the CDS / CDNSKEY record MUST be > ignored. Particularly the rule for the signer. (To disclose some background - I’ve voiced displeasure about this before.) Before you laugh at how long this is, how late this is in the process, this is how I would break down the protocol being specified. I think it’s close to what is in the draft, but, written this way, makes be dubious that this is a stable protocol. (E.g., what action do DNS servers and clients take when a record MUST be ignored?) In the spirit that the CDS/CDNSKEY records are said in section 3 to be “regular RR types” and that in RFC 4035 there’s no mention of checking for the SEP flag in validation (section 5.3.1), the MUST represents a fracture to me. I propose that the rule be changed to this: The CDS/DDNSKEY set MUST be signed and validated as any other RRSet in the zone (except for the zone’s own DNSKEY set) for the purposes of DNSSEC processing. In addition, to indicate that the record set is authorized to convey a new secure entry point, the signer MUST also include a signature generated from a key that is in the zone’s DNSKEY and DS sets. This signature MUST be validated before the change to the current DS set is authorized. The wording in there is a bit funky because the passage above is not using what I’d call “standard” terminology. The “Signer” I assume to be the child zone signature generation process. ——Okay, at this point, I couldn’t resist mashing this into a specification of a protocol: If were to rewrite 4.1 more radically: 4.1 Processing Rules (Note - some of these appear in later sections of the document, not always the way I say them here.) The processing rules apply to both ordinary DNS protocol operations (query/response, zone transfer) and to the application-specific nature of these records. I.e., these records are used as input to the process of generating a zone’s contents which is sometimes called provisioning. It is for this latter purpose that special rules exist. 4.1.1. Publication Rules An owner of a CDS RR set MAY also own a CDNSKEY RR set. In general practice, only one or the other SHOULD be present, but there may be cases when both are needed. The owner of a CDS/CDNSKEY RR set SHOULD be in the process of requesting a change to the owner’s DS RR set. An owner MAY retain a CDS/CDNSKEY once the request has been granted but this will cause unnecessary processing by the parent. (RED FLAG #1) A CDS/CDNSKEY set MUST be owned by a child zone’s apex in order to be considered a request to change the child’s DS RR set. Other names MAY own a CDS/CDNSKEY set but such sets have no meaning and are ignored by provisioning systems. A CDS/CDNSKEY set MUST be signed as a set within the zone, subject to the rules in section 2 of RFC 4035. A CDS/CDNSKEY set MUST (also) be signed by a key that is currently represented in the owner’s DNSKEY set and owner’s DS set held at the parent. Once the owner’s DS set appears to conform with the contents indicated in the CDS/CDNSKEY set, the CDS/CDNSKEY set SHOULD be removed. If, after an undefined extended period of time the owner’s DS set does not conform with the contents indicated in the CDS/CDNSKEY set, out-of-band means are to be taken to discover why this is the case. (RED FLAG#2) 4.1.2 Processing Rules If a CDS/CDNSKEY set fails ordinary DNSSEC validation rules, it is to be ignored. If a CDS/CDNSKEY set is owned by a child zone and is signed by key that is currently represented in the child’s DS RR set, the provisioning system is to begin the process of handling a DS RR set change. If a CDS/CDNSKEY requested state matches the existing state, processing is to be aborted. If a CDS/CDNSKEY requested state would lead to no child-owned DNSKEY matching any key indicated in the child DS RR set, processing is aborted. (RED FLAG #3) Once appropriate authentication, authorization, and sanity checks pass, the parent MUST change the child’s DS RR set to the state described in the CDS/CDNSKEY. RED FLAG #1 - allowing a set to remain (or by being unable to enforce removal) means it is trivial to DOS the parent. If there are a lot of signed delegations and each have these records all the time, the parent will have to go through the motions just to discover it’s a no-op. RED FLAG #2 - as one could imagine, without a feedback loop, “silence” is not a good way to indicate “no, wrong, buzz.” RED FLAG #3 - this step means the parent has to retrieve child records. What if the child servers are out of synchronization, what if the child is spinning in the “no change, just wait” rule above. I dare say that trying to put this protocol into code would be very difficult.
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
