Greetings again. It is quite important that there be an interoperable mechanism where a child can say to its parent "please update your DS for me" in a secure fashion. Parents don't need to implement this mechanism: they can still do the updates in non-interoperable fashions like they do today and nothing will be worse. However, to get greater deployment of DNSSEC, we need to make the operations of the DNSSEC records more automated without reducing security.
At this point, I'm unconvinced that doing the DS update through the DNS is the right method. If it is the right method, draft-ietf-dnsop-delegation-trust-maintainance is probably OK after a bit of updating. However, the flaws that both Patrik and Ed have brought up indicate that the document might need even more words, and more mechanisms, than it has now. It feels like it has the same amount of creep that NSEC and NSEC3 did. Maybe that's a good thing, but it doesn't feel that way to me. At various meetings, people have said that we should be doing this update using a real update protocol like HTTPS. I have thought that is right, but now I'm not sure. Each time I sketch that out, it is almost as complicated as this draft. Getting the authentication right will actually be harder than what is in this draft. Some particular notes on the current draft: - It says too much loosely. It can be shorted in ways that will make it less likely that people will mis-implement by taking out the off-hand remarks that are mostly about use cases. Search for "etc" and see whether those lists or whole paragraphs can be removed. - There are places that use SHOULD instead of MUST but don't explain the exceptions. Some of those places open security holes if they are not explained. Every SHOULD needs an explanation. - In Section 1, the phrase "their DS record(s) (or DNSKEY(s))" is completely unclear until you get to Section 3. Instead, until you say that there are two things that a child might tell its parent, consistently talk about "information that would cause the parent to update the DS record". Before 1.1, put a new section that describes why there are two records, admit that this might be confusing, and say that it's here because different parents want different things. But the big point is to not treat the two records as equivalent: treat them as both having the same result, that the parent will create a new DS. - The document uses "change" and "roll" for the reasons for wanting a new DS. They are different, and "roll" is a subset of "change". (A child might want a change because they are changing signing algorithms, or they might want a change because they are rolling a key within the same algorithm.) Use "change" throughout, and leave "roll" to other documents. - The text throughout would be easier to read if it used "Child DNS Operator" instead of "Child DNS operator"; same for the "Parent DNS Operator". - In 6.2, the discussion of "old version" and "new version" is completely unclear. It needs to be specific about what the contents of a "version" is. --Paul Hoffman _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
