Subject: [Dtls-iot] Issue#17: AES-CCM nonces in DTLS records

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 Dec 2014 09:10:25 +0100

Here is a proposal for resolving issue#17:
http://trac.tools.ietf.org/wg/dice/trac/ticket/17

------

Appendix B: DTLS Record Layer Per-Packet Overhead

Figure X shows the overhead for the DTLS record layer for protecting
data traffic when AES-128-CCM with an 8-octet Integrity Check Value
(ICV) is used.

DTLS Record Layer Header................13 bytes
Nonce (Explicit).........................8 bytes
ICV..................................... 8 bytes
------------------------------------------------
Overhead................................29 bytes
------------------------------------------------

Figure X: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead.

The DTLS record layer header has 13 octets and consists of
- 1 octet content type field,
- 2 octet version field,
- 2 octet epoch field,
- 6 octet sequence number,
- 2 octet length field.

The "nonce" input to the AEAD algorithm is exactly that of [RFC5288],
i.e., 12 bytes long. It consists of a 4 octet salt and an 8 octet nonce.

The salt is the "implicit" part of the nonce and is not sent in the
packet. Since the nonce_explicit may be the 8 octet sequence number and,
in DTLS, it is the 8 octet epoch concatenated with the 6 octet sequence
number.

The sequence number component of the nonce_explicit field in the record
layer is an exact copy of the sequence number in the record layer header
field. Hence, this leads to a duplication of 8-bytes per record.

To avoid this 8-byte duplication RFC 7400 provides help with the use of
the generic header compression technique for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs).

Note that this header compression technique is not available when DTLS
is exchanged over transports that do not use IPv6 or 6LoWPAN, such as
the SMS transport described in Appendix A.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 Dec 2014 09:52:41 +0100

> the SMS transport described in Appendix A.

Interesting.  Should we think about a version of GHC for SMS?

Gruesse, Carsten