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