Hi Paul, On 30 Jul 2020, at 16:28, Paul Wouters <[email protected]> wrote:
> On Thu, 30 Jul 2020, Ben Schwartz wrote: > >> I do not believe that is correct. The first and foremost purpose is for >> the bit to signal the parent zone's behaviour in a public way that >> prevents targeted / coerced attacks from the parent. >> I would love to see some more description of these attacks in the draft. > > I'm a bit confused that you think describing that in more detail helps. > We are talking about fairly simple records like the .ca zone publishing: > > > nohats.ca IN DS blob + RRSIG(key of .ca) > nohats.ca IN NS ns0.nohats.ca. > ns0.nohats.ca IN A 193.110.157.101 > > while also (targetted per victim or within a certain time frame) publishing: > > _443._tcp.nohats.ca IN TLSA blob + RRSIG(key of .ca) > www.nohats.ca IN A <malicious IP> + RRSIG(key of > .ca) > nohats.ca IN MX 0 tapbox.ca. + RRSIG(key of .ca) > > But I can add this if you feel it helps. Usually when I do risk assessment exercises in order to determine what threats are worth spending money on to mitigate, we throw out those that are thought to be very unlikely to occur or very expensive to mitigate, since there are usually better things to focus on. Have you done any thought on that kind of risk analysis for this proposal? For example, has there ever been an example of this attack happening, or are the contractual or commercial pressures to behave well considered by someone to be inadequate? On the expense side, what is the cost of implementation to the degree that the mechanism actually provides some benefit? My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should succeed or fail based on anybody's uninformed sense, hence the request for more data. Joe _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
