From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <toke@toke.dk>
Received: from mail2.tohojo.dk (mail2.tohojo.dk [IPv6:2a01:4f8:200:3141::101])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by huchra.bufferbloat.net (Postfix) with ESMTPS id EE15221F144
	for <cerowrt-devel@lists.bufferbloat.net>;
	Sun, 30 Mar 2014 11:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at example.com
In-Reply-To: <CAA93jw5w6X4OewvYs=eWkUi7bbdK=rAsZ2eM_t9LU5vOetRD1w@mail.gmail.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toke.dk; s=201310;
	t=1396204694; bh=hMkdxWuuRoE0dadqO8qvLk3jFevx8gxWh8h3l0Agcvo=;
	h=References:Subject:From:Date:To:CC;
	b=LeIQpUVyQPSWRxxwpHMAs2YBFYbI8sbpls87SND1dWKt1aR7vFT0r5DKg+QnbaHzo
	7k6Wevaary9ebDfTELxrvX9tQgV6BsM82TQGW4ttKrrt3g1NKI/8UlQTVbinVz2tsm
	qnUluvrFjuAFvbGDQTptSOnLTbnhvwjNjQtlvxNQ=
References: <MTAwMDA0MC5kZWNveQ.1395459208@quikprotect>
	<CAA93jw6GDnoP8_0ZBuQhK0cF2JTWrp281mRWMh5UCUvQ2r71EQ@mail.gmail.com>
	<532DD9DD.8040301@thekelleys.org.uk>
	<871txut453.fsf@alrua-x1.karlstad.toke.dk>
	<532DE7A8.3010504@thekelleys.org.uk>
	<87ppleroks.fsf@alrua-x1.karlstad.toke.dk>
	<53348C32.4040907@thekelleys.org.uk>
	<87ha6idabz.fsf@alrua-x1.karlstad.toke.dk>
	<53353C07.9030000@thekelleys.org.uk> <87eh1madfy.fsf@toke.dk>
	<533551F6.9010402@thekelleys.org.uk> <87lhvu8uqi.fsf@toke.dk>
	<5335E1BD.7010304@thekelleys.org.uk>
	<87k3bdbbt6.fsf@alrua-x1.karlstad.toke.dk>
	<87bnwpb7f7.fsf_-_@alrua-x1.karlstad.toke.dk>
	<421.1396128076@sandelman.ca>
	<CAA93jw5kHUEZWWT7FM7mf+6AesV0x3fqtUWNoN0ARkf-2UNprw@mail.gmail.com>
	<877g7bbz5g.fsf@alrua-x1.karlstad.toke.dk>
	<CAA93jw5w6X4OewvYs=eWkUi7bbdK=rAsZ2eM_t9LU5vOetRD1w@mail.gmail.com>
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
From: =?ISO-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= <toke@toke.dk>
Date: Sun, 30 Mar 2014 20:38:04 +0200
To: Dave Taht <dave.taht@gmail.com>
Message-ID: <a8b65bac-b5a9-4f4b-8317-1a5ddf8f8d62@email.android.com>
Cc: "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] DNSSEC & NTP Bootstrapping -- prototype!
X-BeenThere: cerowrt-devel@lists.bufferbloat.net
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: Development issues regarding the cerowrt test router project
	<cerowrt-devel.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cerowrt-devel>
List-Post: <mailto:cerowrt-devel@lists.bufferbloat.net>
List-Help: <mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cerowrt-devel>,
	<mailto:cerowrt-devel-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Sun, 30 Mar 2014 18:38:26 -0000


> > Well conceivably you could be in a situation where the roots
> validate,
> > but validation fails further down the chain, making that scheme fail
> in
> > weird and unpredictable ways?
> 
> http://www.bortzmeyer.org/dns-routing-hijack-turkey.html
> 
> ?

I was thinking more about the case where, say, the root server keys validate, but the keys further down the chain have been changed, and the clock is set to a time in the interval between the respective beginnings of validity time... I would think that could happen with no malicious intent way too often for the root keys to be a very useful heuristic to use...

-Toke