Dropping last-call and others from distribution... > On 12 May 2025, at 8:54 pm, Paul Wouters <[email protected]> wrote: > >> The draft explicitly recognizes this risk and includes guidance to mitigate >> it. Specifically, as discussed in the Security Considerations section: >> “A client might choose to display the information in the 'c' field to the >> end-user if and only if the encrypted resolver has sufficient reputation, >> according to some local policy (e.g., user configuration, administrative >> configuration, or a built-in list of respectable resolvers)...” >> This is intended to prevent clients from blindly displaying contact >> information, such as those found on potential attacker-controlled networks. > > But the draft is just punting this problem from the protocol specification to > the protocol implementers. It’s not only the contact data but also the extra > text that’s a freeform text attack vector. >> >> >> The goal is to preserve user safety by ensuring that only trusted resolvers >> can supply user-facing details. > > As previously said, this creates a central choke point of trustee dns that > works “better” then untrusted dns and causes centralization of dns followed > by centralization of censorship.
This seems like a good place to focus discussion. First, two things that I don't _think_ are being disputed: 1. Surfacing censorship events to end users is desirable, because it a) avoids user confusion / misattribution of the problem, and b) allows end users to be more fully informed. This is becoming a more urgent problem, thanks to current events. 2. Allowing untrusted network elements to display messages to the end user is an attack vector that needs to be mitigated. If anyone disagrees with either of the above, please say so. (2) leads to designs where the ability to display messages is gated somehow. Both my draft and (AIUI, based upon the above) the structured DNS error draft have a notion of 'trusted' DNS resolvers that has privilege over 'untrusted' DNS resolvers, as a mitigation to this kind of attack. Paul, you say above that this approach can lead to outcomes where there is centralisation in both DNS and censorship. I agree that doing so creates a different experience -- users of 'trusted' resolvers will presumably see clearer error conditions when censorship is happening. However, whether that difference amounts to an advantage that is so great that it creates overwhelming pressure to use such resolvers is questionable. Many users will be unaware of the difference at all; even those that care about censorship only benefit to the degree that they know censorship is happening. There is no economic or functional advantage beyond that knowledge. Even if such pressure does eventuate, it's questionable that it would result in centralisation -- i.e., whereas those DNS resolvers would become more of an effective choke point for control than they are today. That's because users can easily switch between resolvers if they choose to; DNS is a standard protocol with multiple implementations and multiple deployments. Today people can (and do) use their ISP or other local network resolver, use a public resolver, or deploy their own resolver. Note that I'm using 'centralisation' in a way that's distinct from 'concentration' -- but again, even if the concern is concentration in the DNS resolver market, it's hard to see this information making a significant difference in that market. Yes, some censorship-aware folks might decide to deliberately configure a DNS resolver, but that's hardly going to move the needle on concentration. If I'm missing something here or otherwise misjudged it, please point out what/how. If someone has an idea for a way to mitigate (2) in a different fashion, I'm all ears. You also talk about 'centralisation of censorship.' I'm not sure what you mean there, but am guessing that you're concerned that censorship might become easier, based upon: > Will the “trusted” DNS start refusing the .gl TLD soon because of a mad king ? If that's the case, I don't see how proposals along this line change the outcome. If a government in a given jurisdiction wants to censor, they will censor. Providing a mechanism for resolvers to making the details available to citizens who are affected by that censorship so as to inform their participation in the democratic process (assuming they're lucky enough to live in a jurisdiction that allows that) is the best we can do. When I started this work, I had a latent concern that defining mechanisms like this would encourage censorship because it 'blesses' a path for courts (etc.) to use. We're well past that now -- courts, legislatures and policymakers around the world are now regularly blocking content using a variety of (often technically bad) methods. The best outcome is one where that activity does as little collateral damage as possible, and its operation is made as clear as can be to those who it affects. Cheers, -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
