Datagram Transport Layer Security in Constrained Environments
draft-hartke-core-codtls-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Klaus Hartke , Olaf Bergmann | ||
| Last updated | 2012-03-12 | ||
| Replaced by | draft-hartke-dice-practical-issues | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hartke-core-codtls-01
CoRE Working Group K. Hartke
Internet-Draft O. Bergmann
Intended status: Informational Universitaet Bremen TZI
Expires: September 14, 2012 March 13, 2012
Datagram Transport Layer Security in Constrained Environments
draft-hartke-core-codtls-01
Abstract
We consider some obstacles in implementing Datagram Transport Layer
Security (DTLS) in constrained environments, and present some ideas
for a constrained version of DTLS that is friendly to constrained
nodes and networks.
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 14, 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 14, 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 . . . . . . . . 5
3.1. Smaller messages . . . . . . . . . . . . . . . . . . . . . 5
3.2. Less state . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Shorter handshakes . . . . . . . . . . . . . . . . . . . . 7
3.4. Fewer transmissions . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Hartke & Bergmann Expires September 14, 2012 [Page 2]
Internet-Draft Constrained DTLS March 2012
1. Introduction
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 [I-D.bormann-lwig-guidance].
Network communication, especially wireless, also imposes constraints
that need to be considered during protocol design, e.g. low bitrate,
variable delay and possibly high packet loss. Moreover, frames at
the link layer might be much smaller than the IPv6 minimum MTU of
1280 octets and therefore require additional mapping mechanisms such
as 6LoWPAN [RFC4944] for IEEE 802.15.4 wireless networks, which in
turn may exacerbate the limitations of the network: E.g., as high
loss rates are anticipated by design, application protocols usually
try to avoid fragmentation at the network layer.
However, application protocols often delegate security mechanisms to
transport layer security protocols. More often than not, the
protocol overhead from securing the communication is highly relevant
to the overall performance of the systems.
One protocol that has received significant attention recently for
constrained node/network applications is Datagram Transport Layer
Security (DTLS) [RFC6347]. DTLS is derived from and inherits some
characteristics from TLS [RFC5246], which has not been designed with
constrained nodes/networks in mind.
The present document considers some obstacles in implementing DTLS in
constrained environments, and presents some ideas for a constrained
version of DTLS that is friendly to constrained nodes and networks.
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 [RFC2119].
2. Implementing DTLS in Constrained Environments
As an example for the TLS traits that DTLS inherits (and
exacerbates), DTLS has a per-record overhead of 13 octets 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 additional
octets, leading to an overall overhead of 29 octets 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
Hartke & Bergmann Expires September 14, 2012 [Page 3]
Internet-Draft Constrained DTLS March 2012
constrained nodes; buffers must be large enough to hold all fragments
for reassembly and losing a single fragment will cause the entire
DTLS message to be retransmitted. This is very likely especially for
messages at the handshake layer during key and certificate exchange
as these will not fit within a single frame in most 6LoWPANs.
Besides buffer space for packet reassembly at the receiver, a sender
must provide extra buffer space for payload encoding. In particular,
the use of some AEAD ciphers requires inclusion of sequence numbers
in the ciphertext calculation. The sender therefore must keep the
plaintext version of each message in a separate buffer and thus
cannot encrypt it in place.
Nodes with very constrained main memory also suffer from the complex
DTLS handshake protocol. Figure 1 shows the message flights required
for a full DTLS handshake. We envision that the acceptance of DTLS
as security protocol for embedded devices would significantly
increase if a faster setup procedure with a smaller number of
handshake messages was defined.
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: The six message flights of a full DTLS handshake
Hartke & Bergmann Expires September 14, 2012 [Page 4]
Internet-Draft Constrained DTLS March 2012
3. Constrained Datagram Transport Layer Security
This section presents a random collection of ideas for a constrained
version of DTLS ("Constrained DTLS") that is friendly to constrained
nodes by enabling small buffer sizes, reduced state and fewer and
smaller messages -- at the cost of being constrained.
The ideas fall into the following categories:
Implementation guidance: Implementation techniques for achieving
light-weight implementations of DTLS, without affecting
conformance to the relevant specifications or interoperability
with other implementations. This includes techniques for reducing
complexity, memory footprint, or power usage. The result may
eventually be incorporated into [I-D.bormann-lwig-guidance].
Stateless header compression: DTLS records get compressed without
explicitly building any compression context state. This is done
by using shorter forms to represent the same bits of information
or relying on information that is already shared by client and
server. Existing DTLS implementations can continue to be used if
a thin layer is added that handles compression/decompression.
Protocol profile: Use of DTLS in a particular way, for example, by
changing MAYs into MUSTs or MUST NOTs, or by requiring or
precluding certain extensions or cipher suites. Existing DTLS
implementations ought to continue to be used without change if
they can be configured accordingly.
Other: Breaking changes. New implementations are required that do
not interoperate with implementations of DTLS.
3.1. Smaller messages
o When AES-CCM [I-D.mcgrew-tls-aes-ccm] 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.
o Since the DTLS version is negotiated in the handshake, there
should be 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.
o DTLS records specify their length so multiple records can be
transmitted in a single datagram. When DTLS is used with UDP
(which preserves the message boundaries of all sent messages),
Hartke & Bergmann Expires September 14, 2012 [Page 5]
Internet-Draft Constrained DTLS March 2012
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. For example, the 16-bit epoch is either 0 or
1 in most cases.
o Use of a bit field instead of multiple type fields to indicate
which handshake messages are present in a datagram.
3.2. Less state
o The handshake messages within a flight can be processed in any
order: they essentially all just mutate the connection state
without any interdependence. The resulting state is not needed
until all messages have been received. However, the TLS Finished
message includes the hash of all handshake messages which, for
this purpose, need to be processed in the right order for the hash
to be correct. If this was not required, the need for large
buffers to queue reordered messages for future handling could be
alleviated.
An alternative to the hash of the concatenation of all the
Handshake structures might be to compute the hash of the current
and the pending connection state (security parameters, client and
server write parameters, negotiated extensions, etc.).
o The reassembly of fragmented handshake messages requires large
buffers, because buffer space is not only needed to reassemble the
next expected message, but also reordered fragments of following
messages. If entities are required to use an out-of-band
mechanism to exchange large blobs, then the fragmentation of
messages could be removed altogether.
For example, the TLS Cached Information Extension
[I-D.ietf-tls-cached-info] allows to omit the exchange of fairly
static information, such as the server certificate, if this
information is already available.
o TLS defines four logical connection states: the current read and
write states, and the pending read and write states. Records are
processed under the current states; pending states are needed
during a (re-)handshake until ChangeCipherSpec makes the pending
states current.
The maintenance of a pool of connection states can lead to
considerable complexity in an implementation. To reduce
complexity, implementations can choose to not support
Hartke & Bergmann Expires September 14, 2012 [Page 6]
Internet-Draft Constrained DTLS March 2012
rehandshakes. This allows the implementation to logically keep
only the following connection states: the read and write states of
epoch 0 (which specifies that no encryption, compression, or MAC
is used), and the read and writes states of epoch 1. These four
states can be implemented in a very compact way.
o In DTLS, each retransmission is a new record with a new sequence
number value. If the sequence number if part of the nonce, this
means that a sender cannot encrypt plaintext in-place but must
keep the plaintext in a separate buffer until the transmission
succeeds or eventually times out.
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 A DTLS handshake has two additional flights when compared to TLS,
resulting from the addition of a stateless cookie exchange. This
exchange is designed to prevent certain denial-of-service attacks:
consumption of excessive server resources cause by the
transmission of a series of handshake initiation requests, and use
of the server as an amplifier by sending connection initiation
messages with a forged source of the victim.
If the cipher suite permits that the server remains stateless
after sending ServerHello..ServerHelloDone, and
ServerHello..ServerHelloDone fits in one datagram, then a full
handshake could perhaps be shortened to four flights (see
Figure 2).
Hartke & Bergmann Expires September 14, 2012 [Page 7]
Internet-Draft Constrained DTLS March 2012
Client Server
------ ------
ClientHello --------> Flight 1
HelloVerifyRequest \
ServerHello Flight 2
<-------- ServerHelloDone /
(remain stateless)
ClientHello \
"ServerHello" \
ClientKeyExchange Flight 3
[ChangeCipherSpec] /
Finished --------> /
[ChangeCipherSpec] \ Flight 4
<-------- Finished /
Figure 2: Artist's impression of a four-flight DTLS PSK handshake
o As an alternative, client puzzles could be used as a mechanism for
mitigating denial-of-service attacks, resulting in a four-flight
exchange similar to the one in HIP DEX [I-D.moskowitz-hip-rg-dex]
(shown in Figure 3). The application of client puzzles to TLS has
been shown [Usenix01]. However, in the case the client is a
constrained node, client puzzles may be too challenging.
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 3: The four-packet HIP DEX exchange
Hartke & Bergmann Expires September 14, 2012 [Page 8]
Internet-Draft Constrained DTLS March 2012
3.4. Fewer transmissions
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.
o In DTLS, when a datagram carrying one part of a flight is lost,
the whole flight needs to be retransmitted, possibly requiring the
retransmission of the whole previous flight.
A thin reliability layer such as the one provided by CoAP
[I-D.ietf-core-coap] could be used, such that only the messages
that are lost would need to be retransmitted instead of all
messages of an entire flight.
4. Security Considerations
Beyond stateless header compression and profiling, changes to the
TLS/DTLS protocol need to be performed extremely carefully. No
analysis has been done in the present version of this draft.
5. IANA Considerations
This draft includes no request to IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.bormann-lwig-guidance]
Bormann, C., "Guidance for Light-Weight Implementations of
Hartke & Bergmann Expires September 14, 2012 [Page 9]
Internet-Draft Constrained DTLS March 2012
the Internet Protocol Suite",
draft-bormann-lwig-guidance-01 (work in progress),
January 2012.
[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.ietf-tls-cached-info]
Santesson, S. and H. Tschofenig, "Transport Layer Security
(TLS) Cached Information Extension",
draft-ietf-tls-cached-info-11 (work in progress),
December 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.
[I-D.moskowitz-hip-rg-dex]
Moskowitz, R., "HIP Diet EXchange (DEX)",
draft-moskowitz-hip-rg-dex-05 (work in progress),
March 2011.
[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.
[Usenix01]
Dean, D. and A. Stubblefield, "Using Client Puzzles to
Protect TLS", 2001,
<http://www.csl.sri.com/users/ddean/papers/usenix01b.pdf>.
Hartke & Bergmann Expires September 14, 2012 [Page 10]
Internet-Draft Constrained DTLS March 2012
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
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 14, 2012 [Page 11]