TLS Working Group Jayaraghavendran K Internet-Draft Raja Ashok V K Intended Status: Standards Track Huawei Technologies Expires: April 1, 2016 Sep 29, 2015 TLS/DTLS Omit AEAD Explicit Nonce from Record Extension draft-jay-tls-omit-aead-explicit-nonce-extension-00 Abstract With emergence of Internet of Things(IoT), DTLS is being widely considered as a protocol of choice for communication security in IoT applications. Further, AES_CCM has emerged as the cipher of choice in constrained environments. Constrained Application Protocol (CoAP), which is the application layer protocol for resource constrained environments, mandates DTLS as underlying security protocol and proposes AES_CCM based ciphers to be used with different key exchange methods. AEAD ciphers requires an explicit nonce of 8 bytes must be carried in each transmitted record.This document defines a TLS (and DTLS) extension, which will allow clients and servers to omit the explicit nonce sent in TLS/DTLS records. This document can be considered as an extended version of "Transport Layer Security (TLS) Extensions : Extension Definitions". The extension defined in this document apply equally to both DTLS and TLS protocols. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on 1 April, 2016. Jay & Ashok Expires April 1, 2016 [Page 1] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 Copyright and License Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Omit AEAD Explicit Nonce Extension . . . . . . . . . . . . . . . 4 2.1 Extension Type . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Extension Data . . . . . . . . . . . . . . . . . . . . . . . 5 3 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4.1 Security Considerations for OmitAEADExplicitNonce . . . . . 6 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 5.2 Informative References . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Jay & Ashok Expires April 1, 2016 [Page 2] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 1 Introduction The Transport Layer Security (TLS) Protocol Version 1.2 is specified in [RFC5246] and Datagram Transport Layer Security (DTLS) Protocol Version 1.2 is specified in [RFC6347]. TLS Extensions are specified in [RFC6066] though it talks about TLS extensions, they are also applicable to DTLS protocol. With the emergence of Internet of Things (IoT), DTLS has also gained a lot of significance and has emerged as the application layer protocol of choice for communication security in personal area networks involving low power and lossy network (LLNs). Similarly, the AES_CCM cipher has also gained acceptance as the cipher of choice to be used in constrained devices and environments. AEAD ciphers require an 8 byte explicit nonce to be transmitted as a part of every record that is transmitted. But, this can be avoided, if both the client and server can negotiate and decide on a mechanism to generate the same explicit nonce independently at their respective ends. This document proposes a new extension to allow the client and server to negotiate a mechanism for generating the same explicit nonce for each TLS/DTLS records when AEAD based ciphers are used for protecting the session. This document currently focuses only on TLS 1.2 / DTLS 1.2 and prior protocol versions. This document doesn't consider the changes being proposed / discussed for TLS 1.3 where already a lot of work is in- progress. 1.1 Terminology 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 RFC 2119 [KEYWORDS]. This specification refers to TLS as well as DTLS and particularly to version 1.2, which is the most recent version at the time of writing this document. The term AEAD ciphers in general refers to Authenticated Encryption with Associated Data mode of operation associated with block ciphers. For the purpose of this document, it particularly refers to CCM and GCM modes of operation. AEAD Ciphers in this document can be understood to refer to ciphers listed in AES_GCM Cipher Suites for TLS[RFC5288] and AES_CCM Cipher Suites for TLS[RFC6655]. Jay & Ashok Expires April 1, 2016 [Page 3] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 2 Omit AEAD Explicit Nonce Extension TLS 1.2 introduced Authenticated Encryption with Associated Data (AEAD) cipher suites. AEAD is a class of block cipher modes which encrypt and authenticate the message simultaneously. Examples of such modes include the Counter with Cipher Block Chaining - Message Authentication Code (CCM) mode, and the Galois/Counter Mode (GCM). Record structure for AEAD cipher is specified in section 6.2.3.3 of TLS 1.2[RFC5246]. struct { opaque nonce_explicit[SecurityParameters.record_iv_length]; aead-ciphered struct{ opaque content[TLSCompressed.length]; }; }GenericAEADCipher; As per the above record structure, "explicit_nonce" of length "record_iv_length" MUST be transmitted in every encrypted record. This explicit nonce should be distinct for each encryption operation for a particular key. AES_CCM Cipher Suites for TLS [RFC6655] & AES Galois Counter Mode (GCM) for TLS [RFC5288] suggest that Record Sequence Number in TLS/DTLS itself can be used as explicit nonce as they are unique for every record transmitted. If record sequence numbers are used as AEAD explicit nonce, then there is no need to send explicit nonce as a part of DTLS (or TLS) records as the sequence number is explicitly sent as a part of Record Header in case of DTLS and is implicitly known to both the peers incase of TLS. Though the above mentioned RFCs [RFC 5288 & RFC 6655] recommend using record sequence numbers as explicit nonce, they don't mention omitting it from the DTLS/TLS records in the document causing all the implementations to send them for every record. This specification proposes a new extension "omit_aead_explicit_nonce" using which client and server can reach an agreement to avoid transmitting the explicit nonce in every record. This specification proposes one method of using record sequence numbers as explicit nonce.Since, there is a possibility of some other mechanism to be used for generating AEAD explicit nonce in future, the new extension also proposes an extension data field in which the peers can negotiate the mechanism to be used for generating explicit nonce. Regardless of the mechanisms used, the presence of this extension indicates the willingness to omit the explicit nonce from (D)TLS record. 2.1 Extension Type Jay & Ashok Expires April 1, 2016 [Page 4] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 This document defined a new extension type (omit_aead_explicit_nonce (TBD)), which is used in Client Hello and Server Hello messages. The extension type is specified as below: enum{ omit_aead_explicit_nonce(TBD), (65535) }ExtensionType; 2.2 Extension Data The "extension_data" field of this extension consists of a single octet, length field followed by a list of nonce generation methods. Each nonce generation method is identified by an ID of size 1 octet. enum { record_seq_as_aead_explicit_nonce (1), (255) }aead_exp_nonce_method; struct { select (Role) { case client: uint8 len; aead_exp_nonce_method ExplicitNonces<1..255>; case server: aead_exp_nonce_method nonce_method; } }OmitAEADExplicitNonce; Initially, the client should include this extension in it's client hello listing the methods it supports for AEAD explicit nonce generation. Server upon receiving this extension, parses through the list of methods and replies by adding this extension in it's server hello. Server MUST add exactly one method in it's extension data from the list of methods proposed by client. If Server doesn't include this extension in it's Server Hello, it indicates server's unwillingness to omit explicit nonces from it's records. Clients SHOULD add this extension in it's client hello only if the list of ciphers proposed by it includes at least one AEAD cipher. Server MUST include this extension in it's server hello only if it has chosen an AEAD cipher from the client's list. It should be noted that using record sequence numbers as explicit nonce is just one method prescribed by this specification and newer methods may be added in future. If a server receives a client hello message with a non AEAD cipher Jay & Ashok Expires April 1, 2016 [Page 5] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 and with OmitAEADExplicitNonce extension in the client hello extensions, then it SHOULD ignore the extension. If a client receives a server hello message in which the cipher of choice is not an AEAD cipher, but the said extension is present or if the extension is present without client sending it in it's client hello message, then it MUST abort the handshake with a fatal "illegal_parameter" alert. Please note that server MAY choose an AEAD cipher, but MAY still decide not to include this extension in it's Server Hello message in which case both the client and server should transmit the explicit nonce as a part of records. If the record_seq_no_as_aead_explicit_nonce method has been negotiated successfully as a part of this extension, then for DTLS, 64 bit explicit sequence number in record header (comprising of 2 byte epoch and 6 byte sequence number) should be used as explicit nonce and for TLS, 8 byte implicit record sequence number should be used as explicit nonce. This extension reduces the record size by 8 octets (size of explicit nonce) for each encrypted record transmitted between client and server. This in-turn helps in reducing the message size for constrained networks like 802.15.4, where CoAP [RFC7252] is the application layer protocol of choice which mandates the use of DTLS with AES_CCM as the preferred cipher. 3 IANA Considerations IANA is requested to add an entry to the existing TLS ExtensionType Registry, defined in TLS [RFC5246] for omit_aead_explicit_nonce(TBD) defined in this document. A new registry type must be created for maintaining the list of methods which can be negotiated under the omit_aead_explicit_nonce extension. Further, an entry for the method record_seq_as_aead_explicit_nonce(TBD) should be added under this registry. 4 Security Considerations General security considerations for TLS extensions are covered in [RFC5246]. Security Considerations for particular extensions specified in this document are given below. 4.1 Security Considerations for OmitAEADExplicitNonce No specific security as corresponding RFCs for use of AES_CCM & AES_GCM Ciphers in TLS already propose using sequence numbers as Jay & Ashok Expires April 1, 2016 [Page 6] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 explicit nonces. This specification only enables the same through the said extension. 5 References 5.1 Normative References [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011. [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, August 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC6655] D. McGrew, D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, July 2012. 5.2 Informative References [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC7252] Z. Shelby, K. Hartke, C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014. [RFC6347] E. Rescorla and N.Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. Authors' Addresses Jayaraghavendran K Huawei Technologies, Near EPIP Industrial Area, Kundalahalli Village, Bangalore, India Jay & Ashok Expires April 1, 2016 [Page 7] Internet-Draft Omit AEAD Explicit Nonce from Record Sep 29, 2015 EMail: jayaraghavendran.k@huawei.com Raja Ashok V K Huawei Technologies, Near EPIP Industrial Area, Kundalahalli Village, Bangalore, India EMail: raja.ashok@huawei.com Jay & Ashok Expires April 1, 2016 [Page 8]