IETF Logo Mail Archive

Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period

bert hubert <bert.hubert@gmail.com> Thu, 23 July 2009 06:12 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Delivered-To: ietfarch-namedroppers-archive-gleetwall6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 110A83A6823; Wed, 22 Jul 2009 23:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level:
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 Y+9QV07H1ESj; Wed, 22 Jul 2009 23:12:42 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 268BC3A681A; Wed, 22 Jul 2009 23:12:42 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1MTrQo-000KwD-5Q for namedroppers-data0@psg.com; Thu, 23 Jul 2009 06:05:30 +0000
Received: from [74.125.78.25] (helo=ey-out-2122.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <bert.hubert@gmail.com>) id 1MTrQj-000Kvf-Kq for namedroppers@ops.ietf.org; Thu, 23 Jul 2009 06:05:27 +0000
Received: by ey-out-2122.google.com with SMTP id 22so220430eye.65 for <namedroppers@ops.ietf.org>; Wed, 22 Jul 2009 23:05:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=RZLwwrlSfcpcCQ+ttM16q/qoNFG5tDf9yTfowXxgw4Q=; b=TDx2DamPnTr6K4E/TRYdwW2pHckw/USGSsxXFB/6H0BX0vw9wlkDLlCTwYOHJDHkAx 34QviD8zaDaThqBof+2le2nC1vYPhs/fQMycLFPGtbi18dKbNfPiCwOTtb4+BFA1ghdg EnGyulFk9zm5NY8NMYgXeSEDts1TqpusafhBg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; b=Ii5FdlU82nGbRMJoBwFrX7qhheaIojR8i/lg0kpmH5AE0/TQ8wXReXetCNq2LcAdx9 izXuRtPKuKAo5bjy6H1h1j8ZTYULqVvy6O2yWrBvFrlVmb0nF1HY65+Q+rezpqwfIlIm 6wy5cvgwqp5FJdhrpfg8k9/E+D0+XY63Ukl7A=
MIME-Version: 1.0
Received: by 10.210.131.6 with SMTP id e6mr7711463ebd.29.1248329124098; Wed, 22 Jul 2009 23:05:24 -0700 (PDT)
In-Reply-To: <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com>
References: <OF1621B157.6C4A78F9-ON802575FB.0043EF31-C12575FB.004628F6@nominet.org.uk> <3efd34cc0907222304m39371205g557ac5e99aef347a@mail.gmail.com>
From: bert hubert <bert.hubert@gmail.com>
Date: Thu, 23 Jul 2009 08:05:04 +0200
Message-ID: <3efd34cc0907222305i5fd8741fude7c574f44fb840d@mail.gmail.com>
Subject: Fwd: [dnsext] TALINK RRTYPE review. Start of three week comment period
To: "namedroppers@ops.ietf.org namedroppers@ops.ietf.org" <namedroppers@ops.ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>

forgot to CC the list.


---------- Forwarded message ----------
From: bert hubert <bert.hubert@gmail.com>
Date: Thu, Jul 23, 2009 at 8:04 AM
Subject: Re: [dnsext] TALINK RRTYPE review. Start of three week comment period
To: roy@nominet.org.uk


On Wed, Jul 22, 2009 at 2:46 PM, <roy@nominet.org.uk> wrote:
> I have been assigned with the task of coordinating an expert-review of the
> DNS RRTYPE parameter allocation for TALINK, present in
> http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 .

I have read this, and I think I understand what it says. Here goes. So
we have a trust anchor, which is hardcoded in the configuration file.

However, a rollover has occurred, and we didn't see it happen, so we
could not update our trust anchor.
(Just wondering, does this currently happen already in validating
resolvers? I got the impression trust anchors were rather static.)

Now the validator is back in business, possibly because it was only
turned on for the first time after being installed on the PC in the
factory from a 2 year old master, and it finds it can't validate
anything based on the trust anchor it has, because it has since rolled
over.

However, it finds a chain described by TALINK records which say 'this
key is my successor, and I've signed it using the anchor you know,
please trust it'.

And things are good.

Is this description correct? If so, how can we be sure that the
original anchor (which may have been rolled over because it was
compromised), cant' be "resurrected" by a third party using an
appropriate TALINK chain?
In other words, doesn't TALINK negate the utility of doing KSK
rollovers in the first place?

Also, DNSSEC is already straining with complexity - I know for sure
since I started implementing it for a prototype on
www.powerdnssec.org. I wonder if we shouldn't simply tell people to do
this kind of thing out of band. Say, using 'windows update'.

On the TALINK record per se, if it turns out that having a
'rolled-over key' resurrection ability is a good idea, we surely need
a "TALINK" rrtype.

          Bert

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

v2.23.0 | Report a Bug | By Email