Much better - this contains the explanation of the security risks/threats involved. Thanks, --David
> -----Original Message----- > From: Pekka Nikander [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 21, 2006 3:22 AM > To: Black, David > Cc: [EMAIL PROTECTED]; [email protected]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Gen-art] Re: Gen-ART HIP drafts (base and esp) review > > David, > > Just as a reminder of the background, this is the existing text: > > The Diffie-Hellman value is ephemeral, and one value SHOULD be used > only for one connection. Once the Responder has received a valid > response to an R1 packet, that Diffie-Hellman value SHOULD be > deprecated. Because it is possible that the Responder has sent the > same Diffie-Hellman value to different hosts simultaneously in > corresponding R1 packets also those responses should be accepted. > However, as a defense against I1 storms, an implementation MAY use > the same Diffie-Hellman value for a period of time, for example, 15 > minutes. By using a small number of different puzzles for a given > Diffie-Hellman value, the R1 packets can be pre-computed and > delivered as quickly as I1 packets arrive. A scavenger process > should clean up unused DHs and puzzles. > > I think part of the confusion is in the "MAY use". If we replace that > with "MAY propose, and re-use if not avoidable,", that will probably > remove some of the contention. > > Then, I'd suggest the following text to be added: > > Re-using Diffie-Hellman public keys opens up the potential security > risks of more than one Initiators ending up with the same keying > material (due to faulty random number generators), and > more than one > Initiators using the same Responder public key half, > thereby leading > to potentially easier cryptographic attacks and the risk of not > having > perfect forward security. > > However, these risks involved in re-using the same key are > statistical; > that is, authors are not aware of any mechanism that would allow > manipulation of the protocol so that the risk of the > re-use of a any > given Responder Diffie-Hellman public key would differ > from the base > probability. Consequently, it is RECOMMENDED that implementations > avoid re-using the same D-H key with multiple Initiators, but > because the risk is considered statistical and not known to be > manipulatable, the implementations MAY re-use a key in > order to ease > resource constraint implementations and to increase the probability > of successful communication with legitimate clients even under an > I1 storm. In particular, when it is too expensive to > generate enough > of pre-computed R1 packets to supply each potential Initiator with > a different Diffie-Hellman key, the Responder MAY send the same > Diffie-Hellman key to several Initiators, thereby creating the > possibility of multiple legitimate Initiators ending up using the > same Responder-side public key. However, as soon as the Responder > knows that it will use a particular Diffie-Hellman key, it SHOULD > stop > offering it. This design is aimed to allow resource-constrained > Responders to offer services under I1 storms and to simultaneously > make the probability of Diffie-Hellman key re-use both > statistical and as low as possible. > > If a future version of this protocol is considered, we strongly > recommend that these issues shall be studied again. Especially, > the current design allows hosts to become potentially more > vulnerable > to a statistical, low-probability problem during I1 storm attacks > than > what they are if no attack is taking place; whether this is > acceptable or not should be reconsidered in the light of > any new experience gained. > > Ok? > > --Pekka > > > On 20 Dec 2006, at 22:18, [EMAIL PROTECTED] wrote: > > > Pekka, > > > > I think this is still essentially saying: > > - SHOULD NOT reuse D-H values because doing so is a security > > risk. (Aside: the risk isn't stated, but I think it's > > primarily replay, and it should be stated), *but* > > - MAY reuse D-H values when under attack. > > I'm still looking for a design justification for the "MAY". > > > > If the justification is that denial of service attacks are worse > > than replay attacks, then I'm concerned about the replay attacker > > who starts with a denial of service attack in order to open up > > the window for the replay attack to succeed, which would run > > counter to your "low-probability problem during attacks" > > assertion. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > >> David, > >> > >> We tried to address that with Petri's original by proposal: > >> > >>>> 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. > >> > >> Perhaps that should textually bound more strongly to the I1 > >> storm issue? > >> > >> --Pekka > >> > >> > >> On 20 Dec 2006, at 17:13, [EMAIL PROTECTED] wrote: > >> > >>> 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 > >> > >> > > > > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/gen-art > > _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
