Subject: RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 6 Feb 2006 09:59:11 -0500

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

As I'd like to re-submit these drafts as soon as possible, we need to resolve

>7.  Add an 8-bit algorithm identifier to the DHCID RR to
>    support algorithm agility (Allison Mankin)
>8.  Use of MD5 as opposed to a stronger hash function (Sam Hartman,
>    Russ Housley)
>9.  Hash agility (Sam Hartman, Allison Mankin)
>10. Russ's comment that an attacker that has some knowledge of MAC
>    addresses does not need to do lot of work. I think this can be
>    addressed in security considerations by saying this is not privacy
>    but just obfuscation (Russ Housley)

Possible solutions to the hash algorithm issue are:

1. Switch from MD5 to SHA-1 or SHA-256 as the "base" algorithm. This won't help down the road if these are found to have significant weaknesses.

2. Add a field (octet) to the DHCID RR RDATA to specify the algorithm used (perhaps using the digest type field and assignments used by the DS record, RFC 3658, and http://www.iana.org/assignments/ds-rr-types). The RDATA would thus be formatted as <RR TYPE (2 octets)><Digest Type (1 octet)><Digest (n octets)>. This also means a change to SHA-1 as the base algorithm or we'd need to request IANA to allocate a MD5 digest code. (The SHA-1 digest is 20 octets instead of MD5's 16 octets.)

3. Incorporate the hash algorithm into the existing RR type code field, which means a change of algorithm requires new RR type codes to be assigned (likely 3 new codes per algorithm).

4. Don't change the RDATA format or algorithm. Though this would likely block this work from proceeding through the IESG?

Perhaps there's other solutions?

I'm inclined to pick 2 as I believe it meets all of the IESG requirements and is the most flexible. Whether we switch to SHA-1 or request a digest type assignment for MD5 is debatable, but unless there are significantly different export restrictions or licensing issues for MD5 vs. SHA-1, let's just switch to SHA-1? 

Comments please!

- Bernie

--
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: Ted Lemon <[email-masked]>
Date: Mon, 6 Feb 2006 19:47:50 -0700

> Perhaps there's other solutions?

My vote would be to take out the hash entirely - it was unnecessary to begin 
with, and the idea of radically complexifying the protocol to make it more 
secure when there was no real need for it in the first place strikes me as a 
huge and painful mistake.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 7 Feb 2006 16:31:18 -0800

> I'm inclined to pick 2 as I believe it meets all of the IESG requirements and is the most flexible. Whether we switch to SHA-1 or request a digest type assignment for MD5 is debatable, but unless t…

Funny, I was going to say '2 is right out'.  I don't like the
implications of people trying to be reverse-algorithm compatible, or
the fact that there's no way to roll between algorithms except
all-stop, delete, restart.

There's a contradiction in Ted's and Bernie's statements here I want to
point out.  Bernie says if SHA-X is found weak, that's a problem.  Ted
says we can just remove the encoding.

One of these two statements has to be false if the other is true.  If
we can remove the encoding, then we don't care if SHA-X is weak.  If
we care if SHA-X is weak, then we can't remove the encoding.

Obviously I agree with Ted, I think the encoding is more political
problem than technical reward.

In that case, there's no reason to care if SHA-x is weak because the
alternative was cleartext.  So why not just go with door #1 if that
makes the IESG happy?

One of my coworkers (who, wishing not to be named "bad idea fairy" will
for the moment be kept anonymous) suggests we adopt ROT13.  Actually,
some zone admins might be able to read that without a filter, so perhaps
we should just XOR the field by 0xFF.

If cleartext is an acceptable answer, which I think it is, than any
obfuscation that makes plaintext unreadable is equivalent, even if
that equivalent obfuscation is a *different* weak digest algorithm.

MD5 was the right answer.  There's no other way to say it.

So in my final analysis, if switching to SHA-1 or SHA-256 gets it past
IESG, I think that's better than ROT13 or XOR 0xFF, which I think is
better than removing the encoding entirely, which I think is better
than switching to an encoding byte, which I think is better than making
the encoding part of the type field.

But really, the success story here would be if we made no changes and
just stuck with MD5.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins