Sam:
Maybe I should have stayed quiet a bit longer. I fully support
Steve's approach, and maybe that is what you wanted too.
Steve asked the authors to 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
This is better than us each making our own assessment of the hash
function security requirements.
Russ
Date: Tue, 29 Nov 2005 10:26:27 -0500
To: Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
From: Russ Housley <housley(_at_)vigilsec(_dot_)com>
Subject: Re: DHCID and the use of MD5
Cc: smb(_at_)cs(_dot_)columbia(_dot_)edu, ietf(_at_)ietf(_dot_)org
Sam:
I have been hoping to stay out of this discussion. I was hoping
that it would naturally come to closure, but I do not see it doing so.
As you know, I am really pushing for algorithm agility, and I fully
support your efforts to get it in this case.
Here is my understanding of the Random Oracle Model formulated by
Bellare and Rogaway. First, one designs an ideal system in which
all parties have oracle access to a truly random function, and then
one proves the security of this ideal system. Next, one replaces
the random oracle by a the hash function that is being studied (MD5
in this case), and all parties know the hash function that is being
used. Then one sees the impact (if any) of replacing the random
function with the hash function.
Why is this theoretical stuff important in this context? The hash
function security requirements in this application appear pretty
weak to me. It is certainly no where near the requirements imposed
in the digital signature context, which is where I am really worried
about a transition away from MD5 and SHA-1.
I am unclear what else you want the authors to do. Can you help me
understand you objective?
Russ
At 12:00 AM 11/29/2005, Ted Lemon wrote:
> I am not happy with a protocol whose security depends on treating md5
> as a random oracle.
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf