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
