[Uta] Re: Seeking Input on Secure Service Delegation

[Michel Le Bihan <[e-mail]>]

Hi Viktor,

Apologies for the late reply.

While DNSSEC adoption is strong in some ccTLDs, two issues prevent it 
from being a complete solution:

 1.

    *TLD limitations*: Some TLDs don't support DNSSEC at all (e.g., .im,
    popular for XMPP services). Organizations using these domains cannot
    deploy DNSSEC regardless of how motivated they are. For XMPP,
    changing domains isn't feasible since they're part of user
    identifiers ([e-mail])

 2.

    *Infrastructure breakage*: Some DNS forwarders, particularly home
    routers, truncate responses and lack EDNS support (see Table 2, p.
    583: https://www.usenix.org/system/files/sec20-zheng.pdf) This
    breaks DNSSEC validation even for domains that properly support it.

These limitations affect a significant portion of services that need 
secure delegation today. The SRV-ID certificate approach could provide a 
practical alternative where DNSSEC isn't viable.

Best regards,
Michel Le Bihan

Le 01/09/2025 à 05:43, Viktor Dukhovni a écrit :
> On Sun, Aug 31, 2025 at 09:18:38PM +0200, Michel Le Bihan wrote:
>
>> The Security Problem
>>
>> Without DNSSEC (which has very limited deployment according to Cloudflare
>> and SIDN statistics),
> Global average fraction of DNSSEC signed domains is ~6.5%, it is however
> rather unevenly distributed.  The below ccTLDs have 20% or more of their
> delegations DNSSEC-signed:
>
>      https://stats.dnssec-tools.org/#/?top=tlds&tld_tab=3
>
>      TLD     #Zones      #Signed     %Signed #DANE   %DANE
>      TOTAL   370990810   23951119    6.46    4277775 17.86
>      er      53          40          75.47   0       0.00
>      dk      1303448     863667      66.26   367844  42.59
>      cz      1504173     945604      62.87   137880  14.58
>      nl      6109695     3817016     62.47   1054927 27.64
>      se      1386049     837283      60.41   338179  40.39
>      sk      466674      266802      57.17   22761   8.53
>      no      855870      488932      57.13   150899  30.86
>      nu      203088      114855      56.55   33337   29.03
>      ch      2535106     1325679     52.29   587647  44.33
>      li      68737       22104       32.16   7182    32.49
>      be      1704076     499395      29.31   143082  28.65
>      fo      8414        2465        29.30   233     9.45
>      ee      174818      43054       24.63   18794   43.65
>      re      39807       9705        24.38   931     9.59
>      yt      5453        1179        21.62   214     18.15
>      tf      4001        841         21.02   209     24.85
>      fr      4256065     887877      20.86   77439   8.72
>      br      5501608     1147110     20.85   2494    0.22
>      eu      3681490     758904      20.61   115688  15.24
>
>      where the DANE counts are for SMTP (_25._tcp TLSA RRs for the
>      domain's MX hosts) and %DANE is as a fraction of the *signed*
>      domains.  [ Yes, the .er (Eritrea) outlier is not a compelling data
>      point, but that's also not a compelling reason to exclude it. ]
>
>> these SRV-based delegations are vulnerable to DNS spoofing attacks. An
>> attacker who can manipulate DNS responses can redirect users to
>> malicious servers, potentially intercepting credentials and
>> communications.
> One obvious suggestion for those facing the issue is to deploy DNSSEC,
> which is now a well-established technology.
>
>> I've evaluated several approaches, each with significant drawbacks:
>>
>>      DANE (RFC 6698): Requires DNSSEC, which remains impractical due to low
>> adoption
> Can you explain what makes generally modest adoption rates a barrier for
> those who are motivated to take advantage of DANE.
>