Re: [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00)

Phillip Hallam-Baker <hallam@gmail.com> Tue, 01 February 2011 13:25 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: dnsext@core3.amsl.com
Delivered-To: dnsext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 652353A6FC5; Tue, 1 Feb 2011 05:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.475
X-Spam-Level:
X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92e8cVVXccIe; Tue, 1 Feb 2011 05:25:40 -0800 (PST)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id C1B513A6E80; Tue, 1 Feb 2011 05:25:39 -0800 (PST)
Received: by ywk9 with SMTP id 9so2824227ywk.31 for <multiple recipients>; Tue, 01 Feb 2011 05:28:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SgiOe0GSmTUdE7Cu/YmpcjFw0pU1mjwlfZuB32imHAI=; b=MNdTkfUhZSoSP9Vv4e946eptkzsEaiXi1BZ3iBOo+aap8opO20ReNxsZj3yFZ9vjTN yeA7Hk+/Fn/WWnSDW/VzDgj6QZ3Vat0UU+clqxF4lyTZOg2+1/du4No8LYaSf7ipJkp/ /ksGeUCMdlK3PF2DZEzbDJiTECGxXrws4IIng=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=mBxNpL0GBQSO+39AIGKjpMGSD759PYcRMUI2yh1x0/pvRfwr7SfoSw6RmypV6gOeLk XzEqUqv16ljbIGdH00mPR+Oc3VTI8rM1tL+AMi5CVL3lVhH5pscM3Ag8BhT5qUm1siHr GDeNQ1AIQgZvQDxqZzdO9OnDfr/75O5qxwipc=
MIME-Version: 1.0
Received: by 10.100.134.10 with SMTP id h10mr4908603and.86.1296566936130; Tue, 01 Feb 2011 05:28:56 -0800 (PST)
Received: by 10.100.109.16 with HTTP; Tue, 1 Feb 2011 05:28:56 -0800 (PST)
In-Reply-To: <alpine.LFD.1.10.1102010220360.4802@newtla.xelerance.com>
References: <AANLkTikxd+ODmWoyeNLvPs1R2VD2EcFNrdAX=8oWuCX6@mail.gmail.com> <alpine.LFD.1.10.1102010220360.4802@newtla.xelerance.com>
Date: Tue, 1 Feb 2011 08:28:56 -0500
Message-ID: <AANLkTimkbb2SP4_JQHN74oZV-aExbmYivJfKOZjsYW9g@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Paul Wouters <paul@xelerance.com>
Content-Type: multipart/alternative; boundary=0016e644c708a7d54a049b38839a
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, dnsext List <dnsext@ietf.org>, Knight Dave <dave.knight@icann.org>
Subject: Re: [dnsext] Time vs bootstrap (was Re: draft-jabley-dnsop-validator-bootstrap-00)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 13:25:41 -0000

On Tue, Feb 1, 2011 at 2:30 AM, Paul Wouters <paul@xelerance.com> wrote:

> On Tue, 1 Feb 2011, Brian Dickson wrote:
>
>  This may be good enough for DNSSEC purposes.
>>
>
> At least to then do ntp and and see that it matches our rough expectation.
> Though in all, if the attacker is your controlling upstream, you are lost.
>
> Paul


Active man in the middle is rather easier than factoring a 2048 bit RSA.

With active man in the middle it is going to be possible to perform a replay
attack.

Checking for consistency of data is going to make a replay attack harder but
not impossible.

This may not matter if the device that ultimately relies on the data
returned has a trustworthy time source.

Otherwise you need a mechanism that provides trusted time that is secure
against a replay attack. That is at minimum going to require the ability to
persist a trusted time response to provide a weak form of protection but
strong protection requires a challenge response mechanism and trusted time.


Since ICANN does not provide trusted time, an additional trust root is going
to be necessary.

One issue that does come to mind is that if people are going to implement
the trustworthy resolver model, it would probably be useful to be able to
use the DNS resolver as a low fidelity source of trustworthy time.


-- 
Website: http://hallambaker.com/