Ralf, The "same-domain" requirement here serves two main purposes:
1. Prevent DDoS attacks. A malicious DNS server could cause a large number of clients to fetch incident reports from an arbitrary victim server. (c.f. Great Cannon [A]) 2. Block reports that transited a naive forwarder. These reports could be inauthentic, if the forwarder's upstream transport is unencrypted. We could probably develop some technical mechanism that prevents both of these attacks without the same-domain requirement. However, that may not be necessary. As Emily points out, clients (i.e. browsers) might have their own reputation systems for determining which reports can safely be displayed to the user. When the client applies its own reputation system, the same-domain requirement and central registry are both unnecessary. --Ben Schwartz [A] https://en.wikipedia.org/wiki/Great_Cannon ________________________________ From: Ralf Weber <d...@fl1ger.de> Sent: Thursday, November 7, 2024 11:25 AM To: Ben Schwartz <bemasc=40meta....@dmarc.ietf.org> Cc: Stephane Bortzmeyer <bortzmeyer=40nic...@dmarc.ietf.org>; Mark Nottingham <mnot=40mnot....@dmarc.ietf.org>; dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] Re: New Version Notification for draft-nottingham-public-resolver-errors-00.txt Moin! On 7 Nov 2024, at 15:19, Ben Schwartz wrote: > I think this proposal is promising, but I agree with Stephane that the > registry of participating resolvers is unappealing. However, I believe it is > also unnecessary. Instead, the EXTRA-TEXT can simply convey an "https://"; > URL for the Incident Description. The client can enforce that this URL's > hostname be the same as the one used to reach DNS server, ensuring > authenticity. I don’t think having the DoH server also present blocking information is a good idea. The draft does also not put any restrictions on the URI template and I would rather have my DoH servers focus on delivering DNS answers via DoH. So I think a registry is needed. What that registry is and who will be in that registry needs to be discussed. While the definition in 6.2 does not put any limit on that the last paragraph of the introduction does. A better way to limit that IMHO would be to allow only resolver operators to be added to the registries that are under regulation as only those are usually forced to block stuff and hence need the transperency. > For clients using insecure DNS, I would probably rule out this mechanism > entirely, since the authenticity of the report cannot be established. That is what draft-ietf-dnsop-structured-dns-error says in section 5.3 anyway, and this is an extension of this as I understand it. So long -Ralf ——- Ralf Weber _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
