Re: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs
[ 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. ]
Content-Type: text/plain; charset=us-ascii
On Mon, Feb 06, 2006 at 09:59:11AM -0500, Bernie Volz (volz) wrote:[color=blue]
> Possible solutions to the hash algorithm issue are:
> 1. Switch from MD5 to SHA-1 or SHA-256 as the "base" algorithm. This won'=[/color]
t help down the road if these are found to have significant weaknesses.[color=blue]
> 2. Add a field (octet) to the DHCID RR RDATA to specify the algorithm use=[/color]
d (perhaps using the digest type field and assignments used by the DS recor=
d, RFC 3658, and [url]http://www.iana.org/assignments/ds-rr-types[/url]). The RDATA wo=
uld 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.)[color=blue]
> 3. Incorporate the hash algorithm into the existing RR type code field, w=[/color]
hich means a change of algorithm requires new RR type codes to be assigned =
(likely 3 new codes per algorithm).[color=blue]
> 4. Don't change the RDATA format or algorithm. Though this would likely b=[/color]
lock this work from proceeding through the IESG?[color=blue]
> Perhaps there's other solutions?
> I'm inclined to pick 2 as I believe it meets all of the IESG requirements=[/color]
and is the most flexible. Whether we switch to SHA-1 or request a digest t=
ype assignment for MD5 is debatable, but unless there are significantly dif=
ferent export restrictions or licensing issues for MD5 vs. SHA-1, let's jus=
t switch to SHA-1?=20
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
-----END PGP SIGNATURE-----
to unsubscribe send a message to [email]email@example.com[/email] with
the word 'unsubscribe' in a single line as the message text body.