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
- Re: [dane] An AD bit discussion Paul Wouters
- [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Ondřej Surý
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Olafur Gudmundsson
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Wiley, Glen
- Re: [dane] An AD bit discussion James Cloos
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andreas Schulze
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Andrew Sullivan
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Paul Wouters
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion Tony Finch
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion (correction) Petr Spacek
- Re: [dane] An AD bit discussion (+concerns from g… Petr Spacek
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- Re: [dane] An AD bit discussion (+concerns from g… Viktor Dukhovni
- Re: [dane] An AD bit discussion Viktor Dukhovni
- Re: [dane] An AD bit discussion (correction) Viktor Dukhovni
- [dane] Proposal: AD bit handling in stub-resolver… Petr Spacek
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Simo Sorce
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] An AD bit discussion Michael Richardson
- Re: [dane] Proposal: AD bit handling in stub-reso… Viktor Dukhovni
- Re: [dane] An AD bit discussion Florian Weimer
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek
- Re: [dane] An AD bit discussion Mark Andrews
- Re: [dane] An AD bit discussion Petr Spacek