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

 
Document
Type Expired Internet-Draft (individual)
Last updated 2014-08-16 (latest revision 2014-02-12)
Stream (None)
Intended RFC status (None)
Formats
Expired & archived
plain text pdf html
Stream
Stream state (No stream defined)
Document shepherd No shepherd assigned
IESG
IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

Email authors IPR References Referenced by Nits Search lists

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
//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.)