Re: [dane] An AD bit discussion

Mark Andrews <marka@isc.org> Thu, 27 February 2014 03:16 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 5E42C1A01A9 for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 19:16:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.448
X-Spam-Level:
X-Spam-Status: No, score=-7.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 pJe02YRZUteT for <dane@ietfa.amsl.com>; Wed, 26 Feb 2014 19:16:45 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37C1A015C for <dane@ietf.org>; Wed, 26 Feb 2014 19:16:45 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 910652383A7; Thu, 27 Feb 2014 03:16:31 +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 B68E516004C; Thu, 27 Feb 2014 03:17:23 +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 8662416004A; Thu, 27 Feb 2014 03:17:23 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B4A1610765F9; Thu, 27 Feb 2014 14:16:28 +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>
In-reply-to: Your message of "Wed, 26 Feb 2014 21:23:48 -0500." <20140227022347.GC73737@mx1.yitter.info>
Date: Thu, 27 Feb 2014 14:16:28 +1100
Message-Id: <20140227031628.B4A1610765F9@rock.dv.isc.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/th7ILJ2ZbDNuvPuc9NzG7GsUpGw
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 03:16:47 -0000

In message <20140227022347.GC73737@mx1.yitter.info>;, Andrew Sullivan writes:
> On Wed, Feb 26, 2014 at 07:41:00PM -0500, Paul Wouters wrote:
> > seems to agree doing DNSSEC on the host itself (server or in-app) is
> > still the preferred method.
> 
> Is Micorosoft's method still to prefer the AD bit from the server, but
> use IPSec between the clients and the servers?  That would seem to be
> similar to your concern.

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.

Adding a trusted key clause to resolv.conf would work e.g.

trusted-key start-date end-date . 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0="

Better still would be a RFC 5011 replacement that published START
and END dates along with a poll frequency for keys that should be
used as trust anchors along with the key material.  The START and
END dates would be updated periodically.  RFC 5011 is a grose hack.
We can do significantly better.

It the trusted-key clauses haven't been updated before the end date
the validator ignores the trusted key if there are no trusted-key
clauses clauses left you treat everything as insecure.

> Best,
> 
> 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