It's probably fair to say the PR should amend the existing security considerations section to cover this aspect as well. I will update the PR to include that information by EOD tomorrow.
Regarding the DNS threat, the configuration data from the apex is used in 2.5.2 as a uniqueness check against the primary config file - see https://w3c-fedid.github.io/FedCM/#fetch-config-file. It's a bit of an unusual setup (imho). But the outcome is that DNS tampering here can cause availability issues, but not integrity issues - which is just status quo. And, the data is intended to be public. There's perhaps another factoring here that leans into the DNS record just being a uniqueness check. Instead of containing the authentication subdomain label and optionally the login url path and account url path, the DNS record could contain a hash of the well known file. That is.. Today: 1. Retrieve application-specified config file over HTTPS 2. Retrieve well-known from apex domain over HTTPS 3. Confirm critical properties (loginUrl + accountsUrl) from 1 and 2 match. Proposed (my PR and first message in thread): 1. Retrieve application-specified config file over HTTPS 2. Retrieve subdomain from DNS _web-identity on apex 3. Retrieve well-known from identified subdomain over HTTPS 4. Confirm critical properties (loginUrl + accountsUrl) from 1 and 3 match Alternative: 1. Retrieve application-specified config file over HTTPS 2. Retrieve "web identity hash" from DNS _web-identity on apex 3. Compute hash of critical properties (loginUrl + accountsUrl) from 1 and confirm match with 2 This maybe better resembles some of the other things done in DNS (e.g. _acme-challenge) where the DNS data is opaque on its own. No doubts re the viability of threats on DNS. Thanks, Will ________________________________ From: John R. Levine <[email protected]> Sent: Wednesday, April 8, 2026 6:34 PM To: Will Bartlett <[email protected]>; [email protected] <[email protected]> Subject: Re: [DNSOP] Re: [EXTERNAL] Re: Advice sought: DNS record type for FedCM well-known file delegation [You don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] >> I would suggest writing an Internet-Draft to start the discussion. > > You are the second person to make this suggestion. Can you help me understand > what is unclear or missing from the current (W3C-formatted) document, linked > in my initial mail? Partly, it's the way the IETF works, partly the structure of an I-D will encourage you (or whoever) to fill out bits that you may have overlooked, like the security considerations. The security properties of a DNS record are quite different from a well-known URI. If you know that the file for foo.example.com is on a web server at example.com, the client can verify that there's an SSL certficate with the expected domain name. But if you get the URL or domain name from a DNS lookup, you have no verification at all unless it's signed with DNSSEC and the client program checks the signature. In practice hardly anyone does DNSSEC signing, under 5% of .COM. I used to think that malicious DNS stealers were a largely hypothetical issue, but look at this story published just today about state actors hacking soho routers to send the DNS queries to Russia: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ncsc.gov.uk%2Fnews%2Fapt28-exploit-routers-to-enable-dns-hijacking-operations&data=05%7C02%7Cwibartle%40microsoft.com%7C237c8d151636498421e708de95d8223d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639112952896532570%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C40000%7C%7C%7C&sdata=n9k4mEBJKGSzpjMSyOzPAuCT2V7v5%2BGYElxnAnNSO0Q%3D&reserved=0<https://www.ncsc.gov.uk/news/apt28-exploit-routers-to-enable-dns-hijacking-operations> R's, John
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
