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

From: Mark Andrews <[email-masked]>
Date: Mon, 07 Mar 2005 03:58:12 +1100

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

	Donald you are looking at this from the wrong direction.
	Implementations can constain available policy.  We need to
	ensure that a implementation that implements >= bits will
	interoperate with a implementation that implements exact
	bits.  There will also be implementations that will implement
	both giving more policy choices for the administator.

	In all cases the client needs to be able to choose the initial
	number of bits.  The server will choose to accept or reject a
	signature with that number of bits on the request.  It then has
	to send a reply.  We need to make sure that the reply will be
	accepted regardless of the implementation type.
 
> 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]

	We could may the first a MAY.  I would make the second
	a reply MUST use the same number of bits in the digest
	as the request used.

	This allows forces servers that implement the MAY to
	interoperate with clients that do not implement the MAY.
	In other words the client set the number of bits for the
	transaction which may or may not be accepted by the server's
	policy but will be constant for the life of the transaction.

	Mark

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