Re: [dane] An AD bit discussion

[Andrew Sullivan <[e-mail]>]

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
[e-mail]