Pekka and Petri, In the proposed changes, I don't see a response to this concern:
> >> The current text says > >> that DH values SHOULD not be reused unless the system is under attack > >> (I1 storms), in which case they MAY be reused. This appears to drop > >> the level of security in response to an attack, which may not be the > >> best course of action. Thanks, --David > -----Original Message----- > From: Pekka Nikander [mailto:[EMAIL PROTECTED] > Sent: Wednesday, December 20, 2006 7:56 AM > To: Petri Jokela > Cc: Black, David; [email protected]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: Gen-ART HIP drafts (base and esp) review > > Petri, > > >> The text in Section 5.3.2 on Diffie-Hellman value reuse could use > >> some clarification. The underlying issue is that the HIP exchange > >> does not use the nonces that IKE and IKEv2 use, which makes DH > >> value reuse significantly more dangerous. The current text says > >> that DH values SHOULD not be reused unless the system is > under attack > >> (I1 storms), in which case they MAY be reused. This > appears to drop > >> the level of security in response to an attack, which may > not be the > >> best course of action. I don't want to say that HIP ought to use > >> IKE-like nonces, but this text appears to need some more thought. > >> Section 5.3.3 doesn't discuss DH value reuse. It should. > > > > We discussed this and decided to add a note about the issue and a > > strong recommendation that in the future versions of HIP this is > > revisited: > > > > Re-using D-H value can open security holes. When future > > versions of HIP are specified, it is strongly recommended > > that these possible security issues are investigated. > > I'd rather say > > "Re-using public Diffie-Hellman keys has known security > issues. If a > future version of this protocol is considered, we strongly recommend > that these issues are re-considered with due diligence. Especially, > the current design allows hosts to become potentially more > vulnerable > to a low-probability problem during attacks than what they are if no > attack is taking place may; whether this is acceptable or not should > be reconsidered in the light of experimentation experiences." > > or something like that. > > What you now write gives the feeling that we say "this is > broken. go > fix it next time." while we want to say "what we now do has known > limitations. next time, consider if it is worth fixing, based on > your experience." > > --Pekka > > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
