Subject: [Gen-art] RE: Gen-ART review of draft-ietf-dhc-ddns-resolution and draft-ietf-dnsext-dhcid-rr

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 28 Nov 2005 10:49:35 -0500

Harald: 

> The problem is simple: The document gives three ways in which a DHCID
RR 
> can be created based on data from a client request. Section 3.4 does
not 
> specify which of the three to choose.

I don't believe this is a problem. For DHCPv6, there is only the DUID
that can be used. So, there's no issue here.

For DHCPv4, all three forms could be used (once
draft-ietf-dhc-3315id-for-v4-05.txt is an RFC and implementations
support it).

However, the DHCPv4 server knows which format to use as it is using that
same information to associate the client with a lease.

In general, a DHCPv4 server would:
- Use the DUID format if the client and server both support
draft-ietf-dhc-3315id-for-v4-05.txt and the client presents a
client-identifier option formatted as a DUID. (Note that
draft-ietf-dhc-3315id-for-v4-05.txt documents some issues with migrating
to clients/servers that support
draft-ietf-dhc-3315id-for-v4-05.txt.)
- Use the Client Identifier option from the client if the client
included this option in its messages.
- Use the htype/chaddr otherwise.

This is already specified in RFC 2131 and
draft-ietf-dhc-3315id-for-v4-05.txt.

> The second problem with these drafts is the security claims 
> of section 2. I 
> don't believe that the issue is very serious - but the claim 
> of being able 
> to hide 40ish bits of information inside an 128-bit hash is harmful, 
> because it's wrong.

I don't believe we're trying to make strong security claims. I'm not
sure exactly what text is broken here?

We're attempting to make it a bit more difficult to track users by
querying for the DHCID RR. If we left the data un-hashed, it would be
extremely easy for someone to query the DNS to find the mac address (or
client identity). By hashing it, we're making it more difficult though
not impossible. For example, if the mac address is used, a brute force
attack that at worst has to generate 2^48 attempts is not out of the
question (and given the well known 24-bit OIDs, the number of attempts
required is likely far less). With the client identifier and DUID
(depending on the DUID type), it gets a bit more difficult but again is
not out of the question.

(If you could hash 1 million / second, and you had to do 2^40 attempts,
it would take 305 days. With special purpose hardware, efficient
algorithms, or by dividing the work up between multiple systems, this is
doable. Of course, it is far easier to learn the client identity if
you're on the same LAN segment as the client by monitoring the DHCP or
ARP traffic. But, that is only part of the battle as the most value is
in tracking the client as it moves. This requires querying the DNS and
collecting DHCID RRs and then hashing them against the client's identity
for a match. The largest cost here is in doing the DNS queries.)

There also isn't more data we can include in the hash that would be
known by all parties needing to do DNS updates but not known to external
sources. And, having to configure all of the DNS updaters with a magic
value would not scale (especially if the clients are the ones doing
updates).

So, I would take your option 2: "Abandon the idea that you can hide
information from a determined attacker using the hash" and I thought
that's exactly what we did? Section 2 says "This makes it difficult to
'track' a client as it is associated with various domain names." Also,
section 6 "Security Considerations" also says "make it difficult to
'track'".

> Nit: In section 3.1, an MD5 digest is described as having "n bytes".
Unless 
> you truncate it, I believe that "n" is always 16; leaving it as "n"
looks 
> untidy.

Agreed. We should specify 16 bytes.

- Bernie

> -----Original Message-----
> From: Harald Tveit Alvestrand [mailto:[email-masked]] 
> Sent: Monday, November 28, 2005 10:02 AM
> To: [email-masked]
> Cc: [email-masked]; Mark Stapp (mjs); 
> [email-masked]; [email-masked]; Bernie Volz (volz); 
> Ralph Droms (rdroms); [email-masked]; Sam Hartman
> Subject: Gen-ART review of draft-ietf-dhc-ddns-resolution and 
> draft-ietf-dnsext-dhcid-rr
> 
> Documents: draft-ietf-dhc-ddns-resolution-10.txt
>            draft-ietf-dnsext-dhcid-rr-10.txt
> Reviewer: Harald Alvestrand
> Date: Nov 28, 2005
> Summary: Not ready. Technical issues.
> 
> The DDNS resolution document seems to be technically 
> competent, and give a 
> reasonable procedure for detecting conflicts in the case of 
> multiple DDNS 
> clients trying to update the same record.
> 
> The algorithm is, however, dependent on the content of the 
> "disambiguating" 
> record being computed in the same way by all participants - and the 
> dnsext-dhcid document does not contain all information 
> required to achieve 
> this.
> 
> The problem is simple: The document gives three ways in which 
> a DHCID RR 
> can be created based on data from a client request. Section 
> 3.4 does not 
> specify which of the three to choose.
> 
> There are several ways to resolve this:
> 
> - Specify that the option furthest up the list for which 
> information is 
> available MUST be chosen, i.e use option 2 whenever a DUID is present
> - Specify that all servers involved in a domain MUST be 
> configured to pick 
> the identifiers in the same way (the "local configuration" cop-out)
> - Specify a procedure by which one can store/fetch data in 
> the DNS about 
> which algorithm is used to specify the DHCID
> 
> (The last two would also allow easy resolution of the "hash algorithm 
> rollover" issue presented on the IETF list - but this may be 
> unnecessary - 
> see below)
> 
> (There is also no specification that would be "future proof" 
> when new type 
> codes are added to the registry from section 7 - this may be resolved 
> either by specifying that new values require an update to 
> this standard 
> (and no registry is needed), by specifying a rule, or by 
> specifying that 
> new extensions must specify a rule. Future problem.)
> 
> The second problem with these drafts is the security claims 
> of section 2. I 
> don't believe that the issue is very serious - but the claim 
> of being able 
> to hide 40ish bits of information inside an 128-bit hash is harmful, 
> because it's wrong.
> In my opinion, there are only two choices:
> 
> - Abandon the idea that you can generate a DHCID and match it 
> against a 
> DHCID in the DNS without any external input
> - Abandon the idea that you can hide information from a 
> determined attacker 
> using the hash
> 
> If the first option is taken, section 6.3.2 of 
> ddns-resolution needs to 
> specify that the DHCID is fetched - the DHCID can then (for instance) 
> contain a large salt for the hash function; the DNS client 
> can then see if 
> it can successfully reconstruct the hash given the salt. 
> (This also allows 
> specifying the hash algorithm in the DHCID record's typecode).
> 
> If the second option is taken, all that is needed is a 
> declaration that 
> "the DUID of the client has very little value, so there isn't 
> any sense in 
> going to great lengths to protect it. Using a hash makes it a little 
> difficult, and makes the records fixed size, which is good".
> 
> Nit: In section 3.1, an MD5 digest is described as having "n 
> bytes". Unless 
> you truncate it, I believe that "n" is always 16; leaving it 
> as "n" looks 
> untidy.
> 
> 
> 
> 

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 28 Nov 2005 17:06:35 +0100

> draft-ietf-dhc-3315id-for-v4-05.txt.

If you include that little list in this document, I'm fine with it - RFC 
2131 and 3315id-for-v4 can't specify the DHCID, since that's defined here, 
so I don't know what you mean by "already specified"...

The following sentences need editing, in my opinion:

>    In order to avoid exposing potentially sensitive identifying
>    information, the data stored is the result of a one-way MD5 [5] hash
>    computation.

s/avoid exposing potentially sensitive/make it more difficult to get/

>    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.

This whole section is not what you say you were aiming for.
Rather say: "The hiding of information in the hash is already weak, and the 
weaknesses so far uncovered in MD5 do not make it any weaker".

>    The DHCID record as such does not introduce any new security problems
>    into the DNS.  In order to avoid exposing private information about
>    DHCP clients to public scrutiny, a one-way hash is used to obscure
>    all client information.

s/In order to avoid exposing private information/In order to make it 
somewhat more difficult to get at information/

And add some words about how difficult it is to recover the information 
(that you need to be a determined attacker in order to do so).
(if you know your victim's domain name, the DNS queries aren't at all 
expensive, since the DUID will always be stored under the same domain name 
in the DNS...)

                   Harald