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

From: Sam Hartman <[email-masked]>
Date: Sun, 27 Nov 2005 17:21:31 -0500

>>>>> "Steven" == Steven M Bellovin <[email-masked]> writes:

I'm currently writing a discuss on the md5 issue.

At a minimum you will need to specify the complexity in order to deal with changing hash algorithms.

    Steven> More generally...  The currently-known attacks on MD5 are
    Steven> collision attacks: it's possible to generate two inputs
    Steven> that produce the same hash value.  This scenario requires
    Steven> a preimage attack; none are known.  It would not surprise
    Steven> me if someone were to develop one, but until that happens
    Steven> we can't speculate on its properties.  There are, however,

Actually, no, it's worse than that.  A preimage attack is sufficient
to break this.  However you cannot reduce a break of this system to a
preimage attack.  

We actually know very little about how much information hash functions
leak.  We can prove an uppor bound on this given the assumption that
they are one-way.  If they leak too much information then they are not
one-way and we can find preimages.

However I don't think we can say much more than that.  

we can treat a hash function as a random oracle and under that
assumption it does not leak information.  The random oracle assumption
is much stronger than collision resistance.  Collision resistance can
certainly be reduced to random oracle.  So, saying that you can find
collisions actually is a very strong strike against the use of a
particular hash function as a random oracle.

I am not happy with a protocol whose security depends on treating md5
as a random oracle.

--Sam

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 21:50:00 -0700

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?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Nov 2005 22:00:18 -0700

> to break this.  However you cannot reduce a break of this system to a

It's always inspiring to meet someone who knows a lot about a complex topic 
like hash algorithms.

> I am not happy with a protocol whose security depends on treating md5

Again, very inspiring to meet someone who knows about md5, random oracles, et 
cetera.   However, this protocol's security does not rely in any way on md5 
or any other hash.   The hash is present as a privacy mask.   It has limited 
value since the thing being protected is broadcast over the wire on a regular 
basis, but we put it in because we were asked to.   The security of the 
protocol rests on the security of the DNS update mechanism; if you are 
concerned about DNS update security with your DHCP server, I suggest using 
some kind of cryptographic authentication.   I use TSIG, and am reasonably 
happy with it.

In order for the DHCID hash to be a security issue, it has to be the case that 
you have more than one DHCP server that is permitted to update the same zone 
in the DNS, and yet have no trust relationship between these DHCP servers.   
This is a contradiction in terms - if you don't have a trust relationship 
between two updaters of the same zone, you don't have any update security at 
all for that zone.

I would really encourage people who are commenting on this to please, please 
read the drafts for detailed comprehension, not just for keywords.   I get 
the impression that a lot of keyword triggering is going off here, and it's 
really not constructive.