Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
On Mon, Nov 28, 2005 at 05:20:09PM -0500, Bernie Volz (volz) wrote: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. It does, though it only encodes the client identity (client identifier option or chaddr), it does not include the FQDN like the current DHCID draft does. There are a few niggling bits that are different, and obviously incompatible (not just because it's encoded as hexadecimal in a TXT record), but on all points that are topical to this discussion it's the same. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of you can know the expected content of the record without fetching it. Yup. My only objection to changing the hash algorithm is that it means a rev of the document that could cause us to go through another wglc or ietf last call (as opposed to editorial changes, which presumably would not). Otherwise, while I don't think it makes any difference, it's otherwise fine to use SHA-256 instead of MD5. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
The Nominum DHCP server (DCS) supports the exact mechanism described in the collection of documents, except that the data is stored in a TXT record rather than a DHCID record, because we are waiting on the DHCID record. We also implement the older version of the protocol that the ISC server supports, which as David says is only slightly different than the current spec. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Monday, November 28, 2005 11:49 AM To: Ted Lemon Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org; Pekka Savola; ietf@ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] In message [EMAIL PROTECTED], Ted Lemon writes: Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. The updater would then use local policy -- that is, an ordered list of preferred hash functions -- until it found one that was in the response. That one would be used. If no locally-known hash functions are in the list, it should behave as if there were no DHCID records present for that name. DNSSEC could protect against downgrade attacks. (Speaking of which -- were I still AD, I'd ding this document for an inadequate Security Considerations section -- apart from the lack of discussion of brute force attacks, you should cite 3833 for DNS attacks and explain what the risks are if someone can crack the hash function by any means, including brute force or eavesdropping on the wire or (perhaps) a misbehaving updater.) If you don't agree, I'd strongly suggest using SHA-256 instead of MD5. Yes, it's more expensive, but I doubt that that's a major hit on overall system performance here. It would also be useful to include in the document some discussion of upgrade strategy -- how would we ever switch to a new hash function? That's non-trivial even for protocols designed for agility, as Eric Rescorla and I have shown. No matter how it's done, this one is among the very hardest, since DNS servers would have to supply DHCID records for several hashes for a number of years. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
BTW, whatever algorithm you use (SHA-256 or even something much more complex) is not going to help -- it may make the work someone has to do a bit more involved, but it really doesn't make it impossible. 1. You always have a brute force attack. As you indicate, calculating the hash based on the mac address is always going to be a possible attack. And, 8000 is not 8-bits, but more like 13. But agreed that many of the Ethernet OIDs are unlikely to be of much interest. 2. If the attacker is on the same network as the client at some point, they can learn the identifier of the client (snoop DHCP and/or ARP traffic). Once they have that, it is possible to query DNS for DHCID RRs (query for the PTR, query for a DHCID RR for the name). Once you have that, you use the name and client's identity and run it through the algorithm and check for a match. If you looked up all 2^32 PTRs, you'd be able to locate the client at other sites that use DHCP and export the DHCID RR information. The number of PTRs you'd likely have to query is much smaller than 2^32s. You could target just some domains (network addresses) that you were most interested in or where you suspect the client connects to the network. Far reducing the number of queries needed. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Monday, November 28, 2005 11:49 AM To: Ted Lemon Cc: iesg@ietf.org; dhcwg@ietf.org; namedroppers@ops.ietf.org; Pekka Savola; ietf@ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] In message [EMAIL PROTECTED], Ted Lemon writes: Making a hash function interchangeable in DHCID makes the conflict detection algorithm hugely more complicated, and possibly not workable at all. Think about how that would work. I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. The updater would then use local policy -- that is, an ordered list of preferred hash functions -- until it found one that was in the response. That one would be used. If no locally-known hash functions are in the list, it should behave as if there were no DHCID records present for that name. DNSSEC could protect against downgrade attacks. (Speaking of which -- were I still AD, I'd ding this document for an inadequate Security Considerations section -- apart from the lack of discussion of brute force attacks, you should cite 3833 for DNS attacks and explain what the risks are if someone can crack the hash function by any means, including brute force or eavesdropping on the wire or (perhaps) a misbehaving updater.) If you don't agree, I'd strongly suggest using SHA-256 instead of MD5. Yes, it's more expensive, but I doubt that that's a major hit on overall system performance here. It would also be useful to include in the document some discussion of upgrade strategy -- how would we ever switch to a new hash function? That's non-trivial even for protocols designed for agility, as Eric Rescorla and I have shown. No matter how it's done, this one is among the very hardest, since DNS servers would have to supply DHCID records for several hashes for a number of years. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
--On mandag, november 28, 2005 17:00:39 -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. Bernie, just checking this puzzle seems to have several distinct pieces: - the DHCP options to talk about DNS names. Nobody seems to have any large problem with that. - the mechanism for detecting conflicts. Nobody seems to have any large problem with that. - the exact mechanism by which one stores a value identifying the client in the DNS without giving out useful information about the client. That's where all the shouting is. Can you verify for me that all three parts are being done today in production, in just the way (apart from RR type) specified in the I-Ds? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
Harald: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. As does Cisco's Network Registrar (though it presently doesn't encode the data using MD5). And, I'm pretty sure several other DHCP vendors do this -- though whether they're using MD5 or not I can't be sure. These servers are in production all over and have been doing this for many years. - Bernie -Original Message- From: Harald Tveit Alvestrand [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 5:14 PM To: Bernie Volz (volz); Steven M. Bellovin; Ted Lemon Cc: dhcwg@ietf.org; Pekka Savola; ietf@ietf.org; namedroppers@ops.ietf.org Subject: RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] --On mandag, november 28, 2005 17:00:39 -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: I confess that I don't see the problem. The updater would do a DNS query for DHCID RRs; it would be given all of the stored records. That's not how the current update algorithm works. Sure, we could do almost anything but we'll be debating this for the next 100 years. It has already gone on for almost 10 years!!! Can we get serious about this and really ask what are we trying to protect. And where were you folks when IPv6 was designed to use the mac address as the interface identifier. Come on. We're trying to make it NON-TRIVIAL, not impossible. This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. Bernie, just checking this puzzle seems to have several distinct pieces: - the DHCP options to talk about DNS names. Nobody seems to have any large problem with that. - the mechanism for detecting conflicts. Nobody seems to have any large problem with that. - the exact mechanism by which one stores a value identifying the client in the DNS without giving out useful information about the client. That's where all the shouting is. Can you verify for me that all three parts are being done today in production, in just the way (apart from RR type) specified in the I-Ds? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
BTW: Just to be clear, the MD5 hash is calculated using both the client identifier AND the domain name. But the domain name is known (it is the entry under which the DHCID RR lives). However, this means that the DHCID data for a client changes with its name. The RDATA for all type codes other than 0x, which is reserved for future expansion, is formed by concatenating the two type bytes and a 16-byte MD5 hash value. The input to the hash function is defined to be: data = MD5( identifier FQDN ) The FQDN is represented in the buffer in unambiguous canonical form as described in RFC 2535 [8], section 8.1. The type code and the identifier are related as specified in Section 3.3: the type code describes the source of the identifier. - Bernie -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven M. Bellovin Sent: Saturday, November 26, 2005 11:57 AM To: Pekka Savola Cc: dhcwg@ietf.org; namedroppers@ops.ietf.org; iesg@ietf.org; ietf@ietf.org Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard] In message [EMAIL PROTECTED], Pekka Savola writes: 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. I agree with this comment. The draft is wrong -- it asserts that a successful attack of MD5's weakness does not reveal the original data. That's an overassumption -- we have no idea what such an attack would yield, since no such attack currently exists. More generally... The currently-known attacks on MD5 are collision attacks: it's possible to generate two inputs that produce the same hash value. This scenario requires a preimage attack; none are known. It would not surprise me if someone were to develop one, but until that happens we can't speculate on its properties
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
Thanks - these responses point out very clearly that the mechanism is being used as described, *except* for the bit that's contentious (use of MD5 for information hiding). This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of you can know the expected content of the record without fetching it. Harald --On mandag, november 28, 2005 17:20:09 -0500 Bernie Volz (volz) [EMAIL PROTECTED] wrote: Harald: Yes, I can. The ISC's DHCP server (www.isc.org) does this (I'm not sure whether it uses MD5 to encode the client identity or not). Ted might know for sure. As does Cisco's Network Registrar (though it presently doesn't encode the data using MD5). And, I'm pretty sure several other DHCP vendors do this -- though whether they're using MD5 or not I can't be sure. These servers are in production all over and have been doing this for many years. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution ofFQDN Conflicts among DHCP Clients' to Proposed Standard]
--On tirsdag, november 29, 2005 00:03:03 -0700 Ted Lemon [EMAIL PROTECTED] wrote: On Monday 28 November 2005 23:40, Harald Tveit Alvestrand wrote: This means that we will not have a backwards compatibility issue with the installed base if we change the format of the record, but *will* have a procedural compatibility issue if we don't keep the property of you can know the expected content of the record without fetching it. Yup. My only objection to changing the hash algorithm is that it means a rev of the document that could cause us to go through another wglc or ietf last call (as opposed to editorial changes, which presumably would not).Otherwise, while I don't think it makes any difference, it's otherwise fine to use SHA-256 instead of MD5. After reading the docs, I don't think it makes any difference either. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
