Hi Libor, all, On 6/22/23 11:42, libor.peltan wrote:
here are my comments to draft-thomassen-dnsop-cds-consistency-03.
Thank you very much!
"In all cases, consistency is REQUIRED across received responses only. Nameservers that appear to be unavailable SHOULD be disregarded as if they were not part of the NS record set." I don't feel confident about the consequences of this cathegorical statement. What if you have two DNSSEC providers, one has an outage (or just network breakage between them and the polling entity), and the other one maliciously takes over by publishing new CDNSKEYs? The polling entity might re-query several times from different locations, but this is usually only performed when bootstrapping the scure delegation, not when already established. And even if, it's not clear if (when) this would be enough. I understand, on the other hand, that relying on permanently disfunctional (or lame in any meaning of that word) child NSs might be problematic. To sum this up, if this is an issue in the proposed method, it should be fixed, and if it isn't, it should be more verbosely described why. The document seems too brief in this regard.
The SHOULD statement was added based on a concern Viktor voiced at one of the last IETF meetings, saying that if a nameserver is unreachable from the parent, this would permanently block DS maintenance. (A well-taken point, I think.) I would expect the combination of a nameserver not being reachable and the other party being malicious to be quite a rare event. Given the probably much more frequent "price" of blocking DS maintenance, I think this is the right trade-off. Where would you suggest to put more words about that? (Right there, or in the Security Considerations? Which words?)
"CDS/CDNSKEY records at the Child zone apex MUST be fetched ... with DNSSEC validation enforced." Isn't this sentence disabling secure delegation bootstrapping?
Yes, good catch! I addressed it in this commit: https://github.com/peterthomassen/draft-ietf-dnsop-cds-consistency/commit/7939107aebb4e4963367e1d7fd831d14f98dab27#diff-d3398566f77572362e657e31e035a0effbe92148ba122be28de37a177732f318 Also, I addressed all other comments received so far in response to the adoption call (commits in same repo). For convenience, see the editor's copy: https://peterthomassen.github.io/draft-ietf-dnsop-cds-consistency/ Best, Peter -- https://desec.io/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
