Re: [DNSOP] draft-ietf-dnsop-delegation-only: exchanging DS set
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
Re: [DNSOP] draft-ietf-dnsop-delegation-only: exchanging DS set
On Jul 31, 2020, at 05:06, Vladimír Čunát wrote: > > Hello dnsop. > > So far it's been clear. But now... how do we know that this fake > victim.evil DS set was not submitted by the registrant? I assume every > registrant is supposed to watch the logs from everyone for such fakes? > Sounds OK-ish, so if they do find an incorrect set, they know that the > registry is "bad" (intentionally or not), but how can they prove *to > anyone else* that they did not submit it to the registry? A few things could be done. The client could publish a CDS set which would never include the rogue DS. The log could look and explicitly warn for “fast DS changes and undo”, since this would be flipping back and forth. 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. But remember, forcing a rogue parent into this mode is already a win we currently don’t have. > Without that ability I'd still feel quite powerless as a registrant, and > I currently can't see a nice way of solving that. It would be nice if > there was a way we could get the ability in future (for reasonable costs). Some DS flip flopping can be detected so a warning can be issued to the registrant or a public entity. So the registrant isn’t entirely powerless. But contacting the registrant is still tricky if you cannot trust the info from the parent (eg whois) > 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'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. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-delegation-only: exchanging DS set
Hello dnsop. Let me start a simple thought experiment - attacking the planned scheme. It feels like I'm missing some part of the defense. A .evil registry is using the DELEGATION_ONLY flag. They additionally sign a different victim.evil DS set, say adding hash of a DNSKEY they generated themselves. Now they could serve it e.g. to specific targets, allowing .evil to control contents of the victim.evil subtree as seen by those targets. The defense against this will be logging! So this DS set along with its proof chain should get logged by some of the targets. So far it's been clear. But now... how do we know that this fake victim.evil DS set was not submitted by the registrant? I assume every registrant is supposed to watch the logs from everyone for such fakes? Sounds OK-ish, so if they do find an incorrect set, they know that the registry is "bad" (intentionally or not), but how can they prove *to anyone else* that they did not submit it to the registry? Without that ability I'd still feel quite powerless as a registrant, and I currently can't see a nice way of solving that. It would be nice if there was a way we could get the ability in future (for reasonable costs). - - - 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. 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... --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
