Skip to main content

Transport Layer Security (TLS) Renegotiation Indication Extension
draft-ietf-tls-renegotiation-03

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    tls mailing list <tls@ietf.org>, 
    tls chair <tls-chairs@tools.ietf.org>
Subject: Protocol Action: 'Transport Layer Security (TLS) Renegotiation Indication Extension' to Proposed Standard

The IESG has approved the following document:

- 'Transport Layer Security (TLS) Renegotiation Indication Extension '
   <draft-ietf-tls-renegotiation-03.txt> as a Proposed Standard


This document is the product of the Transport Layer Security Working Group. 

The IESG contact persons are Pasi Eronen and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-renegotiation-03.txt

Ballot Text

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.

RFC Editor Note