RFC 7925
Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things
Pages: 61
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 42 to 61
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 handshake. 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 [RFC7568]). 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.
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.
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
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.
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 [LWM2M].
24. References
24.1. Normative References
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", Registration Authority, <https://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>. [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, <http://www.rfc-editor.org/info/rfc2119>. [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, <http://www.rfc-editor.org/info/rfc4279>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [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, <http://www.rfc-editor.org/info/rfc5746>. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>. [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, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>. [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, <http://www.rfc-editor.org/info/rfc6520>. [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, <http://www.rfc-editor.org/info/rfc7250>. [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, <http://www.rfc-editor.org/info/rfc7251>. [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, <http://www.rfc-editor.org/info/rfc7627>. [RFC7924] Santesson, S. and H. Tschofenig, "Transport Layer Security (TLS) Cached Information Extension", RFC 7924, DOI 10.17487/RFC7924, July 2016, <http://www.rfc-editor.org/info/rfc7924>. [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", <https://datatracker.ietf.org/wg/ace/charter>. [AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", NIST FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
[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, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C_updated-July20_2007.pdf>. [COAP-TCP-TLS] 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, <https://en.wikipedia.org/w/ index.php?title=CRIME&oldid=721665716>. [ENISA-Report2013] ENISA, "Algorithms, Key Sizes and Parameters Report - 2013", October 2013, <https://www.enisa.europa.eu/ activities/identity-and-trust/library/deliverables/ algorithms-key-sizes-and-parameters-report>. [FFDHE-TLS] Gillmor, D., "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS", Work in Progress, draft-ietf-tls-negotiated-ff-dhe-10, June 2015. [HomeGateway] 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, <http://conferences.sigcomm.org/imc/2010/papers/p260.pdf>. [IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters", <https://www.iana.org/assignments/tls-parameters>.
[ImprintingSurvey] Chilton, E., "A Brief Survey of Imprinting Options for Constrained Devices", March 2012, <http://www.lix.polytechnique.fr/hipercom/ SmartObjectSecurity/papers/EricRescorla.pdf>. [Keylength] Giry, D., "Cryptographic Key Length Recommendations", September 2015, <http://www.keylength.com>. [LWM2M] Open Mobile Alliance, "Lightweight Machine-to-Machine Requirements", Candidate Version 1.0, OMA-RD- LightweightM2M-V1_0-20131210-C, December 2013, <http://openmobilealliance.org/about-oma/work-program/ m2m-enablers>. [PSK-AES-CCM-TLS] 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, <http://www.rfc-editor.org/info/rfc1981>. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, <http://www.rfc-editor.org/info/rfc2104>. [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, <http://www.rfc-editor.org/info/rfc2865>. [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <http://www.rfc-editor.org/info/rfc3610>. [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, <http://www.rfc-editor.org/info/rfc3748>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>. [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, <http://www.rfc-editor.org/info/rfc4492>. [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>. [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, <http://www.rfc-editor.org/info/rfc4919>. [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, <http://www.rfc-editor.org/info/rfc5077>. [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <http://www.rfc-editor.org/info/rfc5116>. [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, March 2008, <http://www.rfc-editor.org/info/rfc5216>. [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <http://www.rfc-editor.org/info/rfc5247>. [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, <http://www.rfc-editor.org/info/rfc5280>.
[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, <http://www.rfc-editor.org/info/rfc5288>. [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, <http://www.rfc-editor.org/info/rfc5480>. [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, <http://www.rfc-editor.org/info/rfc5758>. [RFC5934] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor Management Protocol (TAMP)", RFC 5934, DOI 10.17487/RFC5934, August 2010, <http://www.rfc-editor.org/info/rfc5934>. [RFC6024] Reddy, R. and C. Wallace, "Trust Anchor Management Requirements", RFC 6024, DOI 10.17487/RFC6024, October 2010, <http://www.rfc-editor.org/info/rfc6024>. [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, DOI 10.17487/RFC6090, February 2011, <http://www.rfc-editor.org/info/rfc6090>. [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, <http://www.rfc-editor.org/info/rfc6234>. [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for Transport Layer Security (TLS)", RFC 6655, DOI 10.17487/RFC6655, July 2012, <http://www.rfc-editor.org/info/rfc6655>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>. [RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 2013, <http://www.rfc-editor.org/info/rfc6943>. [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension", RFC 6961, DOI 10.17487/RFC6961, June 2013, <http://www.rfc-editor.org/info/rfc6961>. [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>. [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>. [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, <http://www.rfc-editor.org/info/rfc7366>. [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <http://www.rfc-editor.org/info/rfc7390>. [RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart Object Security Workshop", RFC 7397, DOI 10.17487/RFC7397, December 2014, <http://www.rfc-editor.org/info/rfc7397>. [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, <http://www.rfc-editor.org/info/rfc7400>. [RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, "Architectural Considerations in Smart Object Networking", RFC 7452, DOI 10.17487/RFC7452, March 2015, <http://www.rfc-editor.org/info/rfc7452>.
[RFC7465] Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465, DOI 10.17487/RFC7465, February 2015, <http://www.rfc-editor.org/info/rfc7465>. [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, <http://www.rfc-editor.org/info/rfc7507>. [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, <http://www.rfc-editor.org/info/rfc7525>. [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, <http://www.rfc-editor.org/info/rfc7539>. [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, <http://www.rfc-editor.org/info/rfc7568>. [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>. [SP800-107-rev1] 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, <http://csrc.nist.gov/publications/nistpubs/800-107-rev1/ sp800-107-rev1.pdf>. [SP800-22b] 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, <http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/ SP800-22rev1a.pdf>.
[SP800-90A] 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, <http://csrc.nist.gov/publications/drafts/800-90/ sp800-90a_r1_draft_november2014_ver.pdf>. [TLS-FALSESTART] Langley, A., Modadugu, N., and B. Moeller, "Transport Layer Security (TLS) False Start", Work in Progress, draft-ietf-tls-falsestart-02, May 2016. [Triple-HS] 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.
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 9.2.3.24.1 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.
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 tunnel.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.)
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 Legend: 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 timeout.
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
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 4.1.1.1 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.
Acknowledgments
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.
Authors' Addresses
Hannes Tschofenig (editor) ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ United Kingdom Email: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at Thomas Fossati Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom Email: thomas.fossati@nokia.com