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? Cheers, -- Mark Nottingham https://www.mnot.net/ _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
