Subject: Re: DNSEXT WG Last Call: TSIG/SHA document

From: Samuel Weiler <[email-masked]>
Date: Tue, 1 Mar 2005 05:15:28 -0500 (EST)

I concur with Andreas's well-written comments, particularly:

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

I'm not sure if in-band communication of truncation minima is
required, but this doc at least needs more text devoted to the topic,
as Andreas has suggested.  I'd also be happy with just removing
truncation, though I imagine there's some good reason for it that I
haven't heard yet.

Other than that, the doc looks good -- I'd be happy to see it advance.

For the benefit of others who may read this doc, I initially wondered
why this doc uses algorithm names in a different namespace than the
one defined in 2845.  Section 7 of 2845 says that is to be expected.

And a nit: there's a normative reference to 2434, but no citation to
2434 in the doc.  The RFC Editor will toss that one back.

-- 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: Donald Eastlake III <[email-masked]>
Date: Tue, 1 Mar 2005 09:31:47 -0500 (EST)

Needless to say, I support the document but enough requests have been 
posted for some more security guidance that I think I should revise it 
once more and post after the IETF meeting. Guidance as to the level of
implementation requirement for varous hash functions would be
appreciated or should they just be left as they are in the current
draft?

There is some mention in the document of weaknesses being found in hash 
algorithms recently. I suppose it should say a little more but I do not 
see any reason to expand substantially on that or try to make the draft 
into a treatise on the subject.

From the draft:                                        "increasingly
    successful cryptanalytic attacks are being made on the shorter
    hashes"

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 Wed, 23 Feb 2005, [iso-8859-1] Ólafur Guðmundsson wrote:

> Date: Wed, 23 Feb 2005 12:01:54 -0500
> From: "[iso-8859-1] Ólafur Guðmundsson" <[email-masked]>
> To: Stephane Bortzmeyer <[email-masked]>
> Cc: [email-masked]
> Subject: Re: DNSEXT WG Last Call: TSIG/SHA document
> 
> At 11:23 23/02/2005, Stephane Bortzmeyer wrote:
>> On Wed, Feb 23, 2005 at 10:36:06AM -0500,
>>  Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]> wrote
>>  a message of 28 lines which said:
>> 
>> > 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.
>> 
>> 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
>
>
> <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: Mark Andrews <[email-masked]>
Date: Wed, 02 Mar 2005 08:35:18 +1100

>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
> 
> --0-910715544-1109686561=:23771
> Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; FORMAT=flowed
> Content-Transfer-Encoding: QUOTED-PRINTABLE
> Content-ID: <[email-masked]>
> 
> Needless to say, I support the document but enough requests have been=20
> posted for some more security guidance that I think I should revise it=20

	The document had enough detail to implement non-truncated
	hash functions.
 
> There is some mention in the document of weaknesses being found in hash=20
> algorithms recently. I suppose it should say a little more but I do not=20
> see any reason to expand substantially on that or try to make the draft=20
> From=20the draft:                                        "increasingly
>   =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> On Wed, 23 Feb 2005, [iso-8859-1] =D3lafur Gu=F0mundsson wrote:
> 
> > From: "[iso-8859-1] =D3lafur Gu=F0mundsson" <[email-masked]>
> >=20
> >>  =D3lafur Gu=F0mundsson /DNSEXT co-chair <[email-masked]> wrote
> >>=20
> >>=20
> >>=20
> >        =D3lafur=20
> --0-910715544-1109686561=:23771--
> 
> --
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 1 Mar 2005 16:57:44 -0500 (EST)

On Tue, 1 Mar 2005, Donald Eastlake III wrote:
>
> Guidance as to the level of implementation requirement for varous
> hash functions would be appreciated or should they just be left as
> they are in the current draft?

I like the list as it stands.  I'd support requiring (with a 2119
SHOULD) software that supports this spec to have a way of specifying
which hash algorithms (and truncations) are (dis-)allowed.  Thinking
about this more, the point about prior agreement is winning me over --
I don't see a need to do hash/truncation negotiation on-line
(specifically, no need to communicate a minumum acceptable bit
length).

> into a treatise on the subject.

Concur.

-- Sam