>From the browser engineer perspective: - I agree that a registry of some sort is needed. I don't necessarily envision that the registry would contain public resolver URLs (or at least not exclusively resolver URLs) but rather entities like public legal databases or transparency reports. Because this information is intended to go into trusted browser UI, we don't want to allow the resolver to provide an arbitrary URL. I'm not too concerned with how the registry is moderated because I imagine that browsers would apply their own discretion to filter the registry contents and only use entities that they are comfortable linking to in the browser UI.
- I'm not sure we'd want to limit it to DoH only. That's a relatively small portion of our userbase, and the mechanism is designed specifically for the incident data to be untrusted. There's not much (?) incentive for an attacker to inject a fabricated filtering incident. Emily On Thu, Nov 7, 2024 at 11:25 AM Ralf Weber <d...@fl1ger.de> wrote: > 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
