Technical Summary
SSL and TLS renegotiation are vulnerable to an attack in which the
attacker forms a TLS connection with the target server, injects
content of his choice, and then splices in a new TLS connection
from a client. The server treats the client's initial TLS
handshake as a renegotiation and thus believes that the initial
data transmitted by the attacker is from the same entity as the
subsequent client data. This draft defines a TLS extension to
cryptographically tie renegotiations to the TLS connections they
are being performed over, thus preventing this attack.
Working Group Summary
This document addresses an urgent security vulnerability, so it was
decided to solicit comments from TLS WG members and the wider
community partly overlapping. This meant there were quite a few
emails during the IETF Last Call.
There are two details where the consensus was a bit rougher than
normally:
1) Whether to send the old channel bindings data over-the-wire
(inside the extension data), or just include it in computations
without actually sending it. Sending the data over-the-wire seems
to have more support (at least 2/3 vs. 1/3), and most participants
(of either opinion) seem to prefer making a decision over
continuing the discussion until some indeterminate time.
2) Whether all clients have to always include the "magic cipher
suite value".
Originally, the magic cipher suite was included to avoid breaking
things with old "extension-intolerant" servers (buggy servers that
fail the connection if the client sends any TLS extensions), and to
support the SSLv2-compatible ClientHello format.
Some people have proposed that the magic cipher suite must be
always included (this would simplify some server implementations a
bit); some others think that using just the extension is better for
clients that always send extensions anyway (and don't care about
buggy extension-intolerant servers). Both approaches work; there
are small differences in coding/testing effort (depending on what
the implementation already supports).
The latter approach (don't require clients to implement the magic
cipher suite if they don't need it) seems to have more support (at
least 2/3 vs. 1/3). One participant has disagreed with this
rough consensus judgment (on the basis that the arguments by the
1/3 have been more technical, and should carry more weight), and
has proposed continuing discussion about this topic. The IESG
believes most participants consider the differences between these
approaches very minor, and prefer making a decision now over
continuing the discussion.
Document Quality
A number of prototype implementations based on earlier versions
of the draft exist; and it is expected the final draft will
be implemented by most TLS stacks.
Personnel
The document shepherd is Joseph Salowey, and the responsible
area director is Pasi Eronen.
RFC Editor Note
Please fix the 2nd bullet in Section 3.2 as follows:
OLD:
"client_verify_data" specified in Section 3.2.
NEW:
"client_verify_data" specified in Section 3.1.