Re: DNSEXT WGLC: TKEY Renewal Mode-02

[randyhall@lucent.com (Randy Hall)]

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>-owner@ops.ietf.org and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> 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

I have two comments on this draft.  I don't feel this protocol should
advanced as written.

1) Quoting from section 2.2:

> Server which has received queries signed with the partially revoked
> key MUST NOT answer them except when they are Renewal requests (See
> section 2.3.) or "key adoption" requests (See section 2.4.). Instead,
> it returns TSIG error messages whose error codes are "PartialRevoke"
> (See section 9.)

I feel the server should accept a TKEY delete query (TKEY mode 5) which
is signed with a partially revoked key.  The wording above (and in
section 9), shuts the door on this possibility, at least the way I
have read it (perhaps it just needs a clarification, or an explanation
for this decision).  As an aside, it occurs to me that the protocol 
seems unnecessarily complex.  Based on implementation experience, a
cleaner approach may be --

  a) server partially revokes key and sends appropriate rcode in
     response to messages signed with that key
  b) client sends a tkey delete request signed with that key
     and server deletes key 
  c) client and server establish brand new secret using tkey

Which approach is better is a matter to think about, but unless there
is a downside to allowing a tkey delete request to be signed with
a partially revoked key (and I can't think of one off the top of
my head, since deleting a key can be construed as part of a mechanism
of using RFC 2930 to renew the key), then it would be nice if the 
protocol didn't preclude this possibility -- and allowing it would 
certainly improve at least on deployed implementation -- which 
currently has a hokey client side management of "is this key about 
to expire" logic.  

2) Just a minor thing -- I think section 1.3 would be clearer
if paragraph 3 mentioned that the messages in the key renewal
procedure are (or can be?) signed with the partially revoked key
(I realise this is mentioned later, but it was my first question
as I was reading it ...)

Cheers
Randy



--
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/>