Hi Libor,
On 6/23/23 17:21, libor.peltan wrote:
I would expect the combination of a nameserver not being reachable and the
other party being malicious to be quite a rare event.
A combination of a nameserver being unreachable and an other one being
misconfigured e.g. in the sense of Section 2.2.1 (in the -03 version of the
doc) does not seem too inprobable to me.
My take is that the likelihoods multiply, so the combination is much more
unlikely than an isolated event of either type.
That said, it's possible I'm mis-estimating the severity of such a situation,
like an operator not only serving compromised content (e.g. server hack,
expired hostname hijack), but in addition blocking traffic to another operator.
I guess if you have this combination, you're out of luck: Multi-homing protects
against failure of an operator, and indeed the draft is intended to protect
against accidental mess-ups by multi-singer peers (as reported by Matthijs) or
server takeover. OTOH, it cannot protect against an omnipresent on-the-wire DoS
attacker (in fact, nothing can) who colludes with a DNS operator.
But risk assessments may vary, and if people think this needs to be addressed,
I'm happy to (suggestions welcome!).
Given the probably much more frequent "price" of blocking DS maintenance, I
think this is the right trade-off.
If you think this is the right trade-off, you should write into the document
that this is the right trade-off, and that this consideration has been made. I
would kindly leave the exact wording on you.
I'll wait for a few days to see if there are more comments, and will then try
to find some words.
I'm not sure. Anyway, the Security Considerations section also claims "ensuring that
an operator in a multi-homing setup cannot unilaterally modify the delegation",
which is not entirely true according to me, considering the above discussion. If one
nameserver becomes (even temporarily!) unreachable, the inability of unilateral
modification is not ensured. It's only trade-off-ed :)
Point taken! I'll fix that accordingly.
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/
Ouch, it seems that in your newest version, Section 2 disappeared completely.
I'd vote for keeping the motivational prose present. Disclosing the motivations
and goals of a standard is a good habit among RFCs.
Oh yeah, I agree. It's just that the section got longer and longer, and I felt
like it takes forever until the reader arrives at the actual spec -- so I
turned that section into an appendix.
Cheers,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
