Summary

  • RFC 2405 said a shorter key lifetime was not a cure for its known-plaintext attack model: ordinary IP datagrams could begin with predictable or guessable text.
  • DES-CBC supplied confidentiality, not authentication. Its explicit IV, key-search cost, integrity protection and Security Association management answered different questions.

A lifetime without a universal timer

In November 1998, RFC 2405 specified DES in CBC mode as an ESP confidentiality transform. It did not prescribe one time- or volume-based key lifetime. Instead, it left the decision to the value of the protected information and an operator’s estimate of an attacker’s resources. That is a risk judgment, not a guarantee that rotating keys on schedule makes an algorithm resistant to recovery.

The RFC explained why. It cited a then-current design for a one-million-dollar machine estimated to recover a DES key in 3.5 hours, and noted that an IP datagram commonly begins with known or guessable header text. Its conclusion was specifically that frequent rekeying would not protect against the known-plaintext attack it described. Those were the RFC’s 1998 claims, including a 1993 estimate—not a present-day price, benchmark or test result. The document also preserved a historical qualification: DES-CBC still offered more privacy than sending a datagram in cleartext.

Three protections, three different jobs

RFC 2405 required an eight-octet explicit IV for each ESP datagram and prohibited a counter or another low-Hamming-distance source. Carrying the IV beside the encrypted payload allowed a receiver to start decrypting a datagram even if another was lost or reordered. That packet boundary did not authenticate the ciphertext or make DES harder to search.

The RFC said the transform itself was not an authentication mechanism. It strongly discouraged using DES-CBC without corresponding authentication and described CBC cut-and-paste splicing. An authentication mechanism could address that integrity problem; a fresh key was not its substitute. Nor did a valid Security Association prove how much protection a particular implementation delivered: the RFC placed confidence on the cipher, implementation, association management, key strength and every participating node.

From required support to “MUST NOT”

The later ESP algorithm record changed its language in stages. RFC 4305 listed DES-CBC as SHOULD NOT where earlier requirements had required it. RFC 4835 retained SHOULD NOT; RFC 7321 changed the requirement to MUST NOT; RFC 8221 kept that status. This is a history of standards guidance. It does not identify the last device that supported DES or establish a universal migration date.

The distinction matters: changing a standard’s implementation requirement can reduce future compatibility pressure without erasing installed systems. A specification, a local configuration, a negotiated transform, authenticated packet processing and measured use are separate evidence. None can be inferred from a key-lifetime paragraph alone.

Sources