[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    RE: Suggested modifications to the TSIG draft
From:       Stuart Kwan <skwan () MICROSOFT ! COM>
Date:       1998-09-30 22:45:13
[Download RAW message or body]

Olafur, were you planning on incorporating all of Brian's points?  Or just a
select set?  A few comments:

> - [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).

It may not be wise to select a new key, if someday these keys are used for
access control.  Also, I take it that you would select a different message
ID for the forwarded update, per RFC 2136?  Does anyone else have a comment
here?

>  * 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?

Jim Gilroy asked for this a while ago, but none of the authors responded.
Eventually we relented so the protocol would move forward.  Such is life,
but are we going to change it again?

Cheers,
- Stuart



> -----Original Message-----
> From:	Olafur Gudmundsson [SMTP:ogud@TIS.COM]
> Sent:	Tuesday, September 29, 1998 11:19 AM
> To:	namedroppers@internic.net
> Subject:	Re: Suggested modifications to the TSIG draft
> 
> At 05:21 PM 9/23/98 -0400, Brian Wellington wrote:
> >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.
> 
> 
> 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 
> >
> >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?
> >
> >
> ----------------------------------------------------
> Ólafur Guðmundsson (in ISO-8859-1)	    ogud@tis.com    (work)
> Olafur Gudmundsson (in US ascii)       ogud@acm.org   (private)
> (301)-854-5700   Fax: x5363

[prev in list] [next in list] [prev in thread] [next in thread]