On Feb 13, 2012, at 3:21 PM, Ted Lemon wrote: > On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote: >> Do I infer correctly from your comment that the security properties of the >> mechanism don't really matter? That is, if the attacker we care about can't >> eavesdrop in the first place, does this really need to be an HMAC? > > Hm, I thought about that a bit more after I wrote my response. The HMAC > allows us to avoid sending the nonce in the clear in the DHCPFORCERENEW. I > don't think this adds any value from a security perspective, actually, even > though it feels more comfortable. I suspect it was put in in the original > version simply because of that—why send a secret over the wire when you don't > have to? However, the original motivation for using the mechanism from > RFC3315 was to avoid defining a new mechanism for a legacy protocol. If we > do need to change it, it's going to require a major rework of the document, > and a lot of delay, so if it causes no harm, I think that's not worth doing.
I concur it's probably not worth changing at this point--but it does inform the "is MD5 good enough" discussion, which might make it worth mentioning in the security considerations. > > I too would like to see the text I proposed added to the security > considerations, so that we can be clear about what is being accomplished with > this draft. >
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
