Subject: RE: Re: DHCID and the use of MD5 [Re: Last Call: 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed Standard]

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sun, 27 Nov 2005 21:23:52 -0500

This would, as Ted indicates, greatly complicate the entire update
sequence. The current update sequence (see
draft-ietf-dhc-ddns-resolution-10.txt), never does a query of the RRs in
the server. Therefore, either we'd have to do a query first to obtain
the DHCID RR and extract the algorithm so we can do the comparison, or
we'd have to try each of the algorithms in a DNS update operation.
Neither of these is particularily pleasant (especially considering that
things can change between DNS operations).

And, if not all implementations support all algorithms, you'd have real
interop problems.

And, what's the benefit? It isn't like this information is hyper
sensitive (come on, IPv6 uses the mac address in the link identifier --
yes, I know about RFC 3041).

While MD5 could be compromised, you can't necessarily get back the mac
address that was used to generate the value.

Yet, we also have to remember that we're dealing with a 48-bit *INPUT*
in many cases for the DHCID -- the mac address. A brute force attack is
not out of the question if you really wanted to get the data (and given
the well known 24-bit OID values, you could probably cut down the bruce
force attack to make it very reasonable whatever scheme we used). If a
client identifier or DUID is used, this does likely mean more bits but
most client identifiers and DUIDs are based on mac addresses.

So, let's be realistic here and not unnecessarily complicate matters for
no real benefit.

If there is a strong argument to improve the security of this
information, we can debate whether SHA1 or SHA-256 be used for the
start. But, I for one don't see the need.

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Pekka Savola
> Sent: Saturday, November 26, 2005 2:10 PM
> To: Ted Lemon
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call: 
> 'Resolution of FQDN Conflicts among DHCP Clients' to Proposed 
> Standard]
> 
> On Sat, 26 Nov 2005, Ted Lemon wrote:
> > 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.
> 
> AFAICS, it shouldn't be all that complicated as long as the 
> implementations [checking for conflicts] support all the algorithms 
> used at the site, right?
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 11:59:20 -0600

On Monday 28 November 2005 10:49, Steven M. Bellovin wrote:
> I confess that I don't see the problem.

The problem is that in order to do what Pekka is proposing, we have to make a 
substantial change to the protocol.   This creates two problems: first, it 
means that this protocol, which is in wide use, has been in wide use for more 
than five years, the standard for which has been under development for ten 
years, will probably take another year to make standard, for this change 
alone.   As it has many times before.   This is a major language tweak, and 
will require substantial review.   Second, it renders implementations 
substantially more complicated, and creates a knob that administrators need 
to understand whether and how to turn, where no knob is needed.   Additional 
knobs that aren't needed have a net negative impact on overall system 
security - the overall impact of the proposed change will be to reduce, not 
enhance security.

I support the changes suggested by Havard that simply reduce the security 
claims being made here.   I do not support making any substantive changes to 
the protocol at this point - to do so will simply delay it longer, and will 
not add any value.   The only reason I can think of for not using MD5 is that 
at some point people might want to be able to avoid having an MD5 
implementation on their device because MD5 is generally deprecated.   I don't 
think this is a practical concern - MD5 implementations are with us for the 
long haul, deprecated or not.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 29 Nov 2005 00:02:02 -0500

In message <[email-masked]>, Ted Lemon writes:
>On Saturday 26 November 2005 09:56, Steven M. Bellovin wrote:
>> In fact, the Security Considerations section should analyze the
>> (non-trivial) probability of a brute-force attack.
>
>It doesn't matter.   The point of the DHCID is to allow two servers to avoid 
>accidentally stepping on each other.   If you break the DHCID, what you get 
>is the ability to pretend that you are another DHCP client.   If you succeed 
>in doing this, you can take over that DHCP client's name, but you don't get 
>to keep it, because you are using the same identification as the other 
>client, and so it's going to take it back.   The information that you would 
>use to pretend to be the other client is routinely being sent over the 
>network in the clear, so you don't need to break the DHCID to get it - you 
>just need to listen on the wire for a packet from that client.   You can't do 
>the attack I've described unless you are on a network managed by a DHCP 
>server that manages the same namespace as the server that put in the 
>legitimate DHCID.
>
>It's true that we could exhaustively go over all possible exploits, no matter 
>how trivial, no matter how useless, in the security considerations section.   
>Do you honestly believe that this is necessary?
>
It's the privacy aspect I'm concerned about.  The protocol has a 
mechanism -- the hash -- intended to protect privacy.  There are 
limitations to how well it works.  These may be unavoidable; that said, 
they should be documented.  See Section 5 of RFC 3552, a BCP:

   Authors MUST describe

      1.   which attacks are out of scope (and why!)
      2.   which attacks are in-scope
      2.1  and the protocol is susceptible to
      2.2  and the protocol protects against

   ...

   There should be a clear description of the residual risk to the user
   or operator of that protocol after threat mitigation has been
   deployed.

Put another way, against a certain grade of attacker the mechanism 
doesn't do its job.  That needs to be documented, so that people who 
are concerned about the issue know to avoid this option.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb