datatracker.ietf.org
Sign in
Version 5.6.3.p2, 2014-09-29
Report a bug

Managing and removing automatic version rollback in TLS Clients
draft-pettersen-tls-version-rollback-removal-03

Document type: Expired Internet-Draft (individual)
Document stream: No stream defined
Last updated: 2014-08-16 (latest revision 2014-02-12)
Intended RFC status: Unknown
Other versions: (expired, archived): plain text, pdf, html

Stream State:No stream defined
Document shepherd: No shepherd assigned

IESG State: Expired
Responsible AD: (None)
Send notices to: No addresses provided

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found here:
http://www.ietf.org/archive/id/draft-pettersen-tls-version-rollback-removal-03.txt

Abstract

Ever since vendors started deploying TLS 1.0 clients, these clients have had to handle server implementations that do not tolerate the TLS version supported by the client, usually by automatically signaling an older supported version instead. Such version rollbacks represent a potential security hazard, if the older version should become vulnerable to attacks. The same history repeated when TLS Extensions were introduced, as some servers would not negotiate with clients that sent these protocol extensions, forcing clients to reduce protocol functionality in order to maintain interoperability. This document outlines a procedure to help clients decide when they may use version rollback to maintain interoperability with legacy servers, under what conditions the clients should not allow version rollbacks, such as when the server has indicated support for the TLS Renegotiation Information extension. The intention of this procedure is to limit the use of automatic version rollback to legacy servers and eventually eliminate its use.

Authors

Yngve Pettersen <yngve@spec-work.net>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)