]> Red Hat

Purkyňova 99/75a Brno 612 00 Czech Republic nmav@redhat.com

INRIA Paris-Rocquencourt

23, Avenue d'Italie Paris 75214 CEDEX 13 France alfredo.pironti@inria.fr

Security I-D Internet-Draft Length Hiding TLS Transport Layer Security This memo proposes a new padding mechanism the TLS and DTLS record protocols. It defines a TLS extension to allow arbitrary amount of padding in any ciphersuite. The new padding mechanism eliminates any known padding oracle attacks on the CBC ciphersuites and allows novel length hiding techniques.

When using CBC block ciphers, the TLS protocol provides means to frustrate attacks based on analysis of the length of exchanged messages, by adding extra padding to TLS records. However this extra padding has the following issues: No other than the CBC ciphersuites can take advantage of padding to hide the length of the records. It is limited to 255 bytes. The plaintext is padded after it is authenticated, allowing for padding oracle attacks . To overcome these limitations, the TLS extension proposed in this document enables a new padding mechanism for for both block and stream ciphers. The proposed extension eliminates padding oracles (both in errors and timing) that have been plaguing standard TLS block ciphers, without modifying critical aspects of the protocol such as the order of encryption and authentication.

This document uses the same notation and terminology used in the TLS and DTLS protocol specifications . The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

The TLS extended record padding is a variant of the TLS record protocol where every record can be padded up to 2^14 bytes, regardless of the cipher being used.

In order to indicate the support of the new record padding, clients MUST include an extension of type "extended_record_padding" to the extended client hello message. The "extended_record_padding" TLS extension is assigned the value of TDB-BY-IANA from the TLS ExtensionType registry. This value is used as the extension number for the extensions in both the client hello message and the server hello message. The hello extension mechanism is described in . This extension carries no payload and indicates support for the extended record padding. The "extension_data" field of this extension are of zero length in both the client and the server. The negotiated record padding applies for the duration of the session, including session resumption. A client wishing to resume a session where the extended record padding was negotiated SHOULD include the "extended_record_padding" extension in the client hello.

The translation of the TLSCompressed structure into TLSCiphertext remains the same as in . When the cipher is BulkCipherAlgorithm.null, the 'fragment' structure of TLSCiphertext also remains unchanged. That is, for the TLS_NULL_WITH_NULL_NULL ciphersuite and for MAC-only ciphersuites this extension has no effect. For all other ciphersuites, the 'fragment' structure of TLSCiphertext is modified as follows.

; opaque content[TLSCompressed.length]; opaque MAC[SecurityParameters.mac_length]; } GenericStreamCipher; struct { opaque IV[SecurityParameters.record_iv_length]; block-ciphered ciphered struct { opaque pad<0..2^14>; opaque content[TLSCompressed.length]; opaque MAC[CipherSpec.hash_size]; }; } GenericBlockCipher; struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct { opaque pad<0..2^14>; opaque content[TLSCompressed.length]; }; } GenericAEADCipher; ]]>

The padding can be filled with arbitrary data, and it is authenticated as part of the MAC. For block ciphers, the length of the pad MUST be such that the total length (i.e., the pad, the content and the MAC) are a multiple of the block size. Note: In typical applications that take no steps to hide the length of the record and are not using block ciphers, the size of the pad will be zero. For the various ciphers the data are authenticated as follows. Standard Stream Ciphers:

Block Ciphers:

AEAD Ciphers:

For all the above cases, a uint16 containing the sum of the padding length and the content length. Implementation note: With block and stream ciphers, in order to avoid padding oracles, decryption, MAC verification and payload decoding MUST be executed in the following order. Decrypt TLSCiphertext.fragment. Verify the MAC. Split plaintext from pad.

Since the padding is always included in the MAC computation, attacks that utilize the CBC-padding timing channel (e.g., ) are not applicable. In a way, the extended record padding can be seen as a special way of encoding application data before encryption (where application data given by the user are prefixed by some padding). Hence, previous security results on standard TLS block and stream ciphers still apply to the extended record padding.

This document defines a new TLS extension, "extended_record_padding", assigned a value of TBD-BY-IANA (the value 48015 is suggested) from the TLS ExtensionType registry defined in . This value is used as the extension number for the extensions in both the client hello message and the server hello message.

&TLS; &DTLS; &RFC2119;

The authors wish to thank Kenny Paterson for his suggestions on improving this document.