Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt

From: Mark Andrews <[email-masked]>
Date: Fri, 04 Mar 2005 11:03:41 +1100

> TSIG is only used by prior agreement of the parties involved. Policies 
> as to what algorithms to use and what truncation to allow are all 
> deliberately left open. If they feel like it, the parties could not only 
> use asymmetric amounts of truncation but different hash algorithms in 
> each direction. But one would expect that in most real cases they would 
> use a fixed algorithm and truncation. But, since amounts of truncation 
> are clearly ordered and, arguably, current hash algorithms also are, I 
> suppose that more flexible code could be configured with a minimum hash 
> algorithm and a minimum number of octets of hash. If the signature is 
> too weak for the receiver's policy, I don't see this as different form 
> the signature being missing. This should be probably all be explicitly 
> stated in the document.

	Truncation introduces lots of flexability.  It would be
	nice to constrain it or everybody will have to implement
	lots of knobs to achieve interoperability.

	In addition to <name, hmac, secret> we now have query bits,
	reply bits, whether they are absolute or minima.  The
	relationship between query bits and reply bits.
	e.g.
		* none
		* reply bits == query bits.
		* reply bits >= query bits

	For example I had a client configure to use hmac-sha512-400
	with a server configure to use hmac-sha512-256 both minima.
	The server could verify the query but client couldn't verify
	the response.  The reason was that the server was sending
	hmac-sha512-256.  Making the server respond with the same
	number bits as the the client sent allow the client to
	verify the response.

> Truncation is trivial and most IETF security protocols provide 
> explicitly for things like SHA-1 truncated to 96 bits. There are people 
> who believe that a little truncation improves security by revealing less 
> information to crackers. I don't see any reason to fail to provide 
> truncation cababilities in TSIG.
> 
> Thanks,
> Donald
>   ====================================================================
>   Donald E. Eastlake 3rd                       [email-masked]
>   155 Beaver Street              +1-508-634-2066(h) +1-508-786-7554(w)
>   Milford, MA 01757 USA                   [email-masked]
> 
> On Tue, 1 Mar 2005, Mark Andrews wrote:
> 
> > Date: Tue, 01 Mar 2005 16:08:36 +1100
> > From: Mark Andrews <[email-masked]>
> > To: [email-masked]
> > Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt
> > 
> >
> > 	HMAC Truncation.
> >
> > 	Looking at this there is nothing to say whether a reply
> > 	has to use the same number of bits as the query?
> >
> > 	i.e.
> > 		Can a server respond to a truncated HMAC-SHA1 w/
> > 	a full HMAC-SHA1?
> >
> > 	If you are rejecting a TSIG because the number of bits is
> > 	too small what is the RCODE in the TSIG?  BADAUTH+????
> >
> > 	Is the server supposed to auto adjust to the client within
> > 	limits (max(80 bits, half digest bits)) or is the server
> > 	supposed to specify a absolute number of expected bits or
> > 	a minimum number of expected bits.
> >
> > 	How does a server, if it rejecting because of too few bits,
> > 	signal the minimum number of bits it will accept for this
> > 	key.
> >
> > 	Is truncation just too much of a complication?
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]
> >
> > --
> > 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/>
> >
> >
> 
> --
> 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/>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

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