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

From: Donald Eastlake III <[email-masked]>
Date: Sat, 5 Mar 2005 23:27:27 -0500 (EST)

Mark,

I just don't see that there is likely to be much problem in actual 
practice. What are plausible relationships between parties using TSIG? 
If they are under common administration, they will have been zapped to 
have compatible policies. If it is a less capable client buying service 
from a server, the client had better sign its queries in a way 
acceptable to the server and accept whatever the server sends back or it 
won't get any service. Only if there are indpendently administered peers 
using TSIG is there much possibility of a problem. And even then, the 
symptom will be immediately failure, which should motivate people to get 
it fixed pretty quick.

I suppose it would be plausible to force an ordering of truction where 
longer signatures are always considered stronger. This is, you could 
have a rule that policies that would accept a signature with algorithm A 
truncated to T octets MUST also accept longer signatures. Getting 
somewhat flakier, you could, as a second rule, say that servers 
receiving a query and verifying a signature on that query truncated to T 
octets MUST reply with a signature having at least T octets. I certainly 
wouldn't go any further than these two rules and I'd be interested in 
the opinion of others as to whether such rules would be desireable.

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 Fri, 4 Mar 2005, Mark Andrews wrote:

> Date: Fri, 04 Mar 2005 11:03:41 +1100
> From: Mark Andrews <[email-masked]>
> To: Donald Eastlake III <[email-masked]>
> Cc: [email-masked]
> Subject: Re: doc/draft/draft-ietf-dnsext-tsig-sha-01.txt 
>
>> 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/>