On Fri, 20 Feb 2026 at 08:42, Mark Nottingham <[email protected]> wrote: > Hi Tiru, > > Thanks for the responses. One followup below. > > > On 19 Feb 2026, at 5:32 pm, tirumal reddy <[email protected]> wrote: > > > >> - Section 5.3 step 2 requires the use of encrypted DNS, otherwise the > extra information is thrown away. Conceivably, some clients may have enough > information available to trust non-encrypted DNS at some future time. I > agree with the notion that the client should evaluate the context of the > DNS resolver and make decisions based upon that regarding how to use the > information -- and that definitely involves whether the connection is > encrypted -- but baking it into the algorithm like this precludes them from > any future flexibility, no matter what the use case. > >> > >> If WG consensus on this is firm and fully informed, so be it, but I > thought I heard an indication that there was a subtle shift away from such > draconian measures in the discussion on Monday. > >> - Similarly, 5.3 step 6 puts constraints on the information available > to clients who have enabled a DoT opportunistic privacy profile. This > likewise seems to take any discretion out of the client's hands and bakes > it into the algorithm. > >> > >> - Same question for step 7 regarding opportunistic discovery. > > > > The reason for this strict requirement is that DNSSEC does not protect > the EDE option. If we allow the EXTRA-TEXT field to be processed over > plaintext, an on-path attacker can inject EDE. Without transport > encryption, there is no way to verify that the structured error actually > came from the resolver. > > So, is the threat model here that a network attacker wishes to convince an > application (and/or its user) that the DNS response is being filtered, and > then do what? >
An attacker could falsely label a legitimate site as malicious via injected EDE metadata, thereby misleading the end-user. -Tiru > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
