On Apr 23, 2013, at 1:16 PM, Paul Hoffman <[email protected]> wrote:
> On Apr 23, 2013, at 9:39 AM, Paul Wouters <[email protected]> wrote: > >> I get it, you don't like the concept. So don't use it. For those who _do_ >> like the concept, let's get to a specification that can be useful to most >> without crippling the basic use case of "using an existing authenticated >> trust relationship in-band to the DNS for automated updates of the DS >> record" (and/or NS/GLUE records) > > Except that this thread has brought out many problems in the -01 draft that > will likely result in changes that will make CDS special, not just like other > records. At that point, you will have to decide if having a CDS record is a > better idea than just re-using DS. The first rule of protocol extensions is "avoid harm" to existing systems. Reusing DS at child side of delegation is likely to cause harm. In order to signal TA changes in-band thus has to be done either using new RRtype or only DNSKEY records. >From a regular validator perspective CDS is a normal record, that is signed by >a key that is in the DNSKEY RRset thus it validates like any any other record. A system that consume CDS records as a matter of Trust Anchor Maintenance require special rules before using the records content to update trust anchors these rules are likely to apply to any other mechanism used in-band. Mandatory Rules are: - signed by one of current trust anchor(s) - applying new trust anchor(s) will not break chain of trust - absence of CDS implies NO change in Trust Anchor Optional Rules: - accept after delay similar to RFC5011 - accept only if DNSKEY contains all keys referred to in the CDS - accept only if DS algorithms are "acceptable" - accept if there is a <push action> by "child" If you agree with the mandatory rules and a subset of the optional rules then you agree with the basic premise of the next version of the draft that will be much clearer on what is Required and what is Optional. Olafur _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
