Subject: Re: DNSEXT WGLC Summary: TSIG SHA1 document

From: Samuel Weiler <[email-masked]>
Date: Thu, 10 Mar 2005 01:55:50 -0500 (EST)

> The working group last call has concluded.

I'm confused.  Perhaps you can explain.

I thought the WG last call on this doc wasn't going to close for
another three days.

http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00391.html

-- Sam

--
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: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Thu, 10 Mar 2005 10:16:24 -0500

>I'm confused.  Perhaps you can explain.

Yes, I'm wrong, we originally scheduled the LC to conclude the
day before the WG meeting and I forgot to update my calendar when we
changed the deadline.

>http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00391.html

So my list posted is the changes that are needed at this point,
and we have enough support to advance the document unless number of
people speak up against the document in the next 3 days.

         sorry about the confusion

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 11 Mar 2005 12:44:22 +0200

Ólafur  Guðmundsson /DNSEXT   co-chair writes:
> 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)

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?

> #2 Set lower bound on truncation (for each algorithm),
> 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.

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.

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

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]

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 22 Mar 2005 15:05:09 -0500

>policy of accepting it"), but what does TKEY have to do with it?

If we have two entities that are trying to set up TSIG using TKEY but
one has policy of preferring ALG X  and the other has policy that ALGX is
not allowed, in this case we need to point out that the responder is within
it's right to refuse exchange.

>intent to require 128-bit HMAC-MD5 signatures?  I don't think that's a

No what this was trying to say is that LOWEST bound ALLOWED by protocol is
half the length of the digest. It is up to implementations and/or
operators to pick the lowest bound they are willing to live with in the
range allowed by protocol.
I agree with you that no one should Truncate MD5.

>accepted by the receiver.

Excellent point

>should truncation be treated any differently?

I will change the direction to say, responder MUST use same truncation as
sender.

         Olafur