[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: Perfect forward (proactive) SECURITY a MUST
> Again: I don't see this as black and white... It's a tradeoff. But, we must
> decide, and therefore I also state my position: the price is reasonable.
> Let's require perfect forward (proactive) security.
I think I have already stated my position on this. Now it's for the
rest of the group to voice their opinion (if they haven't already
done so).
Now for a clarification. I didn't see a perfect forward secrecy
proposal in your MKMP document, other than one which was SKIP
based (in the appendix), i.e using SKIP to exchange ephemeral
DH values. (The master key update protocol in the body of the
MKMP document provides good as opposed to perfect forward
secrecy).
As I have already confirmed offline with Hugo, this is the same
proposal that I made at the San Jose IETF, (and which I also
mentioned verbally at the Toronto IETF). So, is this the proposal
that you are advocating for perfect forward secrecy? If so,
we are at least coming closer to an agreement.
The issue now is whether this is mandatory for situations which dont
require secrecy, or optional for situations which require
secrecy (which is what I support). (I should mention that
Whit Diffie, the person who originally presented this concept,
agrees with my position on this.)
> First of all, our protocol is lightweight, simple, provably secure and quick.
> Second, I did not say that we would not support other options. In fact I tend
> to feel that some implementations could support a well-defined feature that
> allows less secure but more efficient SKIP-like security. My only question is
> what is the requirement we should place on our base protocol. We need to
> agree in order to get more progress. In particular, I think well of your
> work, and I believe that if we reach consensus, you could contribute more
> by helping in the design of a base protocol with interaction with an optional
> non-interactive mode. Peace!
Peace on you and others as well! (After all, this is the season, isn't it?)
My view on this is that if something is going to be a default, it
should be the simple and lightweight thing. Take for example, UDP.
Having IP, UDP is a no-brainer. TCP on the other hand requires more
work. So, requiring UDP is not a major requirement.
Same for SKIP. It is simple, efficient and essentially a no-brainer.
Requiring this on every node does not constitute a major burden to
either implementors or the platforms on which it is to run. There
are no complicated state machines to deal with here, and the
computational burden is minimal.
(I dont consider your interactive proposal with the complex state
machine, the requirement for bypass traffic, and the problem
of dealing with half-open connections when one side crashes
as terribly simple, at least not in comparison with SKIP).
Also, as I mentioned in my IETF talk (and as your MKMP document also notes
in the appendix) it is possible to have perfect forward secrecy on top
of SKIP, without requiring a different crypto algorithm's (e.g RSA)
authenticated public keys. The authentic DH public keys may be obtained
either from secure DNS (per the Kaufman-Eastlake draft) or using
some certificate format distributed using a standard directory service.
I should point out that this would have the lowest computational
overhead of any perfect forward secrecy scheme, (including, I believe,
the Yacobi scheme) and furthermore does not suffer from the
(admittedly theoretical) triangle attack (Burmeister, Crypto '94).
If we can agree on these two modes, one session-less, simple and
efficient, and the other heavier-weight, more complex and session oriented,
then we will have essentially the equivalent of what already exists
in the Internet for transport protocols, namely UDP and TCP.
We can then argue over which one should be required and which
one should be optional. Can we at least agree on this?
Or do you have another perfect forward secrecy proposal that you
would like to support?
> > Do you believe that vendors that sell IPSP will turn on
> > strong encryption by default?
>
> How is this related? Strong authentication is fine! (I'll love to have
> strong encryption too and IBM is lobbying to get this)
This is related because perfect forward secrecy is only important
if you have secrecy!
Authentication-only with perfect-forward secrecy is an oxymoron.
> Ashar, you got it upside down. First, this feature is great for authentication,
> not just secrecy.
What are you talking about? Perfect forward secrecy is great
for authentication? How can forward secrecy make sense, when
there is no secrecy to begin with?
(I will address Hugo's concerns later, which are related to key
compromise and dont really fall in the category of perfect forward
secrecy, as the way the term is used in the literature, and by the
person who invented it).
> Agreed. However I don't think the overhead of a rarely-invoked protocol is so
> significant. Compare this to SKIP, where you essentially suggest that the
> public keys would be changed by some off-line operation.
I am afraid you lost me here. What are you referring to? I suggested
offline computation of ephemeral DH keys, wrt the perfect forward
secrecy-on-SKIP proposal. When did I refer to changing SKIP public
keys offline?
> I understand and respect your position. I'm happy to observe that we both
> want both modes, one to be the default and the other as option. We just have
> different preferences to which is default.
I also respect your work and position, and hope our disagreements will not
prevent continued joint work in helping define/discuss the requirements/details
of the key-management scheme that will ultimately be deployed.
Best regards, peace and goodwill,
Ashar.
Follow-Ups: