idnits 2.17.1 draft-tschofenig-uta-tls13-profile-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 05, 2018) is 2242 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-26 == Outdated reference: A later version (-03) exists of draft-ietf-tls-record-limit-02 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 == Outdated reference: A later version (-04) exists of draft-ietf-httpbis-replay-02 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UTA H. Tschofenig 3 Internet-Draft Arm Limited 4 Intended status: Informational T. Fossati 5 Expires: September 6, 2018 Nokia 6 March 05, 2018 8 TLS/DTLS 1.3 Profiles for the Internet of Things 9 draft-tschofenig-uta-tls13-profile-00 11 Abstract 13 This document is a companion to RFC 7925 and defines TLS/DTLS 1.3 14 profiles for Internet of Things devices. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 6, 2018. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 64 3. Credential Types . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 3 66 5. Session Resumption . . . . . . . . . . . . . . . . . . . . . 4 67 6. Compression . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 7. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . . 4 69 8. Keep-Alive . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 9. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 10. Random Number Generation . . . . . . . . . . . . . . . . . . 4 72 11. Server Name Indication (SNI) . . . . . . . . . . . . . . . . 4 73 12. Maximum Fragment Length Negotiation . . . . . . . . . . . . . 4 74 13. Crypto Agility . . . . . . . . . . . . . . . . . . . . . . . 5 75 14. Key Length Recommendations . . . . . . . . . . . . . . . . . 5 76 15. 0-RTT Data . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 16. Security Considerations . . . . . . . . . . . . . . . . . . . 5 78 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 17.1. Normative References . . . . . . . . . . . . . . . . . . 5 80 17.2. Informative References . . . . . . . . . . . . . . . . . 6 81 Appendix A. The Timestamp Option . . . . . . . . . . . . . . . . 7 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 84 1. Introduction 86 This document defines a profile of DTLS 1.3 [I-D.ietf-tls-dtls13] and 87 TLS 1.3 [I-D.ietf-tls-tls13] that offers communication security 88 services for IoT applications and is reasonably implementable on many 89 constrained devices. Profile thereby means that available 90 configuration options and protocol extensions are utilized to best 91 support the IoT environment. 93 For IoT profiles using TLS/DTLS 1.2 please consult [RFC7925]. This 94 document re-uses the communication pattern defined in RFC 7925 and 95 makes IoT-domain specific recommendations for version 1.3 (where 96 necessary). 98 TLS 1.3 has been re-designed and several previously defined 99 extensions are not applicable to the new version of TLS/DTLS anymore. 100 This clean-up also simplifies this document. Furthermore, many 101 outdated ciphersuites have been omitted from the TLS/DTLS 1.3 102 specification. 104 2. Conventions and Terminology 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in RFC 109 2119 [RFC2119]. 111 3. Credential Types 113 In accordance with the recommendations in [RFC7925] a compliant 114 implementation MUST implement TLS_AES_128_CCM_8_SHA256. It SHOULD 115 implement TLS_CHACHA20_POLY1305_SHA256. 117 For use of a pre-shared secrets for authentication is now integrated 118 into the main specification and does not rely on extensions, as it 119 was the case with earlier versions. The support has also been 120 aligned with the session resumption feature. 122 A compliant implementation supporting authentication based on 123 certificates and raw public keys MUST support digital signatures with 124 ecdsa_secp256r1_sha256. A compliant implementation MUST support the 125 key exchange with secp256r1 (NIST P-256) and SHOULD support key 126 exchange with X25519. 128 A plain PSK-based TLS/DTLS client or server MUST implement the 129 following extensions: - supported_versions - cookie - server_name - 130 pre_shared_key - psk_key_exchange_modes 132 For TLS/DTLS clients and servers implementing raw public keys and/or 133 certificates the guidance for mandatory-to-implement extensions 134 described in Section 9.2 of [I-D.ietf-tls-tls13] MUST be followed. 136 4. Error Handling 138 TLS 1.3 simplified the Alert protocol but the underlying challenge in 139 an embedded context remains unchanged, namely what should an IoT 140 device do when it encounters an error situation. The classical 141 approach used in a desktop environment where the user is prompted is 142 often not applicable with unattended devices. Hence, it is more 143 important for a developer to find out from situation situation the 144 device can recover from and what situations are hopeless. 146 5. Session Resumption 148 TLS 1.3 has built-in support for session resumption by utilizing PSK- 149 based credentials established in an earlier exchange. 151 6. Compression 153 TLS 1.3 does not have support for compression. 155 7. Perfect Forward Secrecy 157 TLS 1.3 allows the use of PFS with all ciphersuites since the support 158 for it is negotiated independently. 160 8. Keep-Alive 162 The discussion in Section 10 of RFC 7925 is applicable. 164 9. Timeouts 166 The recommendation in Section 11 of RFC 7925 is applicable. In 167 particular this document RECOMMENDED to use an initial timer value of 168 9 seconds with exponential back off up to no less then 60 seconds. 170 10. Random Number Generation 172 The discussion in Section 12 of RFC 7925 is applicable with one 173 exception: the ClientHello and the ServerHello messages in TLS 1.3 do 174 not contain gmt_unix_time component anymore. 176 11. Server Name Indication (SNI) 178 This specification mandates the implementation of the SNI extension. 180 12. Maximum Fragment Length Negotiation 182 The Maximum Fragment Length Negotiation (MFL) extension has been 183 superseded by the Record Size Limit (RSL) extension 184 [I-D.ietf-tls-record-limit]. Implementations in compliance with this 185 specification MUST implement the RSL extension and SHOULD use it to 186 indicate their RAM limitations. 188 13. Crypto Agility 190 The recommendations in Section 19 of RFC 7925 are applicable. 192 14. Key Length Recommendations 194 The recommendations in Section 20 of RFC 7925 are applicable. 196 15. 0-RTT Data 198 When clients and servers share a PSK, TLS/DTLS 1.3 allows clients to 199 send data on the first flight ("early data"). This is a great 200 performance improvement but requires application protocols to define 201 its use with the 0-RTT data functionality. 203 For HTTP this functionality is described in 204 [I-D.ietf-httpbis-replay]. This document specifies the application 205 profile for CoAP. 207 For a given request, the level of tolerance to replay risk is 208 specific to the resource it operates upon (and therefore only known 209 to the origin server). In general, if processing a request does not 210 have state-changing side effects, the consequences of replay are not 211 significant. The server can choose whether it will process early 212 data before the TLS handshake completes. 214 It is RECOMMENDED that origin servers allow resources to explicitly 215 configure whether early data is appropriate in requests. 217 This specification defines a new CoAP option "timestamp", which 218 allows the server to attach a timestamp to each CoAP message for the 219 purpose of replay detection. 221 16. Security Considerations 223 This entire document is about security. 225 17. References 227 17.1. Normative References 229 [I-D.ietf-tls-dtls13] 230 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 231 Datagram Transport Layer Security (DTLS) Protocol Version 232 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 233 2018. 235 [I-D.ietf-tls-record-limit] 236 Thomson, M., "Record Size Limit Extension for Transport 237 Layer Security (TLS)", draft-ietf-tls-record-limit-02 238 (work in progress), February 2018. 240 [I-D.ietf-tls-tls13] 241 Rescorla, E., "The Transport Layer Security (TLS) Protocol 242 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 243 March 2018. 245 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 246 Requirement Levels", BCP 14, RFC 2119, 247 DOI 10.17487/RFC2119, March 1997, . 250 17.2. Informative References 252 [I-D.ietf-httpbis-replay] 253 Thomson, M., Nottingham, M., and W. Tarreau, "Using Early 254 Data in HTTP", draft-ietf-httpbis-replay-02 (work in 255 progress), November 2017. 257 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 258 Security (TLS) / Datagram Transport Layer Security (DTLS) 259 Profiles for the Internet of Things", RFC 7925, 260 DOI 10.17487/RFC7925, July 2016, . 263 Appendix A. The Timestamp Option 265 The Timestamp option encodes time in standard UNIX 32-bit format 266 (seconds since the midnight starting Jan 1, 1970, UTC, ignoring leap 267 seconds) according to the sender's internal clock. 269 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 270 | No. | C | U | N | R | Name | Format | Length | Default | E | 271 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 272 | TBD | | | | | Timestamp | opaque | 4 | (none) | x | 273 +-----+---+---+---+---+-------------+--------+--------+---------+---+ 275 C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable, 276 E=Encrypt and Integrity Protect (when using OSCORE) 278 Figure 1: Timestamp Option. 280 Authors' Addresses 282 Hannes Tschofenig 283 Arm Limited 285 EMail: hannes.tschofenig@gmx.net 287 Thomas Fossati 288 Nokia 290 EMail: thomas.fossati@nokia.com