Subject: DNSEXT WGLC Summary: TSIG SHA1 document

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 09 Mar 2005 21:35:20 -0500

The working group last call has concluded.
The document was reviewed by working group members and security
area directorate member.
The working group supports the document advancement.

Following changes/clarifications are needed in the document
before it is advanced.

#1 Add text saying implementations can reject messages signed by a
particular algorithm even if that algorithm is mandatory to implement.
(important in TKEY environments)

#2 Set lower bound on truncation (for each algorithm),
default lower bound is half of original digest.

#3 add new TSIG error code that sender is using excessive truncation

#4 add text if responder can use different truncation than sender
and rules for that.

#5 Remove unused reference to 2434

#6 Add text that defines what is included in subsequent digest when
truncation is used (full or truncated digest)

	Olafur 

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

---

From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Fri, 11 Mar 2005 10:30:58 -0500

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, March 11, 2005 5:44 AM
To: Ólafur Guðmundsson /DNSEXT co-chair
Cc: [email-masked]
Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document

> (important in TKEY environments)

I agree that implementations must be allowed to reject messages signed
with a mandatory to implement algorithm (that's part of what I meant
by "the distinction between implementing an algorithm and having a
policy of accepting it"), but what does TKEY have to do with it?

> default lower bound is half of original digest.

Does this "default lower bound" mean that in the absence of explicit
configuration to the contrary, a receiving implementation should
accept digests truncated to half the original length?  If a slave
server has an existing agreement with its master to accept zone
transfers signed with HMAC-MD5 and is upgraded to conform to the new
specification without changing its configuration, will it start
accepting transfers signed with HMAC-MD5-truncated-to-64-bits because
that's the "default lower bound", thereby becoming 2^64 times easier
to attack by brute force and disregarding the administrator's original
intent to require 128-bit HMAC-MD5 signatures?  I don't think that's a
good idea.

@@@ No, the change to the draft will prohibit (MUST NOT) policies that
would accept a truncation to less than the greater of 80 bits and half
the original digest. I.E., the recommendation currently mentioned in
the Security Considerations section will be made mandatory.

I find this whole discussion about complicated policies to accept
multiple algorithms and ranges of truncation lengths worrisome.
Since TSIG is based on mutual agreement, what's wrong with a policy of
accepting only messages signed with the exact key, algorithm, and
truncation length that were mutually agreed on?  This is what existing
TSIG implementations do with respect to the key and algorithm, and I
would like this to continue to be the norm and the default behavior.
If there has been no explicit agreement regarding truncation, as in
the case of agreements predating the draft, the full digest should be
sent by the sender and nothing less than the full digest should be
accepted by the receiver.

@@@ Re your paragraph above and paragraph below, the change will be
to (1) state that policies SHOULD be implemented such that if a
particular runcation would be accepted, a longer signatures (less
truncation) SHOULD also be accepted and (2) that if a request is
received with a particular truncation, the corresponding reply
SHOULD be sent with no less trncation than the request, even if
the policy would normally allow greater truncation (shorter
signature). These changes did not come out of thin air but were
based on the implimentation experience of Mark Andrews.

@@@ Donald

> #4 add text if responder can use different truncation than sender

This seems like an unnecessary complication.  RFC2845 doesn't allow a
response to use an algorithm or key different from the request; why
should truncation be treated any differently?
-- 
Andreas Gustafsson, [email-masked]