On 7/9/2025 3:43 AM, Ben Schwartz wrote:
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.
+1
The another thing to add here is that a resolver which implements RFC
9539 will have issues implementing opportunistic-SVCB-DoT along with it.
The resolver would anyways be probing DoT 853 without the SVCB signaling
and when there is an explicit SVCB signal, it will be essentially doing
the same - probe for DoT 853. I do not see how it is an improvement to
RFC 9539.
Regards,
*Shreyas Zare*
Technitium <https://technitium.com/>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
