On Jan 17, 2011, at 6:25 AM, Ted Lemon wrote: > On Jan 17, 2011, at 9:22 AM, Andrew Sullivan wrote: >> (RFC 4035, section 4.9.3). Presumably, then, the stub needs somehow >> to have authenticated the DNS server in question otherwise before >> accepting the claims about signature validation. I can't think of any >> way to do this under DHCP, but maybe I don't know the protocol well enough. > > No, you know the protocol well enough. This discussion has been making more > and more clear to me the need for a DHCP security architecture document.
Why bother? IMO A better approach is NOT to try to patch DHCP/IPv6 Route Advertisements/ARP etc, but just ACCEPT these as insecure. [1] On a local broadcast network, the attacker is always a trivial MitM. Securing DHCP, IPv6 Router Advertisements, ARP, etc, won't stop the attacker anyway. The only thing that stops the attacker is application protocols which work in the face of a MitM. Yet now its the same issue with DNSSEC for A records against a MitM who's also a MitM on final traffic: The application is a customer of the final result from DNS/DHCP/ARP/etc.... And that application is either trivially vulnerable to a MitM OR doesn't actually need to care that DHCP, ARP, DNS, etc are secure, because such insecurity is no different than any other MitM. [1] Not to mention it may be impossible to make these secure, since they are usually 'no initial point of trust bootstrap protocols'.... _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
