On Jan 17, 2011, at 9:34 AM, Nicholas Weaver wrote:
> 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]

Right, but people keep trying to treat them as if they conveyed some sort of 
trustworthiness.   Hence the need for a security architecture document.

> 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.

The application needs to get the address of a service to *try* before it can 
validate its trustworthiness.   If DNS is successfully spoofed, the application 
will, at best, simply fail, and at worst, it will reveal sensitive information 
to an attacker or cause damage (or both).

There are really four levels of security we could reasonably aspire to having:

- None: the DHCP server and/or DNS server can lie to the client with impunity, 
because it does not attempt to validate DHCP and/or DNS responses that it gets.
- Some: the DHCP server and/or DNS server's lies will be detected, but the 
client has no way to get the truth, so the lies amount to DoS attacks.
- Some more: the DHCP client and/or DNS resolver can detect rogue servers and 
can re-try the protocol using different servers in hopes of getting a working 
network connection, using cached information.
- Some more still: the DHCP client is configured with keys that it knows belong 
to trusted DHCP servers, and hence when it receives multiple offers, some of 
which come from trusted servers and some of which do not, can entirely avoid 
DoS attacks by using  a trusted server.

As you can see, none of these levels of security reliably protect the 
application layer, yet all of them except the first are clear usability 
improvements over the first.   So to say that there is no value in doing 
validation in these protocols is simply nonsense.   You could argue that there 
isn't enough value to justify going to the trouble, but there is value.

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to