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

Proposed message on perfect forward security

These mailing lists have witnessed a significant amount of commentary on the
usefulness of certain key management protocols. One argument that has arisen
several times is that some proposed protocols do not provide "perfect
forward security." This property is the inabilitiy of an intruder who has
recorded past traffic between a sender and receiver to decrypt that traffic
if and when the long-term keying material of one or both correspondents is

While perfect forward security is a useful property and even may be required
for some applications, it is not always necessary and can introduce certain
inefficiencies that adversely affect application performance. For example,
perfect forward security may be necessary in an application that deals with
information of long-time value, such as certain intelligence traffic, privileged
client/attorney communications, and even commuications that may provide
embarassment well after they have taken place (e.g., the now widely publicized
telephone conversation between the Prince of Wales and his girlfriend).

On the other hand, many other applications have no strong requirement for
perfect forward security. Examples of these fall generally into that class
of communications that are in some sense "tactical." For example,
communications between a commander an his forward units probably have no
need for perfect forward security. The directions he gives will become
apparent to the enemy well before they can use any captured keys they
might obtain to decrypt these. Other examples are communications to meet
someone at a public place, blind auction bids in which all bids are later
revealed in order to assure the participants of fairness, and large stock
exchange purchases/sales by corporate officers of their own company's stock,
for which the law requires public disclosure.

Consequently, to require all key management protocols to provide perfect
forward security simply because it is a useful property in some circumstances
is unreasonable. The argument supporting this view is similar one that might
be made about wearing SCUBA gear. If you intend to dive deeply in the ocean
outside of a vessel, then wearing SCUBA gear is a necessity. Since it 
is such a strong requirement in this situation, we should always wear SCUBA
gear, i.e., when we go shopping, are driving our cars or are playing tennis.

For this reason I believe arguing against a key management protocol because
it fails to provide perfect forward security would only be appropriate if
that were the only protocol being proposed. In the case of IPv6, this is
not true and so, I believe the argument is specious.

Given the limited amount of experience we have in internet-wide deployed
key management protocols, I don't believe this is the time to preclude
key management options, especially based on questionable arguments. It is
precisely for this reason that we should not exclude various key management
protocols so that we may gain experience in this imperfectly understood area.
In regards to in-band keying, two companies, Sun and DEC have devised key
management protocols that use it, which provides a prima facie case for
allowing its optional use in IPv4 and IPv6.