[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Proposal: Perfect forward (proactive) SECURITY a MUST


Ashar and all,

> >From ipsec-request@ans.net Tue Dec 13 14:30:39 1994
> >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.
>
> Actually, when I said it doesn't "come for free", I was quoting
> you in an earlier message.

Correct; of course it does not come for free!! This is the reason for us
to discuss and try to decide on the tradeoffs. In fact I've already mentioned
that perfect forward secrecy would cost us both some performance as well as
requiring a state. It appears to me the computational cost is not too bad,
and (as I explain below) that the state is not a sufficient barrier either.
I asked if you have additional arguments I did not consider, and of course
I'll like us to discuss the tradeoffs in order to reach agreement.

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.

> >Aziz (and others), could you enumerate all the disadvantages/costs associated
> >with deciding on perfect forward secrecy as a requirement?
>
> Sure, I would be happy to.
>
> Think about time critical network management operations that
> have authentication of management entities as a prime concern.
>
> Burdening this application with a high overhead session
> oriented key-management for the sake of perfect forward
> secrecy, (when secrecy itself is not an issue)

I believe people care not just about `perfect forward secrecy' but more
generally about `forward SECURITY', which we call `proactive security'.
Namely, the security of the system (inc. authentication) should recover
from break-ins which reveal the secret keys of the parties. This would be
assured by, e.g., running DH periodically.

At least, I believe requiring such `proactive security' or `forward security'
is reasonable for us, since so far I don't see the prohibitively large costs.
I think this is proper design since strong security which does not cost much
would allow the protocol to be used for more scenario and for longer time.

> The whole reason for running SNMP primarily
> on top of UDP was to keep it lightweight and quick. Now you
> want to add an elaborate high overhead protocol underneath
> it as a *mandatory* feature, which has no justification
> in this context.

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!

>
> Think about ICMP messages. Do you want to have a session/exponentiations
> for each and every one of them, for the sake of perfect forward
> secrecy, when secrecy itself may not be a concern?

Again the issue is not merely secrecy but also authentication. Furthermore,
I think that for many applications such as ICMP, even SKIP may require
communication before getting Kij as I've explained in another message.
Essentially, if the two parties know each other a-priori and cache Kij, they
could just as well keep a long-lived key derived by a protocol... If they don't
then they still have to go to some directory to get public keys (even in SKIP).

> 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)

> You stated at the IETF meeting
> that you (IBM) want to build exportable products (with
> weak or no encryption).

I certainly did not say `no encryption'. Also, we don't `want' to, but we
are forced to by law. We try to change the law and we try to provide the
maximal legal security.

> Now you are pushing a feature as
> mandatory that makes sense only when used with strong
> encryption (something that you yourselves dont intend to
> make the default).

Ashar, you got it upside down. First, this feature is great for authentication,
not just secrecy. Second, for secrecy, this feature is very useful in
conjunction with WEAK, EXPORTABLE ENCRYPTION!! Namely, even if the bad guys
can break some keys, they cannot break the other keys without working again,
and does not collect info on any master keys. The last point may not be too
critical if one uses very good security for the master keys (as is exportable),
but the fact remains that the proactive security is very valueable with weak
encryption as the security is recovering from break-ins!
>
> Working for a computer company, I understand that computers are
> getting faster every year. We love to sell our latest and fastest
> computers, but we also realize that we can't expect our customers
> to throw out all the equipment that they have already purchased
> and spent billions of dollars on, as soon as the new models arrive.

Agreed.
>
> The installed base of computers does not vanish easily, and we
> should be careful about mandating features that are *not* necessary
> in many circumstances, and which pose an unreasonable protocol
> and computational burden to the millions of computers installed
> in the field *today*.

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.
>
> Therefore I cast a strong *no* vote to making this feature
> mandatory. (I have already stated that I support this as
> an optional feature for situations where secrecy is essential).

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. Maybe further discussions would
allow us to agree, if not, then I think the group should try to decide
in order to proceed. Clearly, even picking the wrong one as default should
not be as bad as continued disagreement (if this is really the wrong choice
then people will just use the option).

Best, Amir
References: