CoRE Working Group K. Hartke
Internet-Draft O. Bergmann
Intended status: Informational Universitaet Bremen TZI
Expires: September 7, 2012 March 6, 2012
Datagram Transport Layer Security in Constrained Environments
draft-hartke-core-codtls-00
Abstract
We consider some obstacles when it comes to implement Datagram
Transport Layer Security (DTLS) in constrained environments, and
present some ideas for a constrained version of DTLS that is friendly
to constrained devices.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 7, 2012.
Copyright Notice
Copyright (c) 2012 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.
Hartke & Bergmann Expires September 7, 2012 [Page 1]
Internet-Draft Constrained DTLS March 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Implementing DTLS in Constrained Environments . . . . . . . . . 3
3. Constrained Datagram Transport Layer Security . . . . . . . . . 4
3.1. Smaller messages . . . . . . . . . . . . . . . . . . . . . 4
3.2. Less state . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Shorter handshakes . . . . . . . . . . . . . . . . . . . . 6
3.4. Fewer transmissions . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Hartke & Bergmann Expires September 7, 2012 [Page 2]
Internet-Draft Constrained DTLS March 2012
1. Introduction
In Section 2, we consider some obstacles when it comes to implement
Datagram Transport Layer Security (DTLS) [RFC6347] in constrained
environments.
In Section 3, we present some ideas for a constrained version of DTLS
that is friendly to constrained devices by enabling small buffer
sizes, reduced state and fewer and smaller messages -- at the cost of
being constrained.
2. Implementing DTLS in Constrained Environments
Nodes that take part in the "Internet of Things" often have strict
limitations regarding their computational power, memory size (both,
ROM and RAM), and power management. Network communication,
especially wireless, also imposes constraints that need to be
considered during protocol design, e.g. small bandwidth, variable
delay and possibly high packet loss. Moreover, frames at the link
layer might be too small for the IPv6 minimum MTU of 1280 bytes and
therefore require additional mapping mechanisms such as 6LoWPAN
[RFC4944] for IEEE 802.15.4 wireless networks.
As high loss rates are anticipated by design, application protocols
usually try to avoid fragmentation at the network layer. More often
than not, the protocol overhead from securing the communication is
not taken into consideration. As an example, DTLS has a per-record
overhead of 13 bytes for the record header. AEAD ciphers such as
AES-CCM [I-D.mcgrew-tls-aes-ccm] eat up additional space to carry the
explicit nonce and the MAC. Thus, the cipher suite
TLS_PSK_WITH_AES_128_CCM_8 suggested by CoAP [I-D.ietf-core-coap] for
Pre-Shared Key mode requires 16 bytes, leading to an overall of 29
bytes for each encrypted DTLS packet.
Although DTLS offers fragmentation at the record layer and hence can
get around IP fragmentation, packet loss still is a big problem for
constrained devices as buffers must be large enough to hold all
fragments for reassembly and losing a single fragment will cause the
entire message flight to be retransmitted.
(TODO: Because the frame size is so small, it is actually quite
likely that records need to be fragmented and that records of the
same message flight are transmitted in separate datagrams. This
means that message loss and reordering become increasingly probable.)
(TODO: In DTLS, each retransmission is a new record with a new
sequence number value. This means that a sender cannot encrypt
Hartke & Bergmann Expires September 7, 2012 [Page 3]
Internet-Draft Constrained DTLS March 2012
plaintext in-place but must keep the plaintext in a separate buffer
until the transmission succeeds or eventually times out.)
(TODO: Six message flights for a full DTLS handshake (see Figure 1)
are at least two too many.)
(TODO: We expect that nodes communicate with the same small set of
nodes over a very long time with low traffic. However, nodes may not
be able to keep even a small number of sessions open for extended
periods of time.)
Client Server
------ ------
ClientHello --------> Flight 1
<------- HelloVerifyRequest Flight 2
ClientHello --------> Flight 3
ServerHello \
Certificate* \
ServerKeyExchange* Flight 4
CertificateRequest* /
<-------- ServerHelloDone /
Certificate* \
ClientKeyExchange \
CertificateVerify* Flight 5
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 6
<-------- Finished /
Figure 1: Message flights for full handshake
3. Constrained Datagram Transport Layer Security
3.1. Smaller messages
o DTLS allows multiple messages of the same ContentType to be
coalesced into a single record. As a matter of implementation
quality, implementations should coalesce as many messages of the
same ContentType into a single record as possible. Similarly,
implementations should not fragment a message if the record fits
in a single datagram.
Hartke & Bergmann Expires September 7, 2012 [Page 4]
Internet-Draft Constrained DTLS March 2012
o Stateless header compression (cf. [RFC6282]):
* When AES-CCM [I-D.mcgrew-tls-aes-ccm] (a set of AEAD cipher
suites) is used, the GenericAEADCipher.nonce_explicit field is
set to the 16-bit epoch concatenated with the 48-bit sequence
number. This means the epoch and sequence number are included
twice in each record. Stateless header compression could
eliminate this redundancy.
* Similarly, if the DTLS version is negotiated in the handshake,
there is no need to specify the DTLS version in each and every
record. Stateless header compression could eliminate the DTLS
version field where it is implicitly clear.
* DTLS records specify their length so multiple records can be
transmitted in a single datagram. When DTLS is used with UDP,
stateless header compression could eliminate the length field
of the last record in a datagram.
o Use of self-delimiting numeric values [RFC6256] instead of fixed-
size numeric values.
o Elliptic curve cryptography for small key sizes: "Smaller key
sizes result in savings for power, memory, bandwidth, and
computational cost that make ECC especially attractive for
constrained environments." [RFC4492]
3.2. Less state
o The Finished message includes the hash of all handshake messages
which, for this purpose, need to processed in the right order. If
this would not be required, handshake messages within a flight
could be processed in any order, alleviating the need for large
buffers to bring reordered messages back into order. An
alternative to the hash of the concatenation of all the Handshake
structures might be to compute the hash of the pending connection
state (i.e. the SecurityParameters structure, client and server
write parameters, negotiated extensions, etc.).
o If entities use an out-of-band mechanism to exchange large blobs
such as certificates (e.g., CoAP [I-D.ietf-core-coap]), then
fragmentation could be removed altogether.
o (TODO: If the possibility of rehandshakes was constrained/removed,
there would be no need for current and pending, read and write
state.)
Hartke & Bergmann Expires September 7, 2012 [Page 5]
Internet-Draft Constrained DTLS March 2012
o (TODO: If retransmission would not use a new sequence number,
plaintext could be encrypted in-place without the need for a
second buffer.)
3.3. Shorter handshakes
o Client puzzles have been proposed as a mechanism for mitigating
denial-of-service attacks. Client puzzles could be used in DTLS
to create a four-flight exchange similiar to the one in HIP DEX
[I-D.moskowitz-hip-rg-dex] (shown in Figure 2). The application
to TLS has been shown [Usenix01].
o TLS False Start [I-D.bmoeller-tls-falsestart]: Achieves an
improvement of one round-trip time for full handshakes if the
client sends application data first and for abbreviated handshakes
if the server sends application data first.
o TLS Snap Start [I-D.agl-tls-snapstart]: Eliminates the latency of
handshakes when the client has prior knowledge about the server.
This prior knowledge is not secret and may be obtained from third
parties (e.g., a CoRE Resource Directory
[I-D.shelby-core-resource-directory]) and cached for significant
periods of time.
Initiator Responder
I1:
-------------------------->
select precomputed R1
R1: puzzle, PK
<-------------------------
solve puzzle remain stateless
PK Encrypt x
I2: solution, PK, ECR(DH,secret x), mac
-------------------------->
check puzzle
check mac
PK Encrypt y
R2: PK, ECR(DH,secret y), mac
<--------------------------
check mac
Figure 2: Four-packet HIP DEX exchange
Hartke & Bergmann Expires September 7, 2012 [Page 6]
Internet-Draft Constrained DTLS March 2012
3.4. Fewer transmissions
o (TODO: Use CON/ACK/RST/NON so only lost messages need to
retransmitted instead of the whole flight.)
4. Security Considerations
Security issues are discussed throughout this memo.
5. IANA Considerations
This memo includes no request to IANA.
6. References
6.1. Normative References
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
6.2. Informative References
[I-D.agl-tls-snapstart]
Langley, A., "Transport Layer Security (TLS) Snap Start",
draft-agl-tls-snapstart-00 (work in progress), June 2010.
[I-D.bmoeller-tls-falsestart]
Langley, A., Modadugu, N., and B. Moeller, "Transport
Layer Security (TLS) False Start",
draft-bmoeller-tls-falsestart-00 (work in progress),
June 2010.
[I-D.ietf-core-coap]
Frank, B., Bormann, C., Hartke, K., and Z. Shelby,
"Constrained Application Protocol (CoAP)",
draft-ietf-core-coap-08 (work in progress), October 2011.
[I-D.mcgrew-tls-aes-ccm]
McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for TLS",
draft-mcgrew-tls-aes-ccm-03 (work in progress),
February 2012.
Hartke & Bergmann Expires September 7, 2012 [Page 7]
Internet-Draft Constrained DTLS March 2012
[I-D.moskowitz-hip-rg-dex]
Moskowitz, R., "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-rg-dex-05 (work in progress),
March 2011.
[I-D.shelby-core-resource-directory]
Krco, S. and Z. Shelby, "CoRE Resource Directory",
draft-shelby-core-resource-directory-02 (work in
progress), October 2011.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC6256] Eddy, W. and E. Davies, "Using Self-Delimiting Numeric
Values in Protocols", RFC 6256, May 2011.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011.
[Usenix01]
Dean, D. and A. Stubblefield, "Using Client Puzzles to
Protect TLS", 2001,
<http://www.csl.sri.com/users/ddean/papers/usenix01b.pdf>.
Authors' Addresses
Klaus Hartke
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63905
Fax: +49-421-218-7000
Email: hartke@tzi.org
Hartke & Bergmann Expires September 7, 2012 [Page 8]
Internet-Draft Constrained DTLS March 2012
Olaf Bergmann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63904
Fax: +49-421-218-7000
Email: bergmann@tzi.org
Hartke & Bergmann Expires September 7, 2012 [Page 9]