Paul, On Tue, 25 Aug 2015 18:15:02 -0400 (EDT) Paul Wouters <p...@nohats.ca> wrote:
> On Tue, 25 Aug 2015, Ólafur Guðmundsson wrote: > > > This is a proposed update the CDS/CDNSKEY processing to address the > > omission in RFC7344. > > Comment please, > > As you state, it was an omission on purpose. The document wanted to > ensure the security state was never changed from insecure <-> secure. > I believe it is useful to specify a method for those who can or are > willing to use it to do so. I agree completely. Perhaps we can add blinking red letters of warning to the draft for users? ;) > I fear a non-technical discussion to uhm ... flare up :) A well-grounded fear. > For the technical part, if we write a document that states how to go > from secure to insecure, why not just also include in that document > how to go from insecure to secure. These operations are kind of > orthogonal. Plus, we already implemented a prototype on how to do that, > so we can just write that up (minus the TXT records alternative) AIUI, CDS/CDNSKEY manipulation requires signed records, right? So that means that the person adding new CDS/CDNSKEY records has the ability to sign the zone with the private key. Going from insecure to secure does not have the same property. You can bootstrap trust, but it is from a different kind of thing. IIRC, Joao added code to the soon-to-be-expired DLV registry which used a nonce TXT record to confirm that the person adding to DLV could add TXT records to the domain. But there are several attacks which could be made that allow this (not likely, but also not possible). DNSSEC trust is not the same as "ability to update a zone". To be clear, I fully support adding such a way to bootstrap DNSSEC trust, just pointing out that it is not the same as *removing* DNSSEC trust. > I would also add a note that if you lose the private key, this document > does not help you go insecure, as an out-of-band method will have to be > used to signal that. True. Seems obvious but probably worth a note. :) > IANA would also need to update the algo number 0 from "RESERVED" to > something else - eg "NO DIGEST". -- Shane _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
