[dns-privacy] Re: [DNSOP] Re: Proposal for opportunistic transport signaling from authoritative servers

[Shreyas Zare <[e-mail]>]

On 7/9/2025 3:43 AM, Ben Schwartz wrote:
>> On Jul 8, 2025, at 5:39 PM, Peter Thomassen<peter=[e-mail]> 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/>