Re: [dane] An AD bit discussion

Mark Andrews <marka@isc.org> Thu, 27 February 2014 04:18 UTC

Return-Path: <marka@isc.org>
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 733221A0380 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 20:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.548
X-Spam-Level:
X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 JejT4NymsVVp for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 20:18:12 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id EA2E11A03D6 for <dane@ietf.org>; Wed, 26 Feb 2014 20:18:11 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id CFEC7C9424; Thu, 27 Feb 2014 04:17:56 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1393474690; bh=s/Ytzbz/3um78Dxxx4SjzCTA9WZPCb5EQW6bXNpBdYU=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=BC1d/xwp/sZD6CIFYLyfK0A+JBlHnt3WC+LUfk4ekLTYX92IK10ZvrWP062fvY0OV sxVD8fv5fZ5eKDkLJelupoJviAjoWPH+uwgbjq6sF27esgpBxkL/PUts4BevbbgZtf 3EJU0OvXHhT+w5megFBKtKVphskBe9/YOnwCyJZQ=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Thu, 27 Feb 2014 04:17:56 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8A5AE16004C; Thu, 27 Feb 2014 04:18:49 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 5ACAF16004A; Thu, 27 Feb 2014 04:18:48 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3509810773A8; Thu, 27 Feb 2014 15:17:53 +1100 (EST)
To: Andrew Sullivan <ajs@anvilwalrusden.com>
From: Mark Andrews <marka@isc.org>
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> <20140227034723.GA73861@mx1.yitter.info>
In-reply-to: Your message of "Wed, 26 Feb 2014 22:47:23 -0500." <20140227034723.GA73861@mx1.yitter.info>
Date: Thu, 27 Feb 2014 15:17:53 +1100
Message-Id: <20140227041753.3509810773A8@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/Uj-IeTbBrK_XuWNeDUX1TZwbzdQ
Cc: dane@ietf.org
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 04:18:13 -0000

In message <20140227034723.GA73861@mx1.yitter.info>;, 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
> ajs@anvilwalrusden.com
> 
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org