Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   None   None  Group: DICE

RFC 7925

Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things

Pages: 61
Proposed STD
Part 3 of 3 – Pages 42 to 61
First   Prev   None

Top   ToC   Page 42   prevText
17.  Renegotiation Attacks

   TLS/DTLS allows a client and a server that already have a TLS/DTLS
   connection to negotiate new parameters, generate new keys, etc., by
   using the renegotiation feature.  Renegotiation happens in the
   existing connection, with the new handshake packets being encrypted
   along with application data.  Upon completion of the renegotiation
   procedure, the new channel replaces the old channel.

   As described in RFC 5746 [RFC5746], there is no cryptographic binding
   between the two handshakes, although the new handshake is carried out
   using the cryptographic parameters established by the original

   To prevent the renegotiation attack [RFC5746], this specification
   REQUIRES the TLS renegotiation feature to be disabled.  Clients MUST
   respond to server-initiated renegotiation attempts with an alert
   message (no_renegotiation), and clients MUST NOT initiate them.

18.  Downgrading Attacks

   When a client sends a ClientHello with a version higher than the
   highest version known to the server, the server is supposed to reply
   with ServerHello.version equal to the highest version known to the
   server, and then the handshake can proceed.  This behavior is known
   as version tolerance.  Version intolerance is when the server (or a
   middlebox) breaks the handshake when it sees a ClientHello.version
   higher than what it knows about.  This is the behavior that leads
   some clients to rerun the handshake with a lower version.  As a
   result, a potential security vulnerability is introduced when a
   system is running an old TLS/SSL version (e.g., because of the need
   to integrate with legacy systems).  In the worst case, this allows an
   attacker to downgrade the protocol handshake to SSL 3.0.  SSL 3.0 is
   so broken that there is no secure cipher available for it (see

   The above-described downgrade vulnerability is solved by the TLS
   Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension.
   However, the solution is not applicable to implementations conforming
   to this profile since the version negotiation MUST use TLS/DTLS
   version 1.2 (or higher).  More specifically, this implies:

   o  Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in
      the ClientHello.

   o  Clients MUST NOT retry a failed negotiation offering a TLS/DTLS
      version lower than 1.2.
Top   ToC   Page 43
   o  Servers MUST fail the handshake by sending a protocol_version
      fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated.
      Note that the aborted connection is non-resumable.

19.  Crypto Agility

   This document recommends that software and chip manufacturers
   implement AES and the CCM mode of operation.  This document
   references the CoAP-recommended ciphersuite choices, which have been
   selected based on implementation and deployment experience from the
   IoT community.  Over time, the preference for algorithms will,
   however, change.  Not all components of a ciphersuite are likely to
   change at the same speed.  Changes are more likely expected for
   ciphers, the mode of operation, and the hash algorithms.  The
   recommended key lengths have to be adjusted over time as well.  Some
   deployment environments will also be impacted by local regulation,
   which might dictate a certain algorithm and key size combination.
   Ongoing discussions regarding the choice of specific ECC curves will
   also likely impact implementations.  Note that this document does not
   recommend or mandate a specific ECC curve.

   The following recommendations can be made to chip manufacturers:

   o  Make any AES hardware-based crypto implementation accessible to
      developers working on security implementations at higher layers in
      the protocol stack.  Sometimes hardware implementations are added
      to microcontrollers to offer support for functionality needed at
      the link layer and are only available to the on-chip link-layer
      protocol implementation.  Such a setup does not allow application
      developers to reuse the hardware-based AES implementation.

   o  Provide flexibility for the use of the crypto function with future
      extensibility in mind.  For example, making an AES-CCM
      implementation available to developers is a first step but such an
      implementation may not be usable due to parameter differences
      between an AES-CCM implementation.  AES-CCM in IEEE 802.15.4 and
      Bluetooth Smart use a nonce length of 13 octets while DTLS uses a
      nonce length of 12 octets.  Hardware implementations of AES-CCM
      for IEEE 802.15.4 and Bluetooth Smart are therefore not reusable
      by a DTLS stack.

   o  Offer access to building blocks in addition (or as an alternative)
      to the complete functionality.  For example, a chip manufacturer
      who gives developers access to the AES crypto function can use it
      to build an efficient AES-GCM implementation.  Another example is
      to make a special instruction available that increases the speed
      of speed-up carryless multiplications.
Top   ToC   Page 44
   As a recommendation for developers and product architects, we suggest
   that sufficient headroom is provided to allow an upgrade to a newer
   cryptographic algorithm over the lifetime of the product.  As an
   example, while AES-CCM is recommended throughout this specification,
   future products might use the ChaCha20 cipher in combination with the
   Poly1305 authenticator [RFC7539].  The assumption is made that a
   robust software update mechanism is offered.

20.  Key Length Recommendations

   RFC 4492 [RFC4492] gives approximate comparable key sizes for
   symmetric- and asymmetric-key cryptosystems based on the best-known
   algorithms for attacking them.  While other publications suggest
   slightly different numbers, such as [Keylength], the approximate
   relationship still holds true.  Figure 12 illustrates the comparable
   key sizes in bits.

                       Symmetric  |   ECC   |  DH/DSA/RSA
                           80     |   163   |     1024
                          112     |   233   |     2048
                          128     |   283   |     3072
                          192     |   409   |     7680
                          256     |   571   |    15360

        Figure 12: Comparable Key Sizes (in Bits) Based on RFC 4492

   At the time of writing, the key size recommendations for use with
   TLS-based ciphers found in [RFC7525] recommend DH key lengths of at
   least 2048 bits, which corresponds to a 112-bit symmetric key and a
   233-bit ECC key.  These recommendations are roughly in line with
   those from other organizations, such as the National Institute of
   Standards and Technology (NIST) or the European Network and
   Information Security Agency (ENISA).  The authors of
   [ENISA-Report2013] add that a 80-bit symmetric key is sufficient for
   legacy applications for the coming years, but a 128-bit symmetric key
   is the minimum requirement for new systems being deployed.  The
   authors further note that one needs to also take into account the
   length of time data needs to be kept secure for.  The use of 80-bit
   symmetric keys for transactional data may be acceptable for the near
   future while one has to insist on 128-bit symmetric keys for long-
   lived data.

   Note that the recommendations for 112-bit symmetric keys are chosen
   conservatively under the assumption that IoT devices have a long
   expected lifetime (such as 10+ years) and that this key length
   recommendation refers to the long-term keys used for device
   authentication.  Keys, which are provisioned dynamically, for the
Top   ToC   Page 45
   protection of transactional data (such as ephemeral DH keys used in
   various TLS/DTLS ciphersuites) may be shorter considering the
   sensitivity of the exchanged data.

21.  False Start

   A full TLS handshake as specified in [RFC5246] requires two full
   protocol rounds (four flights) before the handshake is complete and
   the protocol parties may begin to send application data.

   An abbreviated handshake (resuming an earlier TLS session) is
   complete after three flights, thus adding just one round-trip time if
   the client sends application data first.

   If the conditions outlined in [TLS-FALSESTART] are met, application
   data can be transmitted when the sender has sent its own
   "ChangeCipherSpec" and "Finished" messages.  This 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.

   The conditions for using the TLS False Start mechanism are met by the
   public-key-based ciphersuites in this document.  In summary, the
   conditions are:

   o  Modern symmetric ciphers with an effective key length of 128 bits,
      such as AES-128-CCM

   o  Client certificate types, such as ecdsa_sign

   o  Key exchange methods, such as ECDHE_ECDSA

   Based on the improvement over a full round-trip for the full TLS/DTLS
   exchange, this specification RECOMMENDS the use of the False Start
   mechanism when clients send application data first.

22.  Privacy Considerations

   The DTLS handshake exchange conveys various identifiers, which can be
   observed by an on-path eavesdropper.  For example, the DTLS PSK
   exchange reveals the PSK identity, the supported extensions, the
   session ID, algorithm parameters, etc.  When session resumption is
   used, then individual TLS sessions can be correlated by an on-path
   adversary.  With many IoT deployments, it is likely that keying
   material and their identifiers are persistent over a longer period of
   time due to the cost of updating software on these devices.
Top   ToC   Page 46
   User participation poses a challenge in many IoT deployments since
   many of the IoT devices operate unattended, even though they are
   initially provisioned by a human.  The ability to control data
   sharing and to configure preferences will have to be provided at a
   system level rather than at the level of the DTLS exchange itself,
   which is the scope of this document.  Quite naturally, the use of
   DTLS with mutual authentication will allow a TLS server to collect
   authentication information about the IoT device (likely over a long
   period of time).  While this strong form of authentication will
   prevent misattribution, it also allows strong identification.
   Device-related data collection (e.g., sensor recordings) associated
   with other data types will prove to be truly useful, but this extra
   data might include personal information about the owner of the device
   or data about the environment it senses.  Consequently, the data
   stored on the server side will be vulnerable to stored data
   compromise.  For the communication between the client and the server,
   this specification prevents eavesdroppers from gaining access to the
   communication content.  While the PSK-based ciphersuite does not
   provide PFS, the asymmetric versions do.  This prevents an adversary
   from obtaining past communication content when access to a long-term
   secret has been gained.  Note that no extra effort to make traffic
   analysis more difficult is provided by the recommendations made in
   this document.

   Note that the absence or presence of communication itself might
   reveal information to an adversary.  For example, a presence sensor
   may initiate messaging when a person enters a building.  While TLS/
   DTLS would offer confidentiality protection of the transmitted
   information, it does not help to conceal all communication patterns.
   Furthermore, the IP header, which is not protected by TLS/DTLS,
   additionally reveals information about the other communication
   endpoint.  For applications where such privacy concerns exist,
   additional safeguards are required, such as injecting dummy traffic
   and onion routing.  A detailed treatment of such solutions is outside
   the scope of this document and requires a system-level view.

23.  Security Considerations

   This entire document is about security.

   We would also like to point out that designing a software update
   mechanism into an IoT system is crucial to ensure that both
   functionality can be enhanced and that potential vulnerabilities can
   be fixed.  This software update mechanism is important for changing
   configuration information, for example, trust anchors and other
   keying-related information.  Such a suitable software update
   mechanism is available with the LWM2M protocol published by the OMA
Top   ToC   Page 47
24.  References

24.1.  Normative References

   [EUI64]    IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)",
              Registration Authority,

   [GSM-SMS]  ETSI, "3rd Generation Partnership Project; Technical
              Specification Group Core Network and Terminals; Technical
              realization of the Short Message Service (SMS) (Release
              13)", 3GPP TS 23.040 V13.1.0, March 2016.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC4279]  Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
              Ciphersuites for Transport Layer Security (TLS)",
              RFC 4279, DOI 10.17487/RFC4279, December 2005,

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              DOI 10.17487/RFC5246, August 2008,

   [RFC5746]  Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
              "Transport Layer Security (TLS) Renegotiation Indication
              Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010,

   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
              Extensions: Extension Definitions", RFC 6066,
              DOI 10.17487/RFC6066, January 2011,

   [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              within Internet Public Key Infrastructure Using X.509
              (PKIX) Certificates in the Context of Transport Layer
              Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
              2011, <>.
Top   ToC   Page 48
   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <>.

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520,
              DOI 10.17487/RFC6520, February 2012,

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <>.

   [RFC7251]  McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
              TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,

   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension", RFC 7924,
              DOI 10.17487/RFC7924, July 2016,

   [WAP-WDP]  Open Mobile Alliance, "Wireless Datagram Protocol",
              Wireless Application Protocol, WAP-259-WDP, June 2001.

24.2.  Informative References

   [ACE-WG]   IETF, "Authentication and Authorization for Constrained
              Environments (ACE) Working Group",

   [AES]      National Institute of Standards and Technology, "Advanced
              Encryption Standard (AES)", NIST FIPS PUB 197, November
              2001, <
Top   ToC   Page 49
   [CCM]      National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation: The
              CCM Mode for Authentication and Confidentiality", NIST
              Special Publication 800-38C, May 2004,

              Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets", Work
              in Progress, draft-ietf-core-coap-tcp-tls-03, July 2016.

   [CoRE-RD]  Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", Work in Progress, draft-ietf-core-
              resource-directory-08, July 2016.

   [CRIME]    Wikipedia, "CRIME", May 2016, <

              ENISA, "Algorithms, Key Sizes and Parameters Report -
              2013", October 2013, <

              Gillmor, D., "Negotiated Finite Field Diffie-Hellman
              Ephemeral Parameters for TLS", Work in Progress,
              draft-ietf-tls-negotiated-ff-dhe-10, June 2015.

              Eggert, L., Hatoen, S., Kojo, M., Nyrhinen, A., Sarolahti,
              P., and S. Strowes, "An Experimental Study of Home Gateway
              Characteristics", In Proceedings of the 10th ACM SIGCOMM
              conference on Internet measurement,
              DOI 10.1145/1879141.1879174, 2010,

   [IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters",
Top   ToC   Page 50
              Chilton, E., "A Brief Survey of Imprinting Options for
              Constrained Devices", March 2012,

              Giry, D., "Cryptographic Key Length Recommendations",
              September 2015, <>.

   [LWM2M]    Open Mobile Alliance, "Lightweight Machine-to-Machine
              Requirements", Candidate Version 1.0, OMA-RD-
              LightweightM2M-V1_0-20131210-C, December 2013,

              Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher
              Suites with Forward Secrecy for Transport Layer Security
              (TLS)", Work in Progress, draft-schmertmann-dice-ccm-
              psk-pfs-01, August 2014.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
              1996, <>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
              2003, <>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
Top   ToC   Page 51
   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,

   [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,
              DOI 10.17487/RFC4492, May 2006,

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, DOI 10.17487/RFC4919, August 2007,

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <>.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, DOI 10.17487/RFC5247, August 2008,

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
Top   ToC   Page 52
   [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
              Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
              DOI 10.17487/RFC5288, August 2008,

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,

   [RFC5758]  Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
              Polk, "Internet X.509 Public Key Infrastructure:
              Additional Algorithms and Identifiers for DSA and ECDSA",
              RFC 5758, DOI 10.17487/RFC5758, January 2010,

   [RFC5934]  Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
              Management Protocol (TAMP)", RFC 5934,
              DOI 10.17487/RFC5934, August 2010,

   [RFC6024]  Reddy, R. and C. Wallace, "Trust Anchor Management
              Requirements", RFC 6024, DOI 10.17487/RFC6024, October
              2010, <>.

   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", RFC 6090,
              DOI 10.17487/RFC6090, February 2011,

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655,
              DOI 10.17487/RFC6655, July 2012,

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
Top   ToC   Page 53
   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <>.

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <>.

   [RFC7366]  Gutmann, P., "Encrypt-then-MAC for Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014,

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,

   [RFC7397]  Gilger, J. and H. Tschofenig, "Report from the Smart
              Object Security Workshop", RFC 7397, DOI 10.17487/RFC7397,
              December 2014, <>.

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
              2014, <>.

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,
Top   ToC   Page 54
   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
              DOI 10.17487/RFC7465, February 2015,

   [RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
              Suite Value (SCSV) for Preventing Protocol Downgrade
              Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <>.

   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,

   [RFC7568]  Barnes, R., Thomson, M., Pironti, A., and A. Langley,
              "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
              DOI 10.17487/RFC7568, June 2015,

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <>.

              National Institute of Standards and Technology,
              "Recommendation for Applications Using Approved Hash
              Algorithms", NIST Special Publication 800-107, Revision 1,
              DOI 10.6028/NIST.SP.800-107r1, August 2012,

              National Institute of Standards and Technology, "A
              Statistical Test Suite for Random and Pseudorandom Number
              Generators for Cryptographic Applications", NIST Special
              Publication 800-22, Revision 1a, April 2010,
Top   ToC   Page 55
              National Institute of Standards and Technology,
              "Recommendation for Random Number Generation Using
              Deterministic Random Bit Generators", NIST Special
              Publication 800-90A Revision 1,
              DOI 10.6028/NIST.SP.800-90Ar1, June 2015,

              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", Work in Progress,
              draft-ietf-tls-falsestart-02, May 2016.

              Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P.
              Yves Strub, "Triple Handshakes and Cookie Cutters:
              Breaking and Fixing Authentication over TLS", In
              Proceedings of the IEEE Symposium on Security and Privacy,
              Pages 98-113, DOI 10.1109/SP.2014.14, 2014.
Top   ToC   Page 56
Appendix A.  Conveying DTLS over SMS

   This section is normative for the use of DTLS over SMS.  Timer
   recommendations are already outlined in Section 11 and also
   applicable to the transport of DTLS over SMS.

   This section requires readers to be familiar with the terminology and
   concepts described in [GSM-SMS] and [WAP-WDP].

   The remainder of this section assumes Mobile Stations are capable of
   producing and consuming Transport Protocol Data Units (TPDUs) encoded
   as 8-bit binary data.

A.1.  Overview

   DTLS adds an additional round-trip to the TLS [RFC5246] handshake to
   serve as a return-routability test for protection against certain
   types of DoS attacks.  Thus, a full-blown DTLS handshake comprises up
   to 6 "flights" (i.e., logical message exchanges), each of which is
   then mapped on to one or more DTLS records using the segmentation and
   reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347].  The
   overhead for said scheme is 6 bytes per handshake message which,
   given a realistic 10+ messages handshake, would amount to around 60
   bytes across the whole handshake sequence.

   Note that the DTLS SaR scheme is defined for handshake messages only.
   In fact, DTLS records are never fragmented and MUST fit within a
   single transport layer datagram.

   SMS provides an optional segmentation and reassembly scheme as well,
   known as Concatenated short messages (see Section of
   [GSM-SMS]).  However, since the SaR scheme in DTLS cannot be
   circumvented, the Concatenated short messages mechanism SHOULD NOT be
   used during handshake to avoid redundant overhead.  Before starting
   the handshake phase (either actively or passively), the DTLS
   implementation MUST be explicitly configured with the Path MTU (PMTU)
   of the SMS transport in order to correctly instrument its SaR
   function.  The PMTU SHALL be 133 bytes if multiplexing based on the
   Wireless Datagram Protocol (WDP) is used (see Appendix A.3); 140
   bytes otherwise.

   It is RECOMMENDED that the established security context over the
   longest possible period be used (possibly until a Closure Alert
   message is received or after a very long inactivity timeout) to avoid
   the expensive re-establishment of the security association.
Top   ToC   Page 57
A.2.  Message Segmentation and Reassembly

   The content of an SMS message is carried in the TP-UserData field,
   and its size may be up to 140 bytes.  As already mentioned in
   Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent
   using Concatenated SMS.

   This scheme consumes 6-7 bytes (depending on whether the short or
   long segmentation format is used) of the TP-UserData field, thus
   reducing the space available for the actual content of the SMS
   message to 133-134 bytes per TPDU.

   Though in principle a PMTU value higher than 140 bytes could be used,
   which may look like an appealing option given its more efficient use
   of the transport, there are disadvantages to consider.  First, there
   is an additional overhead of 7 bytes per TPDU to be paid to the SaR
   function (which is in addition to the overhead introduced by the DTLS
   SaR mechanism.  Second, some networks only partially support the
   Concatenated SMS function, and others do not support it at all.

   For these reasons, the Concatenated short messages mechanism SHOULD
   NOT be used, and it is RECOMMENDED to leave the same PMTU settings
   used during the handshake phase, i.e., 133 bytes if WDP-based
   multiplexing is enabled; 140 bytes otherwise.

   Note that, after the DTLS handshake has completed, any fragmentation
   and reassembly logic that pertains the application layer (e.g.,
   segmenting CoAP messages into DTLS records and reassembling them
   after the crypto operations have been successfully performed) needs
   to be handled by the application that uses the established DTLS

A.3.  Multiplexing Security Associations

   Unlike IPsec Encapsulating Security Payload (ESP) / Authentication
   Header (AH), DTLS records do not contain any association identifiers.
   Applications must arrange to multiplex between associations on the
   same endpoint which, when using UDP/IP, is usually done with the
   host/port number.

   If the DTLS server allows more than one client to be active at any
   given time, then the Wireless Application Protocol (WAP) User
   Datagram Protocol [WAP-WDP] can be used to achieve multiplexing of
   the different security associations.  (The use of WDP provides the
   additional benefit that upper-layer protocols can operate
   independently of the underlying wireless network, hence achieving
   application-agnostic transport handover.)
Top   ToC   Page 58
   The total overhead cost for encoding the WDP source and destination
   ports is either 5 or 7 bytes out of the total available for the SMS
   content depending on if 1-byte or 2-byte port identifiers are used,
   as shown in Figures 13 and 14.

   0        1        2        3        4
   | ...    | 0x04   | 2      | ...    | ...    |
     UDH      IEI      IE       Dest     Source
     Length            Length   Port     Port

   UDH = user data header
   IEI = information element identifier

       Figure 13: Application Port Addressing Scheme (8-Bit Address)

   0        1        2        3        4        5        6
   | ...    | 0x05   | 4      |       ...       |       ...       |
     UDH      IEI      IE       Dest              Source
     Length            Length   Port              Port

      Figure 14: Application Port Addressing Scheme (16-Bit Address)

   The receiving side of the communication gets the source address from
   the originator address (TP-OA) field of the SMS-DELIVER TPDU.  This
   way, a unique 4-tuple identifying the security association can be
   reconstructed at both ends.  (When replying to its DTLS peer, the
   sender will swap the TP-OA and destination address (TP-DA) parameters
   and the source and destination ports in the WDP.)

A.4.  Timeout

   If SMS-STATUS-REPORT messages are enabled, their receipt is not to be
   interpreted as the signal that the specific handshake message has
   been acted upon by the receiving party.  Therefore, it MUST NOT be
   taken into account by the DTLS timeout and retransmission function.

   Handshake messages MUST carry a validity period (TP-VP parameter in a
   SMS-SUBMIT TPDU) that is not less than the current value of the
   retransmission timeout.  In order to avoid persisting messages in the
   network that will be discarded by the receiving party, handshake
   messages SHOULD carry a validity period that is the same as, or just
   slightly higher than, the current value of the retransmission
Top   ToC   Page 59
Appendix B.  DTLS Record Layer Per-Packet Overhead

   Figure 15 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 15: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead

   The DTLS record layer header has 13 octets and consists of:

   o  1-octet content type field,

   o  2-octet version field,

   o  2-octet epoch field,

   o  6-octet sequence number, and

   o  2-octet length field.

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

      The salt is the "implicit" part and is not sent in the packet.
      Instead, the salt is generated as part of the handshake process.

      The nonce_explicit value is 8 octets long and it is chosen by the
      sender and carried in each TLS record.  RFC 6655 [RFC6655] allows
      the nonce_explicit to be a sequence number or something else.
      This document makes this use more restrictive for use with DTLS:
      the 64-bit none_explicit value MUST be the 16-bit epoch
      concatenated with the 48-bit seq_num.  The sequence number
      component of the nonce_explicit field at the AES-CCM layer is an
      exact copy of the sequence number in the record layer header
      field.  This leads to a duplication of 8-bytes per record.

      To avoid this 8-byte duplication, RFC 7400 [RFC7400] 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
Top   ToC   Page 60
      is exchanged over transports that do not use IPv6 or 6LoWPAN, such
      as the SMS transport described in Appendix A of this document.

Appendix C.  DTLS Fragmentation

   Section 4.2.3 of [RFC6347] advises DTLS implementations to not
   produce overlapping fragments.  However, it requires receivers to be
   able to cope with them.  The need for the latter requisite is
   explained in Section of [RFC6347]: accurate PMTU estimation
   may be traded for shorter handshake completion time.

   In many cases, the cost of handling fragment overlaps has proved to
   be unaffordable for constrained implementations, particularly because
   of the increased complexity in buffer management.

   In order to reduce the likelihood of producing different fragment
   sizes and consequent overlaps within the same handshake, this
   document RECOMMENDs:

   o  clients (handshake initiators) to use reliable PMTU information
      for the intended destination; and

   o  servers to mirror the fragment size selected by their clients.

   The PMTU information comes from either a "fresh enough" discovery
   performed by the client [RFC1981] [RFC4821] or some other reliable
   out-of-band channel.


   Thanks to Derek Atkins, Paul Bakker, Olaf Bergmann, Carsten Bormann,
   Ben Campbell, Brian Carpenter, Robert Cragie, Spencer Dawkins, Russ
   Housley, Rene Hummen, Jayaraghavendran K, Sye Loong Keoh, Matthias
   Kovatsch, Sandeep Kumar, Barry Leiba, Simon Lemay, Alexey Melnikov,
   Gabriel Montenegro, Manuel Pegourie-Gonnard, Akbar Rahman, Eric
   Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael
   StJohns, Rene Struik, Tina Tsou, and Sean Turner for their helpful
   comments and discussions that have shaped the document.

   A big thanks also to Klaus Hartke, who wrote the initial draft
   version of this document.

   Finally, we would like to thank our area director (Stephen Farrell)
   and our working group chairs (Zach Shelby and Dorothy Gellert) for
   their support.
Top   ToC   Page 61
Authors' Addresses

   Hannes Tschofenig (editor)
   ARM Ltd.
   110 Fulbourn Rd
   Cambridge  CB1 9NJ
   United Kingdom


   Thomas Fossati
   3 Ely Road
   Milton, Cambridge  CB24 6DD
   United Kingdom