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 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. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
