Internet DRAFT - draft-jay-tls-omit-aead-explicit-nonce-extension
draft-jay-tls-omit-aead-explicit-nonce-extension
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]
