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. ]
As I'd like to re-submit these drafts as soon as possible, we need to =
>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 =
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
octet)> . 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?=20
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.