TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch and prevent strain on some systems.
IVs attempt to prevent any (key, message) pair from producing the same ciphertext on retransmission. They generally need to be unique, preferably random, but shouldn't need to be secret. (A shared secret IV is really just more key.)
There are many ways to try to use an IV. Let's start with ECB (no IV), then examine TLS 1.0 first, then examine how TLS 1.1/1.2 uses its new IV.
If you just broke up a plaintext into chunks and encrypted each chunk, you're going to risk retransmission of the same block if the plaintext repeats. So the way CBC improves on ECB is to XOR the previous block's ciphertext into the current block's plaintext before encryption. That's sufficient to lower the likelihood of retransmission on every block but the first, which aren't XOR'd with anything yet. So you toss in an explicit IV to the first round to get CBC.
II. TLS 1.0 with CBC
In TLS 1.0, each party might like to be able to ensure this first IV is random. So each party proposes an IV. The two IVs are then mixed together through a pseudo-random function.
Initialization Vector (IV)
When a block cipher is used in CBC mode, the initialization
vector is exclusive-ORed with the first plaintext block prior to
The sender then takes the IV and XORs it with the first block of plaintext. This will propagate through the block chain, it should be sufficient to ensure no repeated ciphertext blocks (at least not corresponding to repeated plaintext blocks).
While an IV proper shouldn't need to be secret, BEAST showed it isn't wise to let your attacker anticipate your next IV and also be able to shape your next chunk of plaintext.
So in the BEAST attack, the attacker gets the IV for the next message, and then tricks the sender into sending some message of the form (not IV xor CPT).
Once the IV (aka 'mask') is XOR'd in before encryption, it cancels (NOT IV). CPT is now some chosen plaintext that will be encrypted (sans any mask). That's bad.
In version 1.1 of TLS, the big change was providing a fresh IV at the start of each record (every 16k bytes).
The TLS 1.0 "IV" for each block is just called a mask in 1.1. The TLS 1.0 IV for the first block can even be optionally kept. So the new IV doesn't actually replace (either of) the old IVs directly, they serve slightly different purposes and are implemented in slightly different ways.
Per RFC 4346, one of the following two algorithms SHOULD be used to generate the per-record IV:
Generate a cryptographically strong random string R for the IV. Mask the data with R. The first cipher block will be encrypted as:
E(R XOR Data).
Generate a cryptographically strong random R and prepend to the plaintext prior to encryption. In this case the mask can be fixed, or
the CBC residue from the previous record may be used as the mask.
Using the residue preserves maximum code compatibility with TLS 1.0
and SSL 3. It also has the advantage that it does not require the
ability to quickly reset the IV, which is known to be a problem on
The decryption operation for all alternatives is the same: The
receiver decrypts the entire structure but discards the first cipher
block, corresponding to the IV component.
The priorities were to preserve as much of the existing spec as possible, making implementation easier.
In TLS 1.1 and 1.2, they're encrypting the IV in the first block, which will be discarded by the sender. The TLS 1.0 IV is now called a "mask." By keeping the old IV as a mask, but introducing a new IV that makes a disposable block, they leave the algorithm changed as little as possible.
The parties no longer cooperate on this new, more frequently generated IV, meaning fewer code changes, and less strain on some systems.