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
