Re: [dane] An AD bit discussion

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 27 February 2014 03:47 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952D11A069A for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 19:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.559
X-Spam-Level: **
X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PcmWyr0ZYCZ for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 19:47:30 -0800 (PST)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE231A037C for <dane@ietf.org>; Wed, 26 Feb 2014 19:47:30 -0800 (PST)
Received: from mx1.yitter.info (c-75-69-155-67.hsd1.nh.comcast.net [75.69.155.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 975188A031 for <dane@ietf.org>; Thu, 27 Feb 2014 03:47:28 +0000 (UTC)
Date: Wed, 26 Feb 2014 22:47:23 -0500
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dane@ietf.org
Message-ID: <20140227034723.GA73861@mx1.yitter.info>
References: <alpine.LFD.2.10.1402260845520.3528@bofh.nohats.ca> <m3txbly9ui.fsf@carbon.jhcloos.org> <alpine.LFD.2.10.1402261930400.3528@bofh.nohats.ca> <20140227022347.GC73737@mx1.yitter.info> <20140227031628.B4A1610765F9@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140227031628.B4A1610765F9@rock.dv.isc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/D3MpVmMcpEFKlOeiXyJbrmJ9d9U
Subject: Re: [dane] An AD bit discussion
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2014 03:47:31 -0000

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
ajs@anvilwalrusden.com