< draft-mavrogiannopoulos-new-tls-padding-00.txt   draft-mavrogiannopoulos-new-tls-padding-01.txt >
Network Working Group N. Mavrogiannopoulos Network Working Group N. Mavrogiannopoulos
Internet-Draft Red Hat Internet-Draft Red Hat
Updates: 5246,6347 A. Pironti Updates: 5246,6347 (if approved) A. Pironti
(if approved) INRIA Paris-Rocquencourt Intended status: Standards Track INRIA Paris-Rocquencourt
Intended status: Standards Track November 12, 2013 Expires: May 21, 2014 November 17, 2013
Expires: May 16, 2014
A new TLS record padding mechanism A new TLS record padding mechanism
draft-mavrogiannopoulos-new-tls-padding-00 draft-mavrogiannopoulos-new-tls-padding-01
Abstract Abstract
This memo proposes a new padding mechanism the TLS and DTLS record This memo proposes a new padding mechanism the TLS and DTLS record
protocols. It defines a TLS extension to allow arbitrary amount of protocols. It defines a TLS extension to allow arbitrary amount of
padding in any ciphersuite. The new padding mechanism eliminates any padding in any ciphersuite. The new padding mechanism eliminates any
known padding oracle attacks on the CBC ciphersuites and allows novel known padding oracle attacks on the CBC ciphersuites and allows novel
length hiding techniques. length hiding techniques.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2014. This Internet-Draft will expire on May 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. TLS Extension: Extended Record Padding . . . . . . . . . . . . 5 3. TLS Extension: Extended Record Padding . . . . . . . . . . . 3
3.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 5 3.1. Extension Negotiation . . . . . . . . . . . . . . . . . . 3
3.2. Record Payload . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Record Payload . . . . . . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 6. Normative References . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
When using CBC block ciphers, the TLS protocol [RFC5246][RFC6347] The ciphersuites of the TLS protocol that utilize CBC block ciphers,
provides means to frustrate attacks based on analysis of the length [RFC5246][RFC6347] require the plaintext to be padded to a multiple
of exchanged messages, by adding extra padding to TLS records. of the cipher's block size prior to encryption. However, this
However this extra padding has the following issues: padding, as implemented in TLS, has the following issues.
1. No other than the CBC ciphersuites can take advantage of padding 1. The plaintext is padded after it is authenticated, allowing for
to hide the length of the records. padding oracle attacks [CBCTIME][DTLS-ATTACK][LH-PADDING].
2. It is limited to 255 bytes. 2. It is limited to 255 bytes.
3. The plaintext is padded after it is authenticated, allowing for 3. No other than the CBC ciphersuites can take advantage of padding
padding oracle attacks [CBCTIME][DTLS-ATTACK]. to hide the length of the records.
To overcome these limitations, the TLS extension proposed in this To overcome these limitations, the TLS extension proposed in this
document enables a new padding mechanism for for both block and document enables a new padding mechanism for for both block and
stream ciphers. The proposed extension eliminates padding oracles stream ciphers. The proposed extension eliminates padding oracles
(both in errors and timing) that have been plaguing standard TLS (both in errors and timing) that have been plaguing standard TLS
block ciphers, without modifying critical aspects of the protocol block ciphers, without modifying critical aspects of the protocol
such as the order of encryption and authentication. such as the order of encryption and authentication.
2. Terminology 2. Terminology
This document uses the same notation and terminology used in the TLS This document uses the same notation and terminology used in the TLS
and DTLS protocol specifications [RFC5246][RFC6347]. and DTLS protocol specifications [RFC5246][RFC6347].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. TLS Extension: Extended Record Padding 3. TLS Extension: Extended Record Padding
The TLS extended record padding is a variant of the TLS record The TLS extended record padding is a variant of the TLS record
skipping to change at page 6, line 41 skipping to change at page 4, line 34
content and the MAC) are a multiple of the block size. content and the MAC) are a multiple of the block size.
Note: In typical applications that take no steps to hide the length 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 of the record and are not using block ciphers, the size of the pad
will be zero. will be zero.
For the various ciphers the data are authenticated as follows. For the various ciphers the data are authenticated as follows.
Standard Stream Ciphers: Standard Stream Ciphers:
MAC(MAC_write_key, seq_num + MAC(MAC_write_key, seq_num +
TLSCompressed.type + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.version +
length + length +
TLSCiphertext.fragment.GenericStreamCipher.pad + TLSCiphertext.fragment.GenericStreamCipher.pad +
TLSCompressed.fragment); TLSCompressed.fragment);
Block Ciphers: Block Ciphers:
MAC(MAC_write_key, seq_num + MAC(MAC_write_key, seq_num +
TLSCompressed.type + TLSCompressed.type +
TLSCompressed.version + TLSCompressed.version +
length + length +
TLSCiphertext.fragment.GenericBlockCipher.pad + TLSCiphertext.fragment.GenericBlockCipher.pad +
TLSCompressed.fragment); TLSCompressed.fragment);
AEAD Ciphers: AEAD Ciphers:
additional_data = seq_num + TLSCompressed.type + additional_data = seq_num + TLSCompressed.type +
TLSCompressed.version + length; TLSCompressed.version + length;
AEADEncrypted = AEAD-Encrypt(write_key, nonce, AEADEncrypted = AEAD-Encrypt(write_key, nonce,
pad + plaintext, pad + plaintext,
additional_data); additional_data);
skipping to change at page 10, line 21 skipping to change at page 6, line 16
Security Version 1.2", RFC 6347, January 2012. Security Version 1.2", RFC 6347, January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[DTLS-ATTACK] [DTLS-ATTACK]
Nadhem, N. and K. Paterson, "Plaintext-recovery attacks Nadhem, N. and K. Paterson, "Plaintext-recovery attacks
against datagram TLS.", Network and Distributed System against datagram TLS.", Network and Distributed System
Security Symposium , 2012. Security Symposium , 2012.
[LH-PADDING]
Pironti, A., Strub, P., and K. Bhargavan, "Identifying
Website Users by TLS Traffic Analysis: New Attacks and
Effective Countermeasures.", INRIA Research Report 8067 ,
2012.
[CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux,
"Password Interception in a SSL/TLS Channel", Advances in "Password Interception in a SSL/TLS Channel", Advances in
Cryptology -- CRYPTO , 2003. Cryptology -- CRYPTO , 2003.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors wish to thank Kenny Paterson for his suggestions on The authors wish to thank Kenny Paterson for his suggestions on
improving this document. improving this document.
Authors' Addresses Authors' Addresses
Nikos Mavrogiannopoulos Nikos Mavrogiannopoulos
Red Hat Red Hat
Purky&#328;ova 99/75a Purkynova 99/75a
Brno, 612 00 Brno 612 00
Czech Republic Czech Republic
Email: nmav@redhat.com Email: nmav@redhat.com
Alfredo Pironti Alfredo Pironti
INRIA Paris-Rocquencourt INRIA Paris-Rocquencourt
23, Avenue d'Italie 23, Avenue d'Italie
Paris, 75214 CEDEX 13 Paris 75214 CEDEX 13
France France
Email: alfredo.pironti@inria.fr Email: alfredo.pironti@inria.fr
 End of changes. 14 change blocks. 
41 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/