This is a discussion on RE: [dhcwg] Open issues in DHCP FQDN, DHCID and DDNS-DHCP Related RFCs - DNS ; [ 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 ...
[ 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. ]
I'm perfectly happy with MD5 too. I'm only doing this because this was =
apparently a blocking issue with the IESG. I'm not even an author on the =
DHCID RR draft, but have volunteered to sheppard it through because the =
authors have lost interest. (Though if one or more of the authors wants =
to pick this up, let me know and I'll send along the xml file for the =
While we could do as Ted suggests (drop the encoding), I personally am =
uncomfortable with that because I think the information will leak out =
and better for it not to be obvious (though I guess if it was obvious it =
would teach folks quickly not to let it leak?). I also don't recall the =
history (because I either wasn't involved or was fairly disinterested at =
the time) the reason for encoding this, but suspect it was to make it =
somewhat difficult for someone to find the client's identity and =
potentially track the user through the Internet as they connect to =
different access networks (assuming the DHCID RR was available). I don't =
believe the goal was ever to make it impossible, just somewhat difficult =
so that most folks wouldn't bother.
BTW, most of the options are definitely not fun for me because it will =
require more changes to the DHCID RR draft and the conflict resolution =
draft, since there needs to be something said about what happens if a =
DHCID RR exists and the data doesn't match -- if the "digest type" is =
different, then the updater might have to switch to that digest (if =
supported), ... If not supported, well, I guess one must assume the FQDN =
is in use and try a different FQDN.
> -----Original Message-----
> From: David W. Hankins [mailtoavid_Hankins@isc.org]=20
> Sent: Tuesday, February 07, 2006 7:31 PM
> To: Bernie Volz (volz)
> Cc: firstname.lastname@example.org; dhcwg; Olaf Kolkman;=20
> Harald@Alvestrand.no; Stig Venaas; =D3lafur Gu>mundsson /DNSEXT=20
> co-chair; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] Open issues in DHCP FQDN, DHCID and=20
> DDNS-DHCP Related RFCs
> On Mon, Feb 06, 2006 at 09:59:11AM -0500, Bernie Volz (volz) wrote:
> > Possible solutions to the hash algorithm issue are:
> > 1. Switch from MD5 to SHA-1 or SHA-256 as the "base"=20
> algorithm. This won't help down the road if these are found=20
> to have significant weaknesses.
> > 2. Add a field (octet) to the DHCID RR RDATA to specify the=20
> algorithm used (perhaps using the digest type field and=20
> assignments used by the DS record, RFC 3658, and=20
> http://www.iana.org/assignments/ds-rr-types). The RDATA would=20
> thus be formatted as
> octet)> . This also means a change to SHA-1=20
> as the base algorithm or we'd need to request IANA to=20
> allocate a MD5 digest code. (The SHA-1 digest is 20 octets=20
> instead of MD5's 16 octets.)
> > 3. Incorporate the hash algorithm into the existing RR type=20
> code field, which means a change of algorithm requires new RR=20
> type codes to be assigned (likely 3 new codes per algorithm).
> > 4. Don't change the RDATA format or algorithm. Though this=20
> 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=20
> IESG requirements and is the most flexible. Whether we switch=20
> to SHA-1 or request a digest type assignment for MD5 is=20
> debatable, but unless there are significantly different=20
> export restrictions or licensing issues for MD5 vs. SHA-1,=20
> let's just 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=20
> 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=20
> 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,=20
> 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=20
> 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=20
> first time,
> Software Engineer you'll just have to do=20
> it again."
> Internet Systems Consortium, Inc. -- Jack T. Hankins
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.