DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
Pekka Savola <pekkas@netcore.fi> Sat, 26 November 2005 14:22 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg0x8-00074g-OG; Sat, 26 Nov 2005 09:22:58 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg0x6-00074Q-S9; Sat, 26 Nov 2005 09:22:56 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15177; Sat, 26 Nov 2005 09:22:13 -0500 (EST)
Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eg1Ga-0002jS-Hi; Sat, 26 Nov 2005 09:43:05 -0500
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAQEMZr26735; Sat, 26 Nov 2005 16:22:36 +0200
Date: Sat, 26 Nov 2005 16:22:35 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: iesg@ietf.org
In-Reply-To: <E1EbpXa-0007U9-4f@newodin.ietf.org>
Message-ID: <Pine.LNX.4.64.0511261615210.26558@netcore.fi>
References: <E1EbpXa-0007U9-4f@newodin.ietf.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
Cc: dhcwg@ietf.org, ietf@ietf.org, namedroppers@ops.ietf.org
Subject: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Hi, I'll break out the most substantial comments in separate messages.. On Mon, 14 Nov 2005, The IESG wrote: > The IESG has received a request from the Dynamic Host Configuration WG to > consider the following documents: > > - 'A DNS RR for Encoding DHCP Information (DHCID RR) ' > <draft-ietf-dnsext-dhcid-rr-10.txt> as a Proposed Standard > - 'Resolution of FQDN Conflicts among DHCP Clients ' > <draft-ietf-dhc-ddns-resolution-10.txt> as a Proposed Standard > - 'The DHCP Client FQDN Option ' > <draft-ietf-dhc-fqdn-option-11.txt> as a Proposed Standard > - 'The DHCPv6 Client FQDN Option ' > <draft-ietf-dhc-dhcpv6-fqdn-03.txt> as a Proposed Standard I have only one major comment on DHCID on its use of MD5 as a glued-in hash-function. The rest of the comments are rather straightforward. substantial ---------- In order to avoid exposing potentially sensitive identifying information, the data stored is the result of a one-way MD5 [5] hash computation. The hash includes information from the DHCP client's REQUEST message as well as the domain name itself, so that the data stored in the DHCID RR will be dependent on both the client identification used in the DHCP protocol interaction and the domain name. This means that the DHCID RDATA will vary if a single client is associated over time with more than one name. This makes it difficult to 'track' a client as it is associated with various domain names. The MD5 hash algorithm has been shown to be weaker than the SHA-1 algorithm; it could therefore be argued that SHA-1 is a better choice. However, SHA-1 is significantly slower than MD5. A successful attack of MD5's weakness does not reveal the original data that was used to generate the signature, but rather provides a new set of input data that will produce the same signature. Because we are using the MD5 hash to conceal the original data, the fact that an attacker could produce a different plaintext resulting in the same MD5 output is not significant concern. ==> while the informatione exposure of someone cracking the MD5 hash is not too huge, I believe it is unacceptable to design new protocols without the capability to switch the hash function as need be. This could be achieved for example by reserving one additional byte from the start of the DHCID record to designate the hash function used. If you don't bother to define your own registry (for all of me, you could include MD5 there as well, but at least include SHA1 and preferably also SHA-256), you could possibly re-use http://www.iana.org/assignments/ds-rr-types or something like that. That way, we can introduce new hash functions in a backward compatible manner later on, with no need to revamp the protocol. If we don't do this, we'll need to define DHCID2, DHCID3, .. etc. records further down in the future (w/ different hash functions) and make DHCP co-exist with all of them. That's bound to cause a lot of protocol complexity, and I don't think we want to go there. ... New DHCID RR type codes are tentatively assigned after the specification for the associated type code, published as an Internet Draft, has received expert review by a designated expert. The final assignment of DHCID RR type codes is through Standards Action, as defined in RFC 2434 [6]. ==> this new RR type code assignment procedure seems to be underspecified. Is there actually harm in just doing this through expert review, and giving the expert guidance that at least an I-D must be published? If so, you could reword this like: New DHCID RR type codes are assigned through Standards Action or Expert Review as defined in RFC2434 [6]. The expert should require sufficient public specification of the new type code. .. in any case, please use existing RFC2434 mechanism unless you're absolutely sure those won't fit your needs. semi-editorial -------------- Conflicts can arise if multiple DHCP clients wish to use the same DNS name. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. ==> conflicts also occur when multiple nodes use the same FQDN while only a part of them uses DHCP. So, the above applicability could be reworded, e.g., like follows: Conflicts can arise if multiple nodes wish to use the same DNS name. To resolve such conflicts when the nodes are using DHCP, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients using them. 3.5. Examples ==> I'd also have liked to see an example of DHCPv6 DHCID generation. editorial --------- A DHCP server allocating the IPv4 address 10.0.0.1 to a client with Ethernet MAC address 01:02:03:04:05:06 using domain name "client.example.com" uses the client's link-layer address to identify the client. ==> you should probably use RFC3330 documentation prefix here instead of 10/8. To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] proposes storing client identifiers in the DNS to unambiguously associate domain names with the DHCP clients to which they refer. ==> no refs in the abstract A set of procedures to allow DHCP [7] clients and servers to automatically update the DNS (RFC 1034 [3], RFC 1035 [4]) is proposed in "Resolution of DNS Name Conflicts" [1]. ==> also refer DHCPv6 here, please -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- DHCID and the use of MD5 [Re: Last Call: 'Resolut… Pekka Savola
- DHCP and FQDN conflicts [Re: Last Call: 'Resoluti… Pekka Savola
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Steven M. Bellovin
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Pekka Savola
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Sam Hartman
- RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Las… Bernie Volz (volz)
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Ted Lemon
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Steven M. Bellovin
- Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Las… Steven M. Bellovin
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Ted Lemon
- Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Las… Ted Lemon
- Re: DHCID and the use of MD5 [Re: Last Call: 'Res… Ted Lemon
- Re: DHCID and the use of MD5 Russ Housley
- Re: DHCID and the use of MD5 Sam Hartman
- Re: DHCID and the use of MD5 Russ Housley
- Re: DHCID and the use of MD5 Paul Hoffman
- Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Las… Mark Stapp
- Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Las… Sam Hartman
- Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Cal… Pekka Savola
- Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Cal… David W. Hankins
- Re: [dhcwg] DHCP and FQDN conflicts [Re: Last Cal… David W. Hankins