How about we address issue 1 by expanding the DHCID RR type code. We
have 16-bits and we're just using 4 values presently. There's plenty of
room for future expansion *SHOULD* someone come along and demand a new
algorithm in the future. I can't see why this would EVER occur since
this really isn't about strong cryptographic protection (we're just
trying to make it non-trivial to find a client's identity by not storing
it in clear text).
In the -10 draft, Section 3.3 is:
3.3. The DHCID RR Type Codes
The DHCID RR Type Code specifies what data from the DHCP client's
request was used as input into the hash function. The type codes are
defined in a registry maintained by IANA, as specified in Section 7.
The initial list of assigned values for the type code is:
0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7].
0x0001 = The data portion from a DHCPv4 client's Client Identifier
option [9].
0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
client's Client Identifier option [10] or the DUID field from a
DHCPv4 client's Client Identifier option [12]).
0x0003 - 0xfffe = Available to be assigned by IANA.
0xffff = RESERVED
---
Replace with:
3.3. The DHCID RR Type Codes
The DHCID RR Type Code specifies what data from the DHCP client's
request was used as input into the hash function and the hash
function used. The type codes are defined in a registry maintained
by IANA, as specified in Section 7. The initial list of assigned
values for the type code is:
0x0000 = htype, chaddr from a DHCPv4 client's DHCPREQUEST [7] and
MD5 hash.
0x0001 = The data portion from a DHCPv4 client's Client Identifier
option [9] and MD5 hash.
0x0002 = The client's DUID (i.e., the data portion of a DHCPv6
client's Client Identifier option [10] or the DUID field from a
DHCPv4 client's Client Identifier option [12]) and MD5 hash.
0x0003 - 0xfffe = Available to be assigned by IANA.
0xffff = RESERVED
---
Note: I used MD5 since that is what the drafts presently specify.
This does mean that using the existing update mechanisms as described in
the conflict resolution draft will only work if all servers (and clients
doing updates) use the same hash algorithm as specified today.
But I don't see that being an issue as again, I suspect we'll never
change the algorithm. And, if we do, we can revise the update procedure
when the draft specifying the new DHCID RR types / algorithm is written.
I think this provide Sam his desired ability to rev the algorithm
without having to use a new DHCID RR type. And, it avoids complicating
the current update producure unnecessarily.
- Bernie
-----Original Message-----
From: dhcwg-bounces(_at_)ietf(_dot_)org
[mailto:dhcwg-bounces(_at_)ietf(_dot_)org]
On Behalf Of Sam Hartman
Sent: Tuesday, November 29, 2005 2:48 PM
To: Mark Stapp (mjs)
Cc: namedroppers(_at_)ops(_dot_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org;
iesg(_at_)ietf(_dot_)org;
Steven M. Bellovin; dhcwg(_at_)ietf(_dot_)org; Pekka Savola; Ted Lemon
Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last
Call:'Resolution of FQDN Conflicts among DHCP Clients' to
Proposed Standard]
"Mark" == Mark Stapp <mjs(_at_)cisco(_dot_)com> writes:
Mark> would such a clarification be "enough" to resolve your
Mark> DISCUSS, Sam Hartman? that is, if it were clearer that we're
Mark> only aiming for more difficult than not difficult at all -
Mark> would that be sufficiently clear guidance to admins about
Mark> what they should expect from this mechanism?
So, as I described in my response to Russ, I'm asking for
three things:
1) algorithm agility
2) Remove the paragraph explaining why md5 is OK or provide a
theoretical model under which we can reason about how good a hash
is at keeping stuff private.
3) Use sha-1 or sha-256 instead of md5.
I feel very strongly about point 1. Unfortunately I think this is the
point the working group most objects to. I understand the concerns
about the complexity of the update process. However I also know that
security primitives are things that you need to replace from time to
time. If you were using md5 because it had a relatively even
distribution of outputs you could probably convince me that you don't
need a way to update it. However even if weakly you're using md5 for
its cryptographic properties. Those can change over time so you need
a mechanism to react to those changes.
I suspect we can all agree that we need to either reword claims about
security of cryptographic primitives so they are clearly true or
remove those claims. So I don't think that we're going to have much
of an issue with point 2.
I think there is room for discussion on point 3. I think sha-1 or
sha-256 would be a better choice. I think that there is an argument
that md5 is not so bad that it cannot be used. If the working group
ends up responding that it would really like to use md5, I can go to
the security community and see what people think there.
--Sam
_______________________________________________
dhcwg mailing list
dhcwg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf