Subject: Re: DHCID and the use of MD5

From: Russ Housley <[email-masked]>
Date: Tue, 29 Nov 2005 10:47:16 -0500

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 <[email-masked]>
>From: Russ Housley <[email-masked]>
>Subject: Re: DHCID and the use of MD5
>Cc: [email-masked], [email-masked]
>
>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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Nov 2005 11:44:50 -0500

>>>>> "Russ" == Russ Housley <[email-masked]> writes:

    Russ> Sam: Maybe I should have stayed quiet a bit longer.  I fully
    Russ> support Steve's approach, and maybe that is what you wanted
    Russ> too.

    Russ> Steve asked the authors to describe

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

    Russ> This is better than us each making our own assessment of the
    Russ> hash function security requirements.

I didn't see that request but I think it is a fine direction.

Honestly though the authors seem more upset about agility than about
md5.  I think we're certain we want agility.

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Nov 2005 12:26:20 -0500

>md5.  I think we're certain we want agility.

There are two kinds of algorithm agility:
    - build it into the protocol
    - update the protocol each time you want to use a new algorithm

Everyone always has the second. The author already made an argument 
against the first, but other seem to be supporting the other form.  I 
do not understand the impact on the current deployment.  Do you?

Given deployed code, either path forces the existing code to change.

Russ

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Nov 2005 12:51:22 -0500

Russ> At 11:44 AM 11/29/2005, Sam Hartman wrote:
    >> Honestly though the authors seem more upset about agility than
    >> about md5.  I think we're certain we want agility.

    Russ> There are two kinds of algorithm agility: - build it into
    Russ> the protocol - update the protocol each time you want to use
    Russ> a new algorithm

I disagree that you always have the second.  In particular you may not
have behavior that allows you to change the protocol.  For example the
SMIME verifier behavior of requiring all (instead of one) signature to
validate makes the change the protocol approach harder.

I think this is an example of a case where you don't have the second
kind of agility without changing the protocol.  In particular you need
clients and hcp servers to expect there to be more than one record
available.

    Russ> Everyone always has the second. The author already made an
    Russ> argument against the first, but other seem to be supporting
    Russ> the other form.  I do not understand the impact on the
    Russ> current deployment.  Do you?

so, the deployed code will have to change somewhat already.  They are
currently using txt records; they will need to transition to this new
RR.

However the update behavior if you add agility is more complicated.

---

From: Bill Fenner <[email-masked]>
Date: Tue, 29 Nov 2005 10:58:47 -0800

> However the update behavior if you add agility is more complicated.

I think this is the key to the objections, and deserves a lot of consideration.

Adding agility would presumably require either
a) Requiring that all consumers of DHCID records are configured to use
the same hash algorithm, or
b) Requiring that the DHCID record encodes the hash and possibly
permitting multiple hashes for the same data.

The problem with b) is that it changes the UPDATE process - right now,
or with a), the DHCP server sends an UPDATE to the DNS server saying
"If this name exists, and if the DHCID record matches this string,
then delete the existing records (and add the new record(s)"
(draft-ietf-dhc-ddns-resolution section 6.3.2).  This is an atomic
operation - the query, match and update.

If the DHCP server doing the UPDATE doesn't know what hash to use a
priori, it has to query the existing record to find out what hash to
use, changing this to a multi-step process with possible associated
race conditions (I think you can eliminate them, but you have to be
careful).  This is almost certainly what is getting the pushback.

  Bill

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 Nov 2005 17:08:00 -0500

Sam:

Perhaps I was being too terse.  I think we are in agreement about the 
most important parts.  I was trying to say that once you are forced 
to deploy new code, protocol changes and algorithm changes are both 
avaioable options.

Russ