Re: I-D ACTION:draft-kamite-dnsext-tkey-secret-renewal-00.txt

Edward Lewis <lewis@tislabs.com> Thu, 12 July 2001 15:40 UTC

Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07926 for <dnsext-archive@lists.ietf.org>; Thu, 12 Jul 2001 11:40:30 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KhcJ-000AFi-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 07:38:59 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KhcJ-000AFc-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 07:38:59 -0700
Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KhcJ-000ABo-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 07:38:59 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Edward Lewis <lewis@tislabs.com>
To: Internet-Drafts@ietf.org
Cc: namedroppers@ops.ietf.org
Subject: Re: I-D ACTION:draft-kamite-dnsext-tkey-secret-renewal-00.txt
In-Reply-To: <E15K4mK-000AbD-00@psg.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15KhcJ-000AFi-00@psg.com>
Date: Thu, 12 Jul 2001 07:38:59 -0700
Content-Transfer-Encoding: 7bit

First, I'm really happy that someone is working on TKEY usage - it is one
of the open areas for improvement in DNS Security.

However, I think most of what is suggested in this document can be
accomplished by adding another extended RCODE to the TKEY definision.
"REKEY" could be a reply from a server to a client when there is an
existing secret (temporally valid) that the server wishes to see go away.

E.g.  At 11pm, client and server agree on a secret to last from 11pm to 3am.

At 12am (midnight), client queries with secret, server replies with secret.

At 1 am, the server decides the secret is unacceptable (and the client
doesn't know this).

At 2am, client queries with secret, server replies with "REKEY"

...Without this new rcode, the choices the server has are "BADKEY" and a
few others.  "BADKEY" might be confusing to the client as this indicates a
secret that is unknown/invalid to the server.  As far as the client knows,
the secret is agreed upon, perhaps the server is just suffering from
amnesia.  I think REKEY would help clarify this.

Of course, the probably action by the client would be to start a rekeying
as a reaction to BADKEY, so the clarification isn't for the software, but
for the implementors.

At 5:10 PM -0400 7/10/01, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title		: TKEY Secret Key Renewal Mode
>	Author(s)	: Y. Kamite, M. Nakayama
>	Filename	: draft-kamite-dnsext-tkey-secret-renewal-00.txt

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: lewis@tislabs.com

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.




to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.