[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal: Perfect forward secrecy a MUST
Ashar Aziz says:
> 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) is very poor
> system design.
In real network management systems, each managed entity typically
communicates with a small number (usually one) of management
stations. At the beginning (and maybe every day) they will end up
spending a second or so setting up SAIDs, and maybe again every day or
two, but thats probably the end of it. You picked a particularly bad
example.
> 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?
ICMP messages are a much better example -- in a big network where you
will typically not have much occasion to the host telling you
"destination unreachable" or what have you. However, I'll note that
you still have to spend some time looking up the key for the
destination host no matter what you do if you are going to
authenticate, so the situation isn't perfect regardless.
Also, its not a question of secrecy at all in this case, because I
suspect that people will use authentication only in this case and not
encryption.
However...
> 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 agree that we shouldn't make perfect forward key secrecy or perfect
forward a requirement for all your work. However, I think that the
ability to use perfect forward secrecy based systems if you wish is a
requirement, because you will have instances where you will need it.
I'd also say that any scheme that unfairly penalizes the use of
perfect forward secrecy is also a problem. If you use perfect forward
secrecy you shouldn't have to pay any more than the cost of the D-H
algorithm. In particular, perfect forward secrecy shouldn't be some
sort of hack hung on the side of the algorithm but should be as easy
to use as any other supported mode.
Key management systems that are too closely linked with a particular
cryptographic algorithm are likely a problem given that technology
advances with time. Certainly we must require a base algorithm for
interoperability (specifying too many options is a recipe for disaster
as the ISO crowd has shown) but that doesn't mean we should handcuff
ourselves to Diffie-Hellman, when other better things might come along.
Perry
References: