On Mon, 20 Aug 2018, Brian Dickson wrote:
Those zones would have a signed ZONEMD but no DS record leading to a
validated path anyway, so those are lost without an external (from
DNSSEC) PKI which falls very far outside the scope of ZONEMD.
Paul
What Shumon was referring to is the actual TLD zones themselves.
For example, the NS sets for COM have nameserver names under gtld-servers.net, which is an unsigned zone.
The A/AAAA records, needed for finding the COM servers aren’t signed, even if attempting to find the AA answer.
What ZONEMD would provide is a method of validation of the non-authoritative
A/AAAA (glue) for the TLD itself.
It wouldn't add anything. To trust the ZONEMD record, you would need to
have traveled the DS chain from root to .com anyway and gotten valid
answers. At that point you are at the child and you can (and have to)
confirm the DNSKEY there, and then you might as well also confirm the
parental glue you followed in the child you found, since you've reached
that child zone anyway (which secure validating resolves already do
anyway)
While not as strong as using NS names in a signed zone, it is still a method of
preventing poisoning of those glue records (A/AAAA specifically).
You can never prevent poisoning. You have to blindly follow any glue and
verify at the alleged child zone that you reached the real thing, since
IP redirections or MITM are always possible.
NB: root-servers.net is unsigned.
The number of insecure hops doesn't matter. What matters is finding a
signed zone with a DNSKEY that matches the DS record.
And also as I said before, the attackers that can change glue on you
dwarve in comparison with upstream hops that can just redirect IP
traffic which accomplishes the exact same thing. Fixing the 1% isn't
helpful when any hotel/coffeeshop can redirect your IP streams to
say 192.5.6.30 anyway.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
