On 7/31/20 2:34 PM, Paul Wouters wrote: > The process of a rogue parent is not a purely technical one. It can include a > legal system, a payment dispute, and many other things. > > Per definition, it will be a manual process to confirm if a “changed child” > is a legitimate change or not. Logging helps this process.
Right, I didn't fully realize that it's impossible to achieve that much by technical means. >> I do support the aims of the draft, but so far the plan doesn't make me >> feel safer, and deploying *all* the necessary parts doesn't seem very >> easy either. > All the necessary parts is one bit and a few lines of code and a tool option. > It’s not that much. The real work happens by log operators. I considered logging among those "necessary" parts, which might've been a bit of black&white point of view. >> I'm sorry if I've missed something. Well, *my* trust >> isn't really important here, so if dnsop thinks the approach will >> increase trust of some more important parties... > Forcing parents into mucking with their customer DS records itself is a big > win. The parent now has an Enigma Problem and is more or less guaranteed to > be found out it’s cheating it’s own published policy. Thanks, I think I see better now - so these are gradual steps to make this kind of "attacks" harder but never able to completely eliminate them (unfortunately). I agree this RFC (without logging) appears relatively cheap, so if it can improve trust, I expect the main stumbling point is willingness of important zones to deploy it (which could include some technical obstacles) and that should be better explored before publishing as RFC. Right now I can't see a better first step towards this draft's goal than the draft itself. Detail: removing that exception for the root might be nice. That sounds possible if the root KSK lifetime really becomes only a couple years (which I haven't seen promised yet). As long as the exception is there, the paragraph about the root rollover feels weird. --Vladimir _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
