In message <[email protected]>, Andrew Sullivan writes: > Hi, > > On Thu, Feb 27, 2014 at 02:16:28PM +1100, Mark Andrews wrote: > > > Blindly trusting AD from anything other than 127.0.0.1 / ::1 is > > asking for trouble even if IPsec is being used. The problem is > > that you still need to trust the server and anything over the net > > should be untrusted by default. > > While I'm pleased as ever to know your personal preferences in this > matter, what I was asking was for information about what Microsoft is > actually shipping, and you seem not to have replied to that question > at all. But I am not sure about your assertion about "should" above, > in at least some scenarios: I think that's exactly what we're > discussing, so you can't just say that one of the possibilities is the > right answer (that would be circular). > > As I understood the deployment model implicit in what Microsoft > shipped (at least in the past), you were not "blindly" trusting the > server, but trusting the server that gave you your IP address, your > definition within the local SMB domain, and so on. In other words, > _not_ trusting the server in question is functionally equivalent to > "doesn't work", so the threat model you have in the above is > completely misaligned with the deployment scenario that I think was > implicit in the product Microsoft shipped. This is the reason for the > reliance on IPSec. I believe that that product was entirely > consistent with the DNSSEC specifications (though it might be subject > to certain kinds of attacks if the attacker can take over the relevant > server).
Just because a server gave you IP addresses doesn't make it trust worthy for DNSSEC. Just because a server gave you credentials which allow you to register is AD doesn't make it trust worthy for DNSSEC. You can trust something for A but not B. Now you can tell a machine if you get A you should also trust it for B but one should be very careful about it. As for not working, if you don't trust the AD bit you are left with the status quo, which isn't everything is not working. I walk into a coffee shop. I get a address. I manage to get IPsec running between the server and myself because both ends are configured for opportunistic IPsec. This does not mean I should trust the AD bit. > I think that it is quite similar to the issue that Paul was raising > with his "virtual servers" scenario. In some virtualized environment, > if you can't trust other systems that share the same physical hardware > as you, you're hosed anyway. Additional protection is going to get > you nothing, and in that case as Paul was arguing it's better to have > the default provide more rather than less protection, even if that > "protection" is completely bogus under some other scenarios. > > Best regards, > > A > > -- > Andrew Sullivan > [email protected] > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
