Subject: Suggested modifications to the TSIG draft

From: Brian Wellington <[email-masked]>
Date: Wed, 23 Sep 1998 17:21:02 -0400 (EDT)

I've been implementing the TSIG draft, both in BIND 8.1.2 and an
independent implementation of DNS (in Java).  Based on this experience,
I've come across a number of issues that need resolution and/or
clarification.

These ideas have arisen in discussions with Olafur Gudmundsson, Paul
Vixie, and Bob Halley.  No guarantees that everyone agreed on all changes
presented below.

Are there any existing implementations of TSIG, and if so, how have the
implementors dealt with these problems?

Brian

-----------

- [1.7] Error codes: Having different errors for BADKEY and BADSIG leaks
security information (specifically, the name/algorithm of exisiting keys).
These should be combined into one error code, which could be called
BADAUTH.

- [3.4.1] DNS Message.  The request ID should be digested as present, not
as 0 (see below).

- [4.3] Error returns:
  * BADAUTH response:  The response will be unsigned, as the problem lies
  with the key used.  The server cannot definitively determine another
  key to sign the data with, so no key is used.

  * BADTIME response:  The response is signed using the key that signed the
  query.  So that the client will not fail to verify the response with a
  TIME error, the ``Time Signed'' field of the response is copied from the
  query.  In order for the client to determined the server's current time,
  the server includes its time in the ``Other Data'' field as an unsigned
  48 bit value, and sets ``Other Len'' to 6.

- [4.5] Server TSIG checks: BADAUTH checking (both valid key and valid
signature) MUST be performed before BADTIME checking, so that BADTIME is
only returned on a message with a valid signature.

- [4.6.1] Key error handling.  The scenario described (a valid signature
from a different key than the query used) should no longer occur, since
error messages are either unsigned (BADAUTH) or signed with the same key
(BADTIME). This mechanism could be used if the client/server shared
multiple keys and the server was requesting that the client use a
different key.

- [4.7] Special Considerations for forwarding servers: Should be removed.
If a server forwards a query, it should strip the incoming TSIG record,
and generate a new one if it shares a key with the next server.  This
allows the message digest to include the request id instead of 0 (see
above).

Other comments, not essential:

- [2.3] Record format:
  * Why is the algorithm a domain name?  It would be simpler to use an
  IANA assigned constant for processing and name server configuration.

  * Computing the digest becomes simpler if the signature length & signature
  fields are moved to the end of the record.  Is there any reason why they
  are in the middle?

- [4.4] TSIG on TCP Connection: This could use clarification and/or
different word choice.  The terms ``header'', ``DNS header'',
``envelope'', and ``message'' are all used and undefined.  It looks like
``header'' and ``DNS header''are used when ``envelope'' should be, and
``header'' should be reserved for the 12 byte header at the beginning of
each envelope. I assume a ``message'' is a set of envelopes containing
exactly one TSIG, on the last envelope.  So, each message digest contains
the previous digest (the TSIG signature), digests of each envelope, and
the TSIG Timers (calculated at the time of the TSIG signature).  Is this
correct?

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 29 Sep 1998 14:18:55 -0400

>Vixie, and Bob Halley.  No guarantees that everyone agreed on all changes

Given that there have been no objections to the proposed changes 
I will go ahead and update the draft to reflect these changes,
any objections ? 

	Olafur 
>implementors dealt with these problems?
----------------------------------------------------
Ólafur Guðmundsson (in ISO-8859-1)	    [email-masked]    (work)
Olafur Gudmundsson (in US ascii)       [email-masked]   (private)
(301)-854-5700   Fax: x5363