Subject: DNSEXT WG Last Call: TSIG/SHA document

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Wed, 23 Feb 2005 10:36:06 -0500

This WG last call ends March 12'th 2005.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt

The TSIG protocol provides transaction level authentication for DNS.
TSIG is extensible through the definition of new algorithms.  This
document specifies an algorithm(s) from the SHA algorithm family.
This document specifies 4 new TSIG/HMAC algorithms, if there are any
issues with defining any of the algorithms, please state so and why.

This draft is on standards track, if you disagree with that please state why
in your response.

The there are no reports of implementations, if you are aware of any please
let us know.

In order to advance this document, the chairs must receive some
messages of support for this document.
Silence will result in dropping the document.

	Olafur and Olaf

--
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: "Scott Rose" <[email-masked]>
Date: Wed, 23 Feb 2005 10:58:48 -0500

I support this document.  I do not know of any implementations yet.
Hopefully I can get the ball rolling on at least one effort.

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Olafur Gu?mundsson
> /DNSEXT co-chair
> Sent: Wednesday, February 23, 2005 10:36 AM
> To: [email-masked]
> Subject: DNSEXT WG Last Call: TSIG/SHA document
>
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 23 Feb 2005 17:23:25 +0100

On Wed, Feb 23, 2005 at 10:36:06AM -0500,
 Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]> wrote 

> document specifies an algorithm(s) from the SHA algorithm family.

The Security Considerations do not mention the very recent attacks on
SHA-1, which, IMHO (I am not a cryptographer) should stop this
document from going on the Standards Track (pending further studies).

http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 23 Feb 2005 13:41:22 -0300

On Wed, Feb 23, 2005 at 05:23:25PM +0100, Stephane Bortzmeyer wrote:
...
> document from going on the Standards Track (pending further studies).

HMAC based on SHA doesn't suffer this attack. There is plenty of
cryptographers in this list to confirm this. Let the document go !

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Wed, 23 Feb 2005 12:01:54 -0500

>http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

<chair-hat on>
Excellent point, the document should address this issue before being
advanced.

I checked with some people that know cryptography before issuing this
last call, they do not see an issue with THIS USE of SHA-1.
<chair-hat off>

<TSIG-RFC-editor-hat on>
According to cryptographers:
The HMAC addition protects the underlying algorithm from the
vulnerabilities found in SHA-1.
http://jis.mit.edu/pipermail/saag/2005q1/001184.html

IMHO more given the short time TSIG signatures are valid, and
the great control each TSIG generator has over the input this
is not a great risk.
<TSIG-RFC-editor-hat off>

<no-hat on>
Having said that the WG can decide to list SHA-1 as Optional,
not mandatory as in the current draft.
Note also HMAC/SHA-256 is listed as mandatory to implement and that is
the algorithm people should be using if they want to significantly
improve security over HMAC/MD5

         Ólafur

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 23 Feb 2005 20:00:21 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-tsig-sha-01.txt

I think the draft needs to emphasize the distinction between
implementing an algorithm and having a policy of accepting messages
signed by that algorithm, especially when most existing
implementations do not yet need to make that distinction because they
only deal with a single algorithm.  It would be unfortunate if an
implementor interpreted "must implement SHA-1" as "must accept
messages signed with SHA-1" (or even as "should accept them by
default"), since accepting messages signed with a new algorithm
without rejecting messages signed with the old one can only hurt
security.

What would be particularly bad is if someone made their implementation
accept messages with the MAC truncated to a single octet just because
the draft says "MAY implement any or all other truncations".  Such an
implementation would of course be completely insecure, breakable in
128 tries on average.  Although the Security Considerations section
does note that "excessive truncation clearly weakens authentication",
I don't think it makes it sufficiently clear that the risk doesn't
lie in excessive truncation by the sender but in the acceptance
of excessively truncated hashes by the receiver.
-- 
Andreas Gustafsson, [email-masked]

---

From: Robert Elz <[email-masked]>
Date: Thu, 24 Feb 2005 08:31:23 +0700

Date:        Wed, 23 Feb 2005 20:00:21 +0200
    From:        [email-masked] (Andreas Gustafsson)
    Message-ID:  <[email-masked]>

  | I think the draft needs to emphasize the distinction between
  | implementing an algorithm and having a policy of accepting messages
  | signed by that algorithm,

And *I* think there are way too many attempts in the IETF to mandate
quality of implementation issues.   All we're supposed to be concerned
with is interoperability.   In bilateral protocols like TSIG that
doesn't require very much.

If there's a sub-standard TSIG implementation around, that doesn't meet
your requirements, then just find a better one.

If there's something in the spec that harms either interoperability, or
of correct operation of the protocol, by all means, object to it.   But
if the only complaint is that it is possible for people to use it in ways
that don't meet your needs, then just leave it alone.

kre