Subject: Re: DNSEXT WGLC: TKEY Renewal Mode-02

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 04 Feb 2003 13:27:38 -0500

At 13:50 2002-11-14, Ólafur Gudmundsson/DNSEXT co-chair wrote:
>This is the beginning of a 3 week working group last call.
>This last call ends on December 6'th.
>
>This document updates RFC2930 to allow atomic updating of TKEY secrets.
>This document defines a new mode for each algorithm supported, and
>how the "key rollover" takes place.
>
>This document is on standards track and is available via following URL:
>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tkey-renewal-mode-02.txt
>
>         Olafur

The last call on this document resulted in few messages,
raising two issues:
1. the complexity of the protocol
2. The document gave impression that some valid TKEY behavior was outlawed.

The second issue requires minor text change to the document to fix.
The first issue is much larger and requires more feedback for chairs
I would like to pose the following questions to the working group

Q: Is the technical description in the document sufficient and complete to
implement ?

Q: Are there any implementations or are there plans to implement ?

Q: Is this overly complex and we should not do this ?

Q: Is standards track appropriate for this, is experimental status better ?

Silence will be taken as request to chairs to remove this document from
working group consideration.
Deadline for feedback is February 20'th.

         Olafur

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

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 5 Feb 2003 08:07:53 -0500

> Q: Is this overly complex and we should not do this ?
I read over the draft, and it seems complete.  However, I don't know if it
is implemented anywhere, nor has anyone I met plans on implementation.
There might be some hidden pitfalls that come out then.

> Q: Is standards track appropriate for this, is experimental status better
?
Unless there is a case for doing secret key rollover in the DNS instead of
some previously known out-of-band method, it should be dropped.  Otherwise,
proceed as experimental due to cost versus benefit. I doubt most DNS
operators will have the need to do secret key exchanges over DNS.

> Deadline for feedback is February 20'th.

Scott

---

From: "Yuji KAMITE" <[email-masked]>
Date: Sun, 9 Feb 2003 23:18:03 +0900

We would like to present our opinion as this draft's authors.

> > The second issue requires minor text change to the document to fix.

We're going to do minor revision soon, before San Francisco, on this issue.
This would not become critical obstacle.

> > Q: Is this overly complex and we should not do this ?

Basically, this draft makes use of existing RFC2930 framework
for the purpose of perparing new keys. This aims at simple extension that
will not be burden for current TKEY operation. And so its original design
is not complecated.
(In the draft, the procedure to rollover is described in detail because it
requires
high reliability -- perahaps that might give you some complex impression.
However, basic principle of operation is not intricate -- partial revoke
notification,
key rollover preparation, confrimation of adoption: these steps only.
Message structure and exchage style of each process is friendly with RFC2930
specification, not complex. )

> There might be some hidden pitfalls that come out then.

We also think protocol specification is complete.

And we have already made a simple prototype implementation for experiment
(available at URL below), and have seen it works well generally.
But this implemenation was based on the first released draft (-00.txt
version).
Unfortunately, complete implementation hasn't been finished that follows the
today's latest draft (-02.txt).
http://www.kaynet.ecc.u-tokyo.ac.jp/~kamite/research/dns.html#tkey-renew

The implementation difference from today's draft is, whether or not
TKEY adoption messageexchange is used. Originally, this messge was
introduced to
enhance rollover operation's reliablility more, but  its basic exchange
process is
quite simple ( that's only final confirmation of rollover commit).
We beleive it is fairly easy to give some additional changes and
make it work well following today's -02 draft.

>
> > Q: Is standards track appropriate for this, is experimental
> status better
> ?
> >

We think this is the first document that describes tsig-key online rollover
process in detail. We also think It is valuable and useful method because
it provides us with key refreshment in an easy automatic way. It also
prevent
memory waste on receiving continuous only-adding-key, by being careful of
systematic schedule.
That's why this draft helps RFC 2930 TKEY become more available and popular.
So, it would be peferred to progress this draft as standard track.

However, on the other hand, we also think that unless any other groups
is planning this implementation for the time being, it might be better to
progress it as experimental status.
Anyway, it is necessary for us to guide and help complete implemenation
(e.g., getting new numbers from IANA)  by issuing this as RFC.

-- Kamite

---
Yuji Kamite (E-mail [email-masked])
NTT Communications Corporation
         TEL: +81-3-6800-3261 FAX: +81-3-5365-2990