On Tue, Aug 25, 2015 at 11:02 PM, Shane Kerr <sh...@time-travellers.org> wrote:
> 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? ;) > > 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". > I think writing a document on acceptable ways to establish trust a useful document but that at this point has no protocol implications for CDS/CDNSKEY that I can see, thus I prefer to not include that in this simple protocol document. Establishing the initial trust is one of the goals of the auto-DS work that some of us are experimenting with. > 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. :) > > Will add a note to that extent basically list cases in where you can not use this to go unsigned. > > IANA would also need to update the algo number 0 from "RESERVED" to > > something else - eg "NO DIGEST". > You are right I need to update the document to reflect the use of 0 as digest algorithm in DS as the examples stand, not just the DNSKEY algorithm number. I guess we could say "CDS 0 0 X" where X is the algorithm in the current DS record, but that makes limited sense. Q: is it better to use DNSKEY algorithm 0 as: DELETE flag in CDS/CDNSKEY or should we reserve a different Algorithm code that for that? Olafur
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
