[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal: Perfect forward secrecy a MUST
Ran, Jim and others,
I agree with your position: speed should not stop us from requiring perfect
forward secrecy (in particular when used in conjunction with a short-lived
key refresh module, as we propose in MKMP, the overhead should be reasonable
even for low-end, mobile devices).
However I think we should be even more explicit about whether we want
perfect forward secrecy to be a must. Aziz has pointed out that this
feature does not come for free, and I think we are all saying that at least
the computational cost is not prohibitive.
Maybe, however, Aziz had other `costs' in mind, such as the requirement of an
interaction and `session' (i.e. keeping the key as a state).
Aziz (and others), could you enumerate all the disadvantages/costs associated
with deciding on perfect forward secrecy as a requirement?
Ran, Jim, Hugo, Phil, others: do you think we should require perfect forward
secrecy in spite of the costs in computation, interaction and state?
I vote to make perfect forward secrecy a requirement. I think it gives a
substantial boost in security at a cost which is reasonable in almost
every scenario. We could allow optional implementations which agree also
to work without it, if needed; this is the exception.
Best, Amir
Enc: note from Ran
>
> I agree with Jim Hughes (and others) that computational speed is not a
> major issue because processor capabilities keep improving rapidly.
>
> Ran
> atkinson@itd.nrl.navy.mil
> (speaking as an individual)
>
References: