Op 18-03-2025 om 05:46 schreef Peter Thomassen:
Hi Willem,On 3/17/25 23:16, Willem Toorop wrote:- For signed delegations, NS revalidation protects the privacy of the actual query.And in addition to that prevents all unsigned parts of the hijacked zone to be rewritten. For example if com is hijacked, unsigned zones like google.com can be redirected.First, .com is signed, so I'm not sure how you'd hijack it as a whole.
With an NS revalidating resolvers this is impossible, because the authoritative parent side .com NS RRset is signed.
A resolver that does not do NS revalidation uses the unsigned .com NS RRset from the root zone, and can as such be redirected to the kind of proxy you describe below.
Second, let's say I run a proxy between the .com server and your resolver, and I manipulate unsigned delegations, but forward everything else (so that things expected to DNSSEC-validate do actually validate). For my fake unsigned delegations, I make sure that my nameservers serve the same fake NS RRsets on the child apex. -- If your resolve now does NS re-validation, how does that prevent me from rewriting those unsigned delegations?
It does not. And the proxy can also rewrite the delegations of signed zones, by rewriting the unsigned parent side NS RRsets and glue (leaving the signed DS as is).
But with the latter, a DNSSEC validating NS revalidating resolver will ultimately reject the rewritten referral of DNSSEC signed zones, because it requires the authoritative and DNSSEC signed child side of the cut NS RRset.
-- Willem
NS revalidation of signed delegations is the only mitigation that protects against on-path or partly on-path attacks.Given the above, I just don't understand that. I hope I'll see the light! :-)Cheers, Peter
OpenPGP_0xE5F8F8212F77A498_and_old_rev.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
