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

From: Mark Stapp <[email-masked]>
Date: Tue, 29 Nov 2005 09:22:41 -0500

I don't object to Steve's proposal to clarify the goal and limitations 
of the use of md5 in the security considerations section. what we're 
trying to achieve in the DHCID rrs is certainly no stronger than the 
'privacy' offered by stateless v6 addresses or rfc3041 addresses. we 
aren't really making a 'privacy' claim; there's plenty of other 
un-obscured information available in the DNS along with the DHCIDs. 
we're only trying to make it difficult to track a DHCP client as it 
moves from address to address. md5 makes it more difficult than the 
plain-text version of an ethernet MAC address; that's "enough" for our 
purpose.

would such a clarification be "enough" to resolve your DISCUSS, Sam 
Hartman? that is, if it were clearer that we're only aiming for more 
difficult than not difficult at all - would that be sufficiently clear 
guidance to admins about what they should expect from this mechanism?

-- Mark

Steven M. Bellovin wrote:

>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
>
>
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg
>
>  
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Nov 2005 14:47:49 -0500

>>>>> "Mark" == Mark Stapp <[email-masked]> writes:

    Mark> would such a clarification be "enough" to resolve your
    Mark> DISCUSS, Sam Hartman? that is, if it were clearer that we're
    Mark> only aiming for more difficult than not difficult at all -
    Mark> would that be sufficiently clear guidance to admins about
    Mark> what they should expect from this mechanism?

So, as I described in my response to  Russ, I'm asking for three things:

1) algorithm agility

2) Remove the paragraph explaining why md5 is OK or provide a
   theoretical model under which we can reason about how good a hash
   is at keeping stuff private.

3) Use sha-1 or sha-256 instead of md5.

I feel very strongly about point 1.  Unfortunately I think this is the
point the working group most objects to.  I understand the concerns
about the complexity of the update process.  However I also know that
security primitives are things that you need to replace from time to
time.  If you were using md5 because it had a relatively even
distribution of outputs you could probably convince me that you don't
need a way to update it.  However even if weakly you're using md5 for
its cryptographic properties.  Those can change over time so you need
a mechanism to react to those changes.

I suspect we can all agree that we need to either reword claims about
security of cryptographic primitives so they are clearly true or
remove those claims.  So I don't think that we're going to have much
of an issue with point 2.

I think there is room for discussion on point 3.  I think sha-1 or
sha-256 would be a better choice.  I think that there is an argument
that md5 is not so bad that it cannot be used.  If the working group
ends up responding that it would really like to use md5, I can go to
the security community and see what people think there.

--Sam

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