ietf-corpus

rfc-3268

Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)

P. Chown
date2002-07 streamIETF areasec wgtls statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc3268 doi10.17487/RFC3268
This document proposes several new ciphersuites. At present, the symmetric ciphers supported by Transport Layer Security (TLS) are RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES), and triple DES. The protocol would be enhanced by the addition of Advanced Encryption Standard (AES) ciphersuites. [STANDARDS-TRACK]

obsoleted by

Extracted elements (11)

design-rationale §Overview

AES ciphersuites are added to TLS because RC2, RC4, and IDEA are subject to intellectual property claims (trademarks, trade secrets, or patents), triple DES is inefficient, and the DHE forward-secrecy ciphersuites previously only supported triple DES and weak export variants.

tls, crypto, security

design-rationale §Cipher Usage

All new ciphersuites use AES in CBC mode with SHA-1 in an HMAC construction as described in TLS section 5. The ciphersuite naming convention inherits the 'SHA' label from TLS, which actually refers to the modified SHA-1.

tls, crypto

design-rationale §Cipher Usage

Only 128-bit and 256-bit AES key lengths are defined, deliberately omitting 192-bit, to avoid unnecessary proliferation of ciphersuites. All ciphersuites use 128-bit AES block size as mandated by the AES process.

tls, crypto

interoperability-note §Security Considerations

Unlike the base TLS specification [RFC 2246], which deprecated anonymous Diffie-Hellman (ADH) ciphersuites, the ADH ciphersuites defined in this document are explicitly not deprecated.

tls, security

protocol-element §Cipher Usage

Twelve new ciphersuites are defined using AES in CBC mode with SHA-1 HMAC, covering RSA, DH_DSS, DH_RSA, DHE_DSS, DHE_RSA, and DH_anon key exchange methods, each in 128-bit and 256-bit key variants.

tls, crypto

registry §Cipher Usage

Twelve new TLS ciphersuite identifiers are assigned: TLS_RSA_WITH_AES_128_CBC_SHA (0x00,0x2F), TLS_DH_DSS_WITH_AES_128_CBC_SHA (0x00,0x30), TLS_DH_RSA_WITH_AES_128_CBC_SHA (0x00,0x31), TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x00,0x32), TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x00,0x33), TLS_DH_anon_WITH_AES_128_CBC_SHA (0x00,0x34), and their AES-256 counterparts (0x00,0x35–0x00,0x3A).

tls, registry, crypto

security-consideration §Security Considerations

A chosen-plaintext attack applies to all TLS CBC-mode ciphersuites defined in RFC 2246, allowing attackers to verify hypotheses about earlier plaintext without compromising key material. This does not affect typical HTTPS use but may affect other TLS applications; the CBC construction was expected to change in a future TLS revision.

tls, crypto, security

security-consideration §Security Considerations

ADH ciphersuites provide confidentiality but not authentication, making them vulnerable to man-in-the-middle attacks. Parties using ADH must authenticate by other means and must have a way to verify they share the same TLS connection (e.g., by computing a MAC over the TLS Finished message).

tls, security

security-consideration §Security Considerations

Ephemeral Diffie-Hellman ciphersuites provide forward secrecy. To maximize their benefit: ephemeral keys should be used only once (no significant efficiency gain from reuse in TLS), destroyed securely when no longer needed, and generated by an RNG that does not reveal past output even when its internal state is compromised.

tls, crypto, security

security-consideration §Security Considerations

The AES ciphersuites are not believed to be less secure than the corresponding older ciphersuites. AES is considered secure and has withstood extensive cryptanalytic attack.

tls, crypto, security

wire-format §Cipher Usage

AES-128 ciphersuites are assigned codes 0x00,0x2F (RSA) through 0x00,0x34 (DH_anon); AES-256 ciphersuites are assigned 0x00,0x35 (RSA) through 0x00,0x3A (DH_anon). All use 2-byte ciphersuite identifiers.

tls, crypto