> On Jul 8, 2025, at 5:39 PM, Peter Thomassen <[email protected]> > wrote: > > On 6/24/25 21:37, Ben Schwartz wrote: >> 1. An attacker could strip the SVCB record and its RRSIG, resulting in an >> ordinary delegation response that would be accepted and used without >> encryption. > > While that is true, the same attacker can also prevent RFC9539-style > opportunistic probing, by blocking the port or sending weird traffic. If > that's deemed an OK threat model (for opportunistic encryption), I think the > same applies here.
The security here is opportunistic, just like RFC 9539. I agree that it’s not weaker than RFC 9539. > Also, such stripping is more easily observable via standard DNS queries (and > looking for the additional SVCB record, e.g., using RIPE ATLAS). It sounds like you’re arguing that the attack in this case has less plausible deniability? Perhaps, but in either case there is no trivial way to identify the attacker. > It may be more difficult to directly compare reachability of port 853 from > other vantage points, both because other network reasons may be at fault, and > because the observer needs more capabilities (does RIPE ATLAS support that?). I don’t think it’s more difficult. “Can I reach port 853?” seems easier than “Did the delegation response from this address include a SVCB record in the additional section?”. Overall, my view is that RFC 9539 is a fine solution for opportunistic DoT that has already achieved a nontrivial amount of implementation and deployment. We can talk about other ways to do opportunistic DoT that might reach more users, but I think we’re unlikely to encrypt significantly more traffic that way. The number of resolvers who would do opportunistic-SVCB-DoT but not RFC 9539 seems too small. The real prize is authenticated DoT. For that, our best bet is DELEG. I would rather focus more mental energy on DELEG, rather than spending more time on other (weaker) proposals. I also appreciate the unambiguously opportunistic structure of RFC 9539. In my view, it muddies the water to define an explicit DoT upgrade signal that is not actually secure. —Ben _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
