Subject: Meeting at IETF-71 in Dublin

From: Ólafur Guðmundsson /DNSEXT chair <[email-masked]>
Date: Tue, 20 May 2008 10:49:39 -0400

DNSEXT will meet, please send in agenda requests.

	Olafur & Andrew 

--
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: Francis Dupont <[email-masked]>
Date: Wed, 21 May 2008 12:10:09 +0200

In your previous mail you wrote:

=> about draft-dupont-dnsext-tsig-md5-deprecated-00.txt:
 - no presentation if you don't require one (there should be
  nothing to say to people who read it, and only "please read it"
  to others :-)
 - WG item question, next steps, etc

Thanks

[email-masked]

PS: I have an improved version (better wording, no new technical thing).
I can wait for an answer to the WG item question or publish it. BTW
we have still a lot of times (more than one month).
PPS: wellcome to the new co-chair!

---

From: Scott Rose <[email-masked]>
Date: Thu, 22 May 2008 12:24:31 -0400

For what it's worth, I support this draft becoming a WG document.

Two comments for the Security Considerations section:
1. From the security folk I've talked too, HMAC-SHA1 is still considered 
"good enough" beyond 2010, which is the time SHA-1 is considered weak 
for digital signatures.  Something about the shared secret makes up for 
the potential weakness in SHA-1.  No, I don't fully understand either 
but they assure me it's acceptable.

2. Would it be a good idea to give some guidance on length of the 
HMAC-SHAXXX shared secret?  I've always referred to the NIST Special 
Publication 800-57 part 1 dealing with security strengths.  The rule of 
thumb there is 80 bits now until 2010, then 112 bits.  The string can be 
longer, but must contain at least 80 bits of "randomness".  I don't 
remember in which document there are suggestions for TSIG shared secret 
length, so why not here?

Scott

-- 
----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnsops.gov/
-----------------------------------------

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 22 May 2008 14:14:04 -0400

HMAC involves a double application of SHA-1, the output of the first
feeding into the second; this is the key to why it's stronger than a
single application of SHA-1.

The length of the shared secret should be at least as long as the output
of the basic hash function according to the original TSIG RFC, RFC 2845.
That RFC just refers to RFC 1750, now obsoleted by RFC 4086, for
discussions of the amount of randomness or entropy.

RFC 4635 talks about allowable truncation. Possibly if the required
minimum entropy is being upped to 112 bits in 2010, consideration should
be given to upping the required minimum truncation size (currently
specified in RFC 4635) to 112 bits at that time...

Thanks,
Donald

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott Rose
Sent: Thursday, May 22, 2008 12:25 PM
To: Francis Dupont
Cc: [email-masked]
Subject: Re: Meeting at IETF-71 in Dublin

Scott

---

From: Francis Dupont <[email-masked]>
Date: Sun, 25 May 2008 22:51:26 +0200

=> fine, thanks!

=> there were some bad things discovered about SHA-1, this is why
the recommendation is to go to SHA-256 (note SHA-224 is enough but
it was not mandatory to support).

=> this is common knowledge (or should be :-). The shared secret should
have a least half of the bits (so SHA-1 -> 80, SHA-224 -> 112) and when
it is longer than the number of the hash it is hashed before to be used,
so longer than the hash gives no more entropy.
   
BTW this is only bound to hash algorithms, not to TSIG, so we can
consider the right guidelines are already included into the references
(if it is not the case it has to be fixed by the security area directors
(if no reference is available) or with their help (if a reference is
available but not pointed to)).

Thanks