> On 14 Feb 2024, at 03:31, Paul Wouters <p...@nohats.ca> wrote: > > On Wed, 14 Feb 2024, Roy Arends wrote: > >>> 1. There is a recommendation to use DNS COOKIEs [RFC7873] over UDP (PS), >>> but no >>> statement about how to mitigate the effects when these are not used. What >>> ought >>> someone to do when this is not done? >> >> It is recommended that the client (the resolver) sets the DNS COOKIE. The >> benefit of using cookies is for the client. It is to make sure that the >> response is genuine. > > Does it? Not for an on-path attacker that sees the COOKIE in the clear. > So what attack does this really counter?
Ah, no, apologies, it doesn’t. (I’ll blame this on my DNSSEC muscle memory). I should know better. I’ll try again: There is text in the document that specifies what the monitoring agent should do if cookies are not used: Section 6.3: The monitoring agent SHOULD respond to queries received over UDP that have no DNS COOKIE set with a response that has the truncation bit (TC bit) set to challenge the resolver to re-query over TCP. > And if using TLS, then one wouldn't need a COOKIE anymore to prove > genuineness. > >> However, there is little value in the response. The actual value for >> error-reporting is to the authoritative server that may have an issue. >> >> When cookies are not set, or are not used, there is language that states the >> following: >> >> The monitoring agent SHOULD respond to queries received over UDP that have >> no DNS COOKIE set with a response that has the truncation bit (TC bit) set >> to challenge the resolver to re-query over TCP. > > This sounds more like an attempt for a mechanism for the monitoring agent > to determine that the incoming report is not send from a spoofed address, > but it wouldn't work like that. Setting the TC would work, provided the > client comes back. Or if the monitoring agent would demand a COOKIE > before answering (even if the answer is not the actual data the resolver > wants anyway). If the monitoring agent requests a COOKIE, it would force > the resolver to resend with the COOKIE, proving it is not just a spoofed > packet. But that would always result in double the load to the > monitoring agent. A cookie may be set due to an earlier transaction, no? Roy _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
