RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
- To: "Bernie Volz (volz)" <volz at cisco.com>, Sam Hartman <hartmans-ietf at mit.edu>, "Mark Stapp (mjs)" <mjs at cisco.com>
- Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
- From: Jeffrey Hutzelman <jhutz at cmu.edu>
- Date: Sun, 04 Dec 2005 23:42:58 -0500
- Cc: namedroppers at ops.ietf.org, ietf at ietf.org, iesg at ietf.org, "Steven M. Bellovin" <smb at cs.columbia.edu>, dhcwg at ietf.org, Pekka Savola <pekkas at netcore.fi>, Ted Lemon <Ted.Lemon at nominum.com>
- In-reply-to: <8E296595B6471A4689555D5D725EBB21E71B4A@xmb-rtp-20a.amer.cisco.com>
- List-help: <mailto:ietf-request@ietf.org?subject=help>
- List-id: IETF-Discussion <ietf.ietf.org>
- List-post: <mailto:ietf@ietf.org>
- List-subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
- References: <8E296595B6471A4689555D5D725EBB21E71B4A@xmb-rtp-20a.amer.cisco.c om>
- Sender: ietf-bounces at ietf.org
On Thursday, December 01, 2005 08:48:10 AM -0500 "Bernie Volz (volz)"
<volz at cisco.com> wrote:
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).
I think that's a good start; in fact, I was going to propose something very
similar. This solves half the problem; particularly, it makes it possible
to indicate that some other hash is in use. It does bind the hash to the
type, rather than allowing them to be specified orthogonally, but I don't
think that's a major problem. If it ever becomes an issue, there should be
no problem defining a type where the next 16 bits indicate a subtype and
the 16 bits after that indicate a hash.
However, it doesn't solve the other half of the problem, which is present
even without considering changing hash algorithms. The problem is that for
any given fqdn and DHCP client, there are multiple possible DHCID RR's; in
particular, one for each type. In order the update mechanism to work
without requiring either an advance query or multiple update attempts, all
possible updaters must agree in advance on the type in use. This lack of
negotiation seems problematic to me, even in the absence of multiple hash
algorithms.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions
of the senders and do not imply endorsement by the IETF.
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.