idnits 2.17.1 draft-ietf-opsawg-mud-tls-03.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 : ---------------------------------------------------------------------------- ** There are 30 instances of too long lines in the document, the longest one being 30 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 419 has weird spacing: '... cipher ian...' -- The document date (November 1, 2020) is 1270 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '10' on line 1071 -- Looks like a reference, but probably isn't: '11' on line 1071 -- Looks like a reference, but probably isn't: '13' on line 1071 -- Looks like a reference, but probably isn't: '16' on line 1071 -- Looks like a reference, but probably isn't: '24' on line 1071 -- Looks like a reference, but probably isn't: '29' on line 1072 == Missing Reference: 'RFCXXXX' is mentioned on line 1239, but not defined == Missing Reference: 'RFC5246' is mentioned on line 1256, but not defined ** Obsolete undefined reference: RFC 5246 (Obsoleted by RFC 8446) == Missing Reference: 'RFC6346' is mentioned on line 1273, but not defined == Unused Reference: 'RFC6991' is defined on line 1368, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-18 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-38 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Downref: Normative reference to an Informational RFC: RFC 8701 -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-08 == Outdated reference: A later version (-09) exists of draft-ietf-uta-tls13-iot-profile-00 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: May 5, 2021 Citrix 6 B. Anderson 7 Cisco 8 November 1, 2020 10 Manufacturer Usage Description (MUD) (D)TLS Profiles for IoT Devices 11 draft-ietf-opsawg-mud-tls-03 13 Abstract 15 This memo extends the Manufacturer Usage Description (MUD) 16 specification to incorporate (D)TLS profile parameters. This allows 17 a network security service to identify unexpected (D)TLS usage, which 18 can indicate the presence of unauthorized software or malware on an 19 endpoint. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 5, 2021. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 5 58 4. (D)TLS 1.3 Handshake . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Full (D)TLS 1.3 Handshake Inspection . . . . . . . . . . 6 60 4.2. Encrypted DNS . . . . . . . . . . . . . . . . . . . . . . 7 61 5. (D)TLS Profile of a IoT device . . . . . . . . . . . . . . . 7 62 5.1. Tree Structure of the (D)TLS profile Extension to the ACL 63 YANG Model . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2. The (D)TLS profile Extension to the ACL YANG Model . . . 10 65 5.3. IANA (D)TLS profile YANG Module . . . . . . . . . . . . . 15 66 5.4. MUD (D)TLS Profile Extension . . . . . . . . . . . . . . 20 67 6. Processing of the MUD (D)TLS Profile . . . . . . . . . . . . 21 68 7. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 22 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 70 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 72 10.1. (D)TLS Profile YANG Modules . . . . . . . . . . . . . . 25 73 10.2. TLS Version registry . . . . . . . . . . . . . . . . . . 27 74 10.3. DTLS version registry . . . . . . . . . . . . . . . . . 27 75 10.4. (D)TLS Parameters registry . . . . . . . . . . . . . . . 28 76 10.5. MUD Extensions registry . . . . . . . . . . . . . . . . 29 77 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 80 12.2. Informative References . . . . . . . . . . . . . . . . . 31 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 83 1. Introduction 85 Encryption is necessary to enhance the privacy of end users using IoT 86 devices. TLS [RFC8446] and DTLS [I-D.ietf-tls-dtls13] are the 87 dominant protocols (counting all (D)TLS versions) providing 88 encryption for IoT device traffic. Unfortunately, in conjunction 89 with IoT applications' rise of encryption, malware authors are also 90 using encryption which thwarts network-based analysis such as deep 91 packet inspection (DPI). Other mechanisms are thus needed to help 92 detecting malware running on an IoT device. 94 Malware frequently uses proprietary libraries for its activities, and 95 those libraries are reused much like any other software engineering 96 project. [malware] indicates that there are observable differences in 97 how malware uses encryption compared with how non-malware uses 98 encryption. There are several interesting findings specific to 99 (D)TLS which were found common to malware: 101 o Older and weaker cryptographic parameters (e.g., 102 TLS_RSA_WITH_RC4_128_SHA). 104 o TLS server name indication (SNI) extension [RFC6066] and server 105 certificates are composed of subjects with characteristics of a 106 domain generation algorithm (DGA) (e.g., 'www.33mhwt2j.net'). 108 o Higher use of self-signed certificates compared with typical 109 legitimate software. 111 o Discrepancies in the SNI TLS extension and the DNS names in the 112 SubjectAltName (SAN) X.509 extension in the server certificate 113 message. 115 o Discrepancies in the key exchange algorithm and the client public 116 key length in comparison with legitimate flows. As a reminder, 117 the Client Key Exchange message has been removed from TLS 1.3. 119 o Lower diversity in TLS client advertised extensions compared to 120 legitimate clients. 122 o Using privacy enhancing technologies like Tor, Psiphon, Ultrasurf 123 (see [malware-tls]), and evasion techniques such as ClientHello 124 randomization. 126 o Using DNS-over-HTTPS (DoH) [RFC8484] to avoid detection by malware 127 DNS filtering services [malware-doh]. Specifically, malware may 128 not use the DoH server provided by the local network. 130 If observable (D)TLS profile parameters are used, the following 131 functions are possible which have a positive impact on the local 132 network security: 134 o Permit intended DTLS or TLS use and block malicious DTLS or TLS 135 use. This is superior to the layers 3 and 4 ACLs of Manufacturer 136 Usage Description Specification (MUD) [RFC8520] which are not 137 suitable for broad communication patterns. 139 o Ensure TLS certificates are valid. Several TLS deployments have 140 been vulnerable to active Man-In-The-Middle (MITM) attacks because 141 of the lack of certificate validation or vulnerability in the 142 certificate validation function (see [cryto-vulnerability]). By 143 observing (D)TLS profile parameters, a network element can detect 144 when the TLS SNI mismatches the SubjectAltName and when the 145 server's certificate is invalid. In TLS 1.2, the ClientHello, 146 ServerHello and Certificate messages are all sent in clear-text. 147 This check is not possible with TLS 1.3, which encrypts the 148 Certificate message thereby hiding the server identity from any 149 intermediary. In TLS 1.3, the server certificate validation 150 functions should be executed within an on-path TLS proxy, if such 151 a proxy exists. 153 o Support new communication patterns. An IoT device can learn a new 154 capability, and the new capability can change the way the IoT 155 device communicates with other devices located in the local 156 network and Internet. There would be an inaccurate policy if an 157 IoT device rapidly changes the IP addresses and domain names it 158 communicates with while the MUD ACLs were slower to update (see 159 [clear-as-mud]). In such a case, observable (D)TLS profile 160 parameters can be used to permit intended use and to block 161 malicious behavior from the IoT device. 163 The YANG module specified in Section 5 of this document is an 164 extension of YANG Data Model for Network Access Control Lists (ACLs) 165 [RFC8519] to enhance MUD [RFC8520] to model observable (D)TLS profile 166 parameters. Using these (D)TLS profile parameters, an active MUD- 167 enforcing network security service (e.g., firewall) can identify MUD 168 non-compliant (D)TLS behavior indicating outdated cryptography or 169 malware. This detection can prevent malware downloads, block access 170 to malicious domains, enforce use of strong ciphers, stop data 171 exfiltration, etc. In addition, organizations may have policies 172 around acceptable ciphers and certificates for the websites the IoT 173 devices connect to. Examples include no use of old and less secure 174 versions of TLS, no use of self-signed certificates, deny-list or 175 accept-list of Certificate Authorities, valid certificate expiration 176 time, etc. These policies can be enforced by observing the (D)TLS 177 profile parameters. Network security services can use the IoT 178 device's (D)TLS profile parameters to identify legitimate flows by 179 observing (D)TLS sessions, and can make inferences to permit 180 legitimate flows and to block malicious or insecure flows. The 181 proposed technique is also suitable in deployments where decryption 182 techniques are not ideal due to privacy concerns, non-cooperating 183 end-points, and expense. 185 2. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119][RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 "(D)TLS" is used for statements that apply to both Transport Layer 194 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 195 Specific terms are used for any statement that applies to either 196 protocol alone. 198 'DoH/DoT' refers to DNS-over-HTTPS and/or DNS-over-TLS. 200 3. Overview of MUD (D)TLS profiles for IoT devices 202 In Enterprise networks, protection and detection are typically done 203 both on end hosts and in the network. Host security agents have deep 204 visibility on the devices where they are installed, whereas the 205 network has broader visibility. Installing host security agents may 206 not be a viable option on IoT devices, and network-based security is 207 an efficient means to protect such IoT devices. If the IoT device 208 supports a MUD (D)TLS profile, the (D)TLS profile parameters of the 209 IoT device can be used by a middlebox to detect and block malware 210 communication, while at the same time preserving the privacy of 211 legitimate uses of encryption. The middlebox need not proxy (D)TLS 212 but can passively observe the parameters of (D)TLS handshakes from 213 IoT devices and gain visibility into TLS 1.2 parameters and partial 214 visibility into TLS 1.3 parameters. 216 Malicious agents can try to use the (D)TLS profile parameters of 217 legitimate agents to evade detection, but it becomes a challenge to 218 mimic the behavior of various IoT device types and IoT device models 219 from several manufacturers. In other words, malware developers will 220 have to develop malicious agents per IoT device type, manufacturer 221 and model, infect the device with the tailored malware agent and will 222 have keep up with updates to the device's (D)TLS profile parameters 223 over time. Furthermore, the malware's command and control server 224 certificates need to be signed by the same certifying authorities 225 trusted by the IoT devices. Typically, IoT devices have an 226 infrastructure that supports a rapid deployment of updates, and 227 malware agents will have a near-impossible task of similarly 228 deploying updates and continuing to mimic the TLS behavior of the IoT 229 device it has infected. However, if the IoT device has reached end- 230 of-life and the IoT manufacturer will not issue a firmware or 231 software update to the Thing or will not update the MUD file, the 232 "is-supported" attribute defined in Section 3.6 of [RFC8520] can be 233 used by the MUD manager to identify the IoT manufacturer no longer 234 supports the device. 236 The end-of-life of a device does not necessarily mean that it is 237 defective; rather, it denotes a need to replace and upgrade the 238 network to next-generation devices for additional functionality. The 239 network security service will have to rely on other techniques 240 discussed in Section 8 to identify malicious connections until the 241 device is replaced. 243 Compromised IoT devices are typically used for launching DDoS attacks 244 (Section 3 of [RFC8576]). For example, DDoS attacks like Slowloris 245 and Transport Layer Security (TLS) re-negotiation can be blocked if 246 the victim's server certificate is not be signed by the same 247 certifying authorities trusted by the IoT device. 249 4. (D)TLS 1.3 Handshake 251 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 252 all (D)TLS handshake messages excluding the ClientHello message are 253 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 254 record layers called Encrypted Extensions. Using these extensions 255 handshake messages will be encrypted and network security services 256 (such as a firewall) are incapable to decipher the handshake, and 257 thus cannot view the server certificate. However, the ClientHello 258 and ServerHello still have some fields visible, such as the list of 259 supported versions, named groups, cipher suites, signature algorithms 260 and extensions in ClientHello, and chosen cipher in the ServerHello. 261 For instance, if the malware uses evasion techniques like ClientHello 262 randomization, the observable list of cipher suites and extensions 263 offered by the malware agent in the ClientHello message will not 264 match the list of cipher suites and extensions offered by the 265 legitimate client in the ClientHello message, and the middlebox can 266 block malicious flows without acting as a (D)TLS 1.3 proxy. 268 4.1. Full (D)TLS 1.3 Handshake Inspection 270 To obtain more visibility into negotiated TLS 1.3 parameters, a 271 middlebox can act as a (D)TLS 1.3 proxy. A middlebox can act as a 272 (D)TLS proxy for the IoT devices owned and managed by the IT team in 273 the Enterprise network and the (D)TLS proxy must meet the security 274 and privacy requirements of the organization. In other words, the 275 scope of middlebox acting as a (D)TLS proxy is restricted to 276 Enterprise network owning and managing the IoT devices. The 277 middlebox would have to follow the behaviour detailed in Section 9.3 278 of [RFC8446] to act as a compliant (D)TLS 1.3 proxy. 280 To further increase privacy, Encrypted Client Hello (ECH) extension 281 [I-D.ietf-tls-esni] prevents passive observation of the TLS Server 282 Name Indication extension and other potentially sensitive fields, 283 such as the ALPN [RFC7301]. To effectively provide that privacy 284 protection, ECH extension needs to be used in conjunction with DNS 285 encryption (e.g., DoH). A middlebox (e.g., firewall) passively 286 inspecting ECH extension cannot observe the encrypted SNI nor observe 287 the encrypted DNS traffic. 289 4.2. Encrypted DNS 291 A common usage pattern for certain type of IoT devices (e.g., light 292 bulb) is for it to "call home" to a service that resides on the 293 public Internet, where that service is referenced through a domain 294 name (A or AAAA record). As discussed in Manufacturer Usage 295 Description Specification [RFC8520], because these devices tend to 296 require access to very few sites, all other access should be 297 considered suspect. If an IoT device is pre-configured to use a 298 public DoH/DoT server, the MUD policy enforcement point is moved to 299 that public server, which cannot enforce the MUD policy based on 300 domain names (Section 8 of [RFC8520]). If the DNS query is not 301 accessible for inspection, it becomes quite difficult for the 302 infrastructure to suspect anything. Thus the use of a public DoH/DoT 303 server is incompatible with MUD in general. A local DoH/DoT server 304 is necessary to allow MUD policy enforcement on the local network 305 [I-D.reddy-add-enterprise]. 307 5. (D)TLS Profile of a IoT device 309 This document specifies a YANG module for representing (D)TLS 310 profile. The (D)TLS profile YANG module provides a method for 311 network security services to observe the (D)TLS profile parameters in 312 the (D)TLS handshake to permit intended use and to block malicious 313 behavior. This module uses the cryptographic types defined in 314 [I-D.ietf-netconf-crypto-types]. See [RFC7925] for (D)TLS 1.2 and 315 [I-D.ietf-uta-tls13-iot-profile] for DTLS 1.3 recommendations related 316 to IoT devices, and [RFC7525] for additional (D)TLS 1.2 317 recommendations. 319 A companion YANG module is defined to include a collection of (D)TLS 320 parameters and (D)TLS versions maintained by IANA: "iana-tls-profile" 321 (Section 5.3). 323 The (D)TLS parameters in each (D)TLS profile include the following: 325 o Profile name 327 o (D)TLS versions supported by the IoT device. 329 o List of supported cipher suites. For (D)TLS1.2, [RFC7925] 330 recommends AEAD ciphers for IoT devices. 332 o List of supported extension types 334 o List of trust anchor certificates used by the IoT device. If the 335 server certificate is signed by one of the trust anchors, the 336 middlebox continues with the connection as normal. Otherwise, the 337 middlebox will react as if the server certificate validation has 338 failed and takes appropriate action (e.g, block the (D)TLS 339 session). An IoT device can use a private trust anchor to 340 validate a server's certificate (e.g., the private trust anchor 341 can be preloaded at manufacturing time on the IoT device and the 342 IoT device fetches the firmware image from the Firmware server 343 whose certificate is signed by the private CA). This empowers the 344 middlebox to reject TLS sessions to servers that the IoT device 345 does not trust. 347 o List of SPKI pin set pre-configured on the client to validate 348 self-signed server certificates or raw public keys. A SPKI pin 349 set is a cryptographic digest to "pin" public key information in a 350 manner similar to HTTP Public Key Pinning (HPKP) [RFC7469]. If 351 SPKI pin set is present in the (D)TLS profile of a IoT device and 352 the server certificate does not pass the PKIX certification path 353 validation, the middlebox computes the SPKI Fingerprint for the 354 public key found in the server's certificate (or in the raw public 355 key, if the server provides that instead). If a computed 356 fingerprint exactly matches one of the SPKI pin sets in the (D)TLS 357 profile, the middlebox continues with the connection as normal. 358 Otherwise, the middlebox will act on the SPKI validation failure 359 and takes appropriate action. 361 o Cryptographic hash algorithm used to generate the SPKI pinsets 363 o List of pre-shared key exchange modes 365 o List of named groups (DHE or ECDHE) supported by the client 367 o List of signature algorithms the client can validate in X.509 368 server certificates 370 o List of signature algorithms the client is willing to accept for 371 CertificateVerify message (Section 4.2.3 of [RFC8446]). For 372 example, a TLS client implementation can support different sets of 373 algorithms for certificates and in TLS to signal the capabilities 374 in "signature_algorithms_cert" and "signature_algorithms" 375 extensions. 377 o List of supported application protocols (e.g., h3, h2, http/1.1 378 etc.) 380 o List of certificate compression algorithms (defined in 381 [I-D.ietf-tls-certificate-compression]) 383 o List of the distinguished names [X501] of acceptable certificate 384 authorities, represented in DER-encoded format [X690] (defined in 385 Section 4.2.4 of [RFC8446]) 387 GREASE [RFC8701] sends random values on TLS parameters to ensure 388 future extensibility of TLS extensions. Similar random values might 389 be extended to other TLS parameters. Thus, the (D)TLS profile 390 parameters defined in the YANG module by this document MUST NOT 391 include the GREASE values for extension types, named groups, 392 signature algorithms, (D)TLS versions, pre-shared key exchange modes, 393 cipher suites and for any other TLS parameters defined in future 394 RFCs. 396 The (D)TLS profile does not include parameters like compression 397 methods for data compression, [RFC7525] recommends disabling TLS- 398 level compression to prevent compression-related attacks. In TLS 399 1.3, only the "null" compression method is allowed (Section 4.1.2 of 400 [RFC8446]). 402 5.1. Tree Structure of the (D)TLS profile Extension to the ACL YANG 403 Model 405 This document augments the "ietf-acl" ACL YANG module defined in 406 [RFC8519] for signaling the IoT device (D)TLS profile. This document 407 defines the YANG module "ietf-acl-tls", which has the following tree 408 structure: 410 module: ietf-acl-tls 411 augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches: 412 +--rw client-profile {match-on-tls-dtls}? 413 +--rw client-profile 414 +--rw tls-dtls-profiles* [profile-name] 415 +--rw profile-name string 416 +--rw supported-tls-versions* ianatp:tls-version 417 +--rw supported-dtls-versions* ianatp:dtls-version 418 +--rw cipher-suites* [cipher hash] 419 | +--rw cipher ianatp:cipher-algorithm 420 | +--rw hash ianatp:hash-algorithm 421 +--rw extension-types* 422 | ianatp:extension-type 423 +--rw acceptlist-ta-certs* 424 | ct:trust-anchor-cert-cms 425 +--rw spki 426 | +--rw spki-pin-sets* ianatp:spki-pin-set 427 | +--rw spki-hash-algorithm? iha:hash-algorithm-type 428 +--rw psk-key-exchange-modes* 429 | ianatp:psk-key-exchange-mode 430 | {tls-1-3 or dtls-1-3}? 431 +--rw supported-groups* 432 | ianatp:supported-group 433 +--rw signature-algorithms-cert* 434 | ianatp:signature-algorithm 435 | {tls-1-3 or dtls-1-3}? 436 +--rw signature-algorithms* 437 | ianatp:signature-algorithm 438 +--rw application-protocols* 439 | ianatp:application-protocol 440 +--rw cert-compression-algorithms* 441 | ianatp:cert-compression-algorithm 442 | {tls-1-3 or dtls-1-3}? 443 +--rw certificate-authorities* 444 ianatp:certificate-authority 445 {tls-1-3 or dtls-1-3}? 447 5.2. The (D)TLS profile Extension to the ACL YANG Model 449 file "ietf-acl-tls@2020-10-07.yang" 450 module ietf-acl-tls { 451 yang-version 1.1; 452 namespace "urn:ietf:params:xml:ns:yang:ietf-acl-tls"; 453 prefix ietf-acl-tls; 455 import iana-tls-profile { 456 prefix ianatp; 457 reference 458 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 459 Profiles for IoT Devices"; 460 } 461 import ietf-crypto-types { 462 prefix ct; 463 reference 464 "RFC CCCC: Common YANG Data Types for Cryptography"; 465 } 466 import iana-hash-algs { 467 prefix iha; 468 reference 469 "RFC IIII: Common YANG Data Types for 470 Hash algorithms"; 471 } 472 import ietf-access-control-list { 473 prefix acl; 474 reference 475 "RFC 8519: YANG Data Model for Network Access 476 Control Lists (ACLs)"; 477 } 479 organization 480 "IETF OPSAWG (Operations and Management Area Working Group)"; 481 contact 482 "WG Web: 483 WG List: opsawg@ietf.org 485 Author: Konda, Tirumaleswar Reddy 486 TirumaleswarReddy_Konda@McAfee.com 487 "; 488 description 489 "This YANG module defines a component that augments the 490 IETF description of an access list to allow (D)TLS profile 491 as matching criteria. 493 Copyright (c) 2020 IETF Trust and the persons identified as 494 authors of the code. All rights reserved. 496 Redistribution and use in source and binary forms, with or 497 without modification, is permitted pursuant to, and subject 498 to the license terms contained in, the Simplified BSD License 499 set forth in Section 4.c of the IETF Trust's Legal Provisions 500 Relating to IETF Documents 501 (http://trustee.ietf.org/license-info). 503 This version of this YANG module is part of RFC XXXX; see 504 the RFC itself for full legal notices."; 506 revision 2020-11-02 { 507 description 508 "Initial revision"; 509 reference 510 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 511 Profiles for IoT Devices"; 512 } 514 feature tls-1-2 { 515 description 516 "TLS Protocol Version 1.2 is supported."; 517 reference 518 "RFC 5246: The Transport Layer Security (TLS) Protocol 519 Version 1.2"; 520 } 522 feature tls-1-3 { 523 description 524 "TLS Protocol Version 1.3 is supported."; 525 reference 526 "RFC 8446: The Transport Layer Security (TLS) Protocol 527 Version 1.3"; 528 } 530 feature dtls-1-2 { 531 description 532 "DTLS Protocol Version 1.2 is supported."; 533 reference 534 "RFC 6346: Datagram Transport Layer Security 535 Version 1.2"; 536 } 538 feature dtls-1-3 { 539 description 540 "DTLS Protocol Version 1.3 is supported."; 541 reference 542 "draft-ietf-tls-dtls13: Datagram Transport Layer 543 Security 1.3"; 544 } 546 feature match-on-tls-dtls { 547 description 548 "The networking device can support matching on 549 (D)TLS parameters."; 550 } 552 augment "/acl:acls/acl:acl/acl:aces/acl:ace/acl:matches" { 553 if-feature "match-on-tls-dtls"; 554 description 555 "(D)TLS specific matches."; 556 container client-profile { 557 description 558 "A grouping for (D)TLS profiles."; 559 container client-profile { 560 description 561 "A grouping for DTLS profiles."; 562 list tls-dtls-profiles { 563 key "profile-name"; 564 description 565 "A list of (D)TLS version profiles supported by 566 the client."; 567 leaf profile-name { 568 type string { 569 length "1..64"; 570 } 571 description 572 "The name of (D)TLS profile; space and special 573 characters are not allowed."; 574 } 575 leaf-list supported-tls-versions { 576 type ianatp:tls-version; 577 description 578 "TLS versions supported by the client."; 579 } 580 leaf-list supported-dtls-versions { 581 type ianatp:dtls-version; 582 description 583 "DTLS versions supported by the client."; 584 } 585 list cipher-suites { 586 key "cipher hash"; 587 leaf cipher { 588 type ianatp:cipher-algorithm; 589 description 590 "AEAD encryption algorithm as defined in RFC5116."; 591 } 592 leaf hash { 593 type ianatp:hash-algorithm; 594 description 595 "Hash algorithm used with HKDF as defined in RFC5869."; 596 } 597 description 598 "A list of Cipher Suites supported by the client."; 599 } 600 leaf-list extension-types { 601 type ianatp:extension-type; 602 description 603 "A list of Extension Types supported by the client."; 604 } 605 leaf-list acceptlist-ta-certs { 606 type ct:trust-anchor-cert-cms; 607 description 608 "A list of trust anchor certificates used by the client."; 609 } 610 container spki { 611 description 612 "A grouping for spki."; 613 leaf-list spki-pin-sets { 614 type ianatp:spki-pin-set; 615 description 616 "A list of SPKI pin sets pre-configured on the client 617 to validate self-signed server certificate or 618 raw public key."; 619 } 620 leaf spki-hash-algorithm { 621 type iha:hash-algorithm-type; 622 description 623 "cryptographic hash algorithm used to generate the 624 SPKI pinset."; 625 } 626 } 627 leaf-list psk-key-exchange-modes { 628 if-feature "tls-1-3 or dtls-1-3"; 629 type ianatp:psk-key-exchange-mode; 630 description 631 "pre-shared key exchange modes."; 632 } 633 leaf-list supported-groups { 634 type ianatp:supported-group; 635 description 636 "A list of named groups supported by the client."; 637 } 638 leaf-list signature-algorithms-cert { 639 if-feature "tls-1-3 or dtls-1-3"; 640 type ianatp:signature-algorithm; 641 description 642 "A list signature algorithms the client can validate 643 in X.509 certificates."; 644 } 645 leaf-list signature-algorithms { 646 type ianatp:signature-algorithm; 647 description 648 "A list signature algorithms the client can validate 649 in the CertificateVerify message."; 651 } 652 leaf-list application-protocols { 653 type ianatp:application-protocol; 654 description 655 "A list application protocols supported by the client."; 656 } 657 leaf-list cert-compression-algorithms { 658 if-feature "tls-1-3 or dtls-1-3"; 659 type ianatp:cert-compression-algorithm; 660 description 661 "A list certificate compression algorithms 662 supported by the client."; 663 } 664 leaf-list certificate-authorities { 665 if-feature "tls-1-3 or dtls-1-3"; 666 type ianatp:certificate-authority; 667 description 668 "A list of the distinguished names of certificate authorities 669 acceptable to the client."; 670 } 671 } 672 } 673 } 674 } 675 } 676 678 5.3. IANA (D)TLS profile YANG Module 680 The TLS and DTLS IANA registries are available from 681 682 and . 685 The values for all the parameters in the "iana-tls-profile" YANG 686 module are defined in the TLS and DTLS IANA registries excluding the 687 tls-version, dtls-version, spki-pin-set, and certificate-authority 688 parameters. The values of spki-pin-set and certificate-authority 689 parameters will be specific to the IoT device. 691 The TLS and DTLS IANA registries do not maintain (D)TLS version 692 numbers. In (D)TLS 1.2 and below, "legacy_version" field in the 693 ClientHello message is used for version negotiation. However in 694 (D)TLS 1.3, the "supported_versions" extension is used by the client 695 to indicate which versions of (D)TLS it supports. TLS 1.3 696 ClientHello messages are identified as having a "legacy_version" of 697 0x0303 and a "supported_versions" extension present with 0x0304 as 698 the highest version. DTLS 1.3 ClientHello messages are identified as 699 having a "legacy_version" of 0xfefd and a "supported_versions" 700 extension present with 0x0304 as the highest version. 702 In order to ease updating the "iana-tls-profile" YANG module with 703 future (D)TLS versions, new (D)TLS version registries are defined in 704 Section 10.2 and Section 10.3. Whenever a new (D)TLS protocol 705 version is defined, the registry will be updated using expert review; 706 the "iana-tls-profile" YANG module will be automatically updated by 707 IANA. 709 The "iana-tls-profile" YANG module is defined as follows: 711 file "iana-tls-profile@2020-10-07.yang" 713 module iana-tls-profile { 714 yang-version 1.1; 715 namespace "urn:ietf:params:xml:ns:yang:iana-tls-profile"; 716 prefix ianatp; 718 organization 719 "IANA"; 720 contact 721 " Internet Assigned Numbers Authority 723 Postal: ICANN 724 12025 Waterfront Drive, Suite 300 725 Los Angeles, CA 90094-2536 726 United States 728 Tel: +1 310 301 5800 729 E-Mail: iana@iana.org>"; 730 description 731 "This module contains YANG definition for the (D)TLS profile. 733 Copyright (c) 2020 IETF Trust and the persons identified as 734 authors of the code. All rights reserved. 736 Redistribution and use in source and binary forms, with or 737 without modification, is permitted pursuant to, and subject 738 to the license terms contained in, the Simplified BSD License 739 set forth in Section 4.c of the IETF Trust's Legal Provisions 740 Relating to IETF Documents 741 (http://trustee.ietf.org/license-info). 743 This version of this YANG module is part of RFC XXXX; see 744 the RFC itself for full legal notices."; 746 revision 2020-11-02 { 747 description 748 "Initial revision"; 749 reference 750 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS Profiles 751 for IoT Devices"; 752 } 754 typedef extension-type { 755 type uint16; 756 description 757 "Extension type in the TLS ExtensionType Values registry as 758 defined in Section 7 of RFC8447."; 759 } 761 typedef supported-group { 762 type uint16; 763 description 764 "Supported Group in the TLS Supported Groups registry as 765 defined in Section 9 of RFC8447."; 766 } 768 typedef spki-pin-set { 769 type binary; 770 description 771 "Subject Public Key Info pin set as discussed in 772 Section 2.4 of RFC7469."; 773 } 775 typedef signature-algorithm { 776 type uint16; 777 description 778 "Signature algorithm in the TLS SignatureScheme registry as 779 defined in Section 11 of RFC8446."; 780 } 782 typedef psk-key-exchange-mode { 783 type uint8; 784 description 785 "Pre-shared key exchange mode in the TLS PskKeyExchangeMode 786 registry as defined in Section 11 of RFC8446."; 787 } 789 typedef application-protocol { 790 type string; 791 description 792 "Application-Layer Protocol Negotiation (ALPN) Protocol ID 793 registry as defined in Section 6 of RFC7301."; 794 } 795 typedef cert-compression-algorithm { 796 type uint16; 797 description 798 "Certificate compression algorithm in TLS Certificate 799 Compression Algorithm IDs registry as defined in 800 Section 7.3 of ietf-tls-certificate-compression"; 801 } 803 typedef certificate-authority { 804 type string; 805 description 806 "Distinguished Name of Certificate authority as discussed 807 in Section 4.2.4 of RFC8446."; 808 } 810 typedef cipher-algorithm { 811 type uint8; 812 description 813 "AEAD encryption algorithm in TLS Cipher Suites registry 814 as discussed in Section 11 of RFC8446."; 815 } 817 typedef hash-algorithm { 818 type uint8; 819 description 820 "Hash algorithm used with HMAC-based Extract-and-Expand Key 821 Derivation Function (HKDF) in TLS Cipher Suites registry 822 as discussed in Section 11 of RFC8446."; 823 } 825 typedef tls-version { 826 type enumeration { 827 enum tls-1.2 { 828 value 1; 829 description 830 "TLS Protocol Version 1.2. 832 TLS 1.2 ClientHello contains 833 0x0303 in 'legacy_version'."; 834 reference 835 "RFC 5246: The Transport Layer Security (TLS) Protocol 836 Version 1.2"; 837 } 838 enum tls-1.3 { 839 value 2; 840 description 841 "TLS Protocol Version 1.3. 843 TLS 1.3 ClientHello contains a 844 supported_versions extension with 0x0304 845 contained in its body and the ClientHello contains 846 0x0303 in 'legacy_version'."; 847 reference 848 "RFC 8446: The Transport Layer Security (TLS) Protocol 849 Version 1.3"; 850 } 851 } 852 description 853 "Indicates the TLS version."; 854 } 856 typedef dtls-version { 857 type enumeration { 858 enum dtls-1.2 { 859 value 1; 860 description 861 "DTLS Protocol Version 1.2. 863 DTLS 1.2 ClientHello contains 864 0xfefd in 'legacy_version'."; 865 reference 866 "RFC 6346: Datagram Transport Layer Security 1.2"; 867 } 868 enum dtls-1.3 { 869 value 2; 870 description 871 "DTLS Protocol Version 1.3. 873 DTLS 1.3 ClientHello contains a 874 supported_versions extension with 0x0304 875 contained in its body and the ClientHello contains 876 0xfefd in 'legacy_version'."; 877 reference 878 "RFC DDDD: Datagram Transport Layer Security 1.3"; 879 } 880 } 881 description 882 "Indicates the DTLS version."; 883 } 884 } 885 887 5.4. MUD (D)TLS Profile Extension 889 This document augments the "ietf-mud" MUD YANG module to indicate 890 whether the device supports (D)TLS profile. If the "ietf-mud-tls" 891 extension is supported by the device, MUD file is assumed to 892 implement the "match-on-tls-dtls" ACL model feature defined in this 893 specification. Furthermore, only "accept" or "drop" actions SHOULD 894 be included with the (D)TLS profile similar to the actions allowed in 895 Section 2 of [RFC8520]. 897 This document defines the YANG module "ietf-mud-tls", which has the 898 following tree structure: 900 module: ietf-mud-tls 901 augment /ietf-mud:mud: 902 +--rw is-tls-dtls-profile-supported? boolean 904 The model is defined as follows: 906 file "iana-tls-mud@2020-10-20.yang" 908 module ietf-mud-tls { 909 yang-version 1.1; 910 namespace "urn:ietf:params:xml:ns:yang:ietf-mud-tls"; 911 prefix ietf-mud-tls; 913 import ietf-mud { 914 prefix ietf-mud; 915 } 917 organization 918 "IETF OPSAWG (Operations and Management Area Working Group)"; 919 contact 920 "WG Web: 921 WG List: opsawg@ietf.org 923 Author: Konda, Tirumaleswar Reddy 924 TirumaleswarReddy_Konda@McAfee.com 926 "; 927 description 928 "Extension to a MUD module to indicate (D)TLS 929 profile support. 931 Copyright (c) 2020 IETF Trust and the persons identified as 932 authors of the code. All rights reserved. 934 Redistribution and use in source and binary forms, with or 935 without modification, is permitted pursuant to, and subject 936 to the license terms contained in, the Simplified BSD License 937 set forth in Section 4.c of the IETF Trust's Legal Provisions 938 Relating to IETF Documents 939 (http://trustee.ietf.org/license-info). 941 This version of this YANG module is part of RFC XXXX; see 942 the RFC itself for full legal notices."; 944 revision 2020-10-19 { 945 description 946 "Initial revision."; 947 reference 948 "RFC XXXX: Manufacturer Usage Description (MUD) (D)TLS 949 Profiles for IoT Devices"; 950 } 952 augment "/ietf-mud:mud" { 953 description 954 "This adds a extension for a manufacturer 955 to indicate whether (D)TLS profile is 956 is supported by a device."; 957 leaf is-tls-dtls-profile-supported { 958 type boolean; 959 description 960 "This value will equal 'true' if a device supports 961 (D)TLS profile."; 962 } 963 } 964 } 965 967 6. Processing of the MUD (D)TLS Profile 969 The following text outlines the rules for a network security service 970 (e.g., firewall) to follow to process the MUD (D)TLS Profile: 972 o If the (D)TLS parameter observed in a (D)TLS session is not 973 specified in the MUD (D)TLS profile and the parameter is 974 recognized by the firewall, it can identify unexpected (D)TLS 975 usage, which can indicate the presence of unauthorized software or 976 malware on an endpoint. The firewall can take several actions 977 like block the (D)TLS session or raise an alert to quarantine and 978 remediate the compromised device. For example, if the cipher 979 suite TLS_RSA_WITH_AES_128_CBC_SHA in the ClientHello message is 980 not specified in the MUD (D)TLS profile and the cipher suite is 981 recognized by the firewall, it can identify unexpected TLS usage. 983 o If the (D)TLS parameter observed in a (D)TLS session is not 984 specified in the MUD (D)TLS profile and the (D)TLS parameter is 985 not recognized by the firewall, it can ignore the unrecognized 986 parameter and the correct behavior is not to block the (D)TLS 987 session. The behaviour is functionally equivalent to the 988 description in Section 9.3 of [RFC8446] to ignore all unrecognized 989 cipher suites, extensions, and other parameters. For example, if 990 the cipher suite TLS_CHACHA20_POLY1305_SHA256 in the ClientHello 991 message is not specified in the MUD (D)TLS profile and the cipher 992 suite is not recognized by the firewall, it can ignore the 993 unrecognized cipher suite. 995 o Deployments update at different rates, so an updated MUD (D)TLS 996 profile may support newer parameters. If the firewall does not 997 recognize the newer parameters, an alert should be triggered to 998 the firewall vendor and the IoT device owner or administrator. A 999 firewall must be readily updatable, so that when ossification 1000 problems are discovered, they can be addressed quickly. Most 1001 importantly, if the firewall is not readily updatable, its 1002 efficacy to identify emerging malware will decrease with time. 1003 For example, if the cipher suite TLS_AES_128_CCM_8_SHA256 in the 1004 ClientHello message is specified in the MUD (D)TLS profile and the 1005 cipher suite is not recognized by the firewall, an alert will be 1006 triggered. Similarly, if the (D)TLS version in the MUD file is 1007 not recognized by the firewall, an alert will be triggered. 1009 7. MUD File Example 1011 The example below contains (D)TLS profile parameters for a IoT device 1012 used to reach servers listening on port 443 using TCP transport. 1013 JSON encoding of YANG modelled data [RFC7951] is used to illustrate 1014 the example. 1016 { 1017 "ietf-mud:mud": { 1018 "mud-version": 1, 1019 "mud-url": "https://example.com/IoTDevice", 1020 "last-update": "2019-18-06T03:56:40.105+10:00", 1021 "cache-validity": 100, 1022 "extensions": [ 1023 "ietf-mud-tls" 1024 ], 1025 "ietf-mud-tls:is-tls-dtls-profile-supported": "true", 1026 "is-supported": true, 1027 "systeminfo": "IoT device name", 1028 "from-device-policy": { 1029 "access-lists": { 1030 "access-list": [ 1031 { 1032 "name": "mud-7500-profile" 1033 } 1034 ] 1035 } 1036 }, 1037 "ietf-access-control-list:acls": { 1038 "acl": [ 1039 { 1040 "name": "mud-7500-profile", 1041 "type": "ipv6-acl-type", 1042 "aces": { 1043 "ace": [ 1044 { 1045 "name": "cl0-frdev", 1046 "matches": { 1047 "ipv6": { 1048 "protocol": 6 1049 }, 1050 "tcp": { 1051 "ietf-mud:direction-initiated": "from-device", 1052 "destination-port": { 1053 "operator": "eq", 1054 "port": 443 1055 } 1056 }, 1057 "ietf-acl-tls:client-profile" : { 1058 "tls-dtls-profiles" : [ 1059 { 1060 "supported-tls-versions" : ["tls-1.3"], 1061 "cipher-suites" : [ 1062 { 1063 "cipher": 19, 1064 "hash": 1 1065 }, 1066 { 1067 "cipher": 19, 1068 "hash": 2 1069 } 1070 ], 1071 "extension-types" : [10,11,13,16,24], 1072 "supported-groups" : [29] 1073 } 1074 ] 1075 }, 1076 "actions": { 1077 "forwarding": "accept" 1078 } 1080 } 1081 } 1082 ] 1083 } 1084 } 1085 ] 1086 } 1087 } 1088 } 1090 The following illustrates the example scenarios for processing the 1091 above profile: 1093 o If the extension type "encrypt_then_mac" (code point 22) [RFC7366] 1094 in the ClientHello message is recognized by the firewall, it can 1095 identify unexpected TLS usage. 1097 o If the extension type "token_binding" (code point 24) [RFC8472] in 1098 the ClientHello message is not recognized by the firewall, it can 1099 ignore the unrecognized extension. Because the extension type 1100 token_binding is specified in the profile, an alert will be 1101 triggered to the firewall vendor and the IoT device owner or 1102 administrator to notify the firewall is not up to date. 1104 8. Security Considerations 1106 Security considerations in [RFC8520] need to be taken into 1107 consideration. Although it is challenging for a malware to mimic the 1108 TLS behavior of various IoT device types and IoT device models from 1109 several manufacturers, malicious agents have a very low probability 1110 of using the same (D)TLS profile parameters as legitimate agents on 1111 the IoT device to evade detection. Network security services should 1112 also rely on contextual network data to detect false negatives. In 1113 order to detect such malicious flows, anomaly detection (deep 1114 learning techniques on network data) can be used to detect malicious 1115 agents using the same (D)TLS profile parameters as legitimate agent 1116 on the IoT device. In anomaly detection, the main idea is to 1117 maintain rigorous learning of "normal" behavior and where an 1118 "anomaly" (or an attack) is identified and categorized based on the 1119 knowledge about the normal behavior and a deviation from this normal 1120 behavior. 1122 9. Privacy Considerations 1124 Privacy considerations discussed in Section 16 of [RFC8520] to not 1125 reveal the MUD URL to an attacker need to be taken into 1126 consideration. The MUD URL can be stored in Trusted Execution 1127 Environment (TEE) for secure operation, enhanced data security, and 1128 prevent exposure to unauthorized software. 1130 The middlebox acting as a (D)TLS proxy must immediately delete the 1131 decrypted data upon completing any necessary inspection functions. 1132 TLS proxy potentially has access to a user's PII (Personally 1133 identifiable information) and PHI (Protected Health Information). 1134 The TLS proxy must not store, process or modify PII data. For 1135 example, IT administrator can configure the middlebox to bypass 1136 payload inspection for a connection destined to a specific service 1137 due to privacy compliance requirements. In addition, mechanisms 1138 based on object security can be used by IoT devices to enable end-to- 1139 end security and the middlebox will not have any access to the packet 1140 data. For example, Object Security for Constrained RESTful 1141 Environments (OSCORE) [RFC8613] is a proposal that protects CoAP 1142 messages by wrapping them in the COSE format [RFC8152]. 1144 10. IANA Considerations 1146 10.1. (D)TLS Profile YANG Modules 1148 This document requests IANA to register the following URIs in the 1149 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 1151 URI: urn:ietf:params:xml:ns:yang:iana-tls-profile 1152 Registrant Contact: The IESG. 1153 XML: N/A; the requested URI is an XML namespace. 1155 URI: urn:ietf:params:xml:ns:yang:ietf-acl-tls 1156 Registrant Contact: The IESG. 1157 XML: N/A; the requested URI is an XML namespace. 1159 URI: urn:ietf:params:xml:ns:yang:ietf-mud-tls 1160 Registrant Contact: The IESG. 1161 XML: N/A; the requested URI is an XML namespace. 1163 IANA is requested to create an IANA-maintained YANG Module called 1164 "iana-tls-profile", based on the contents of Section 5.3, which will 1165 allow for new (D)TLS parameters and (D)TLS versions to be added to 1166 "client-profile". The registration procedure will be Expert Review, 1167 as defined by [RFC8126]. 1169 This document requests IANA to register the following YANG modules in 1170 the "YANG Module Names" subregistry [RFC6020] within the "YANG 1171 Parameters" registry. 1173 name: iana-tls-profile 1174 namespace: urn:ietf:params:xml:ns:yang:iana-tls-profile 1175 maintained by IANA: Y 1176 prefix: ianatp 1177 reference: RFC XXXX 1179 name: ietf-acl-tls 1180 namespace: urn:ietf:params:xml:ns:yang:ietf-acl-tls 1181 maintained by IANA: N 1182 prefix: ietf-acl-tls 1183 reference: RFC XXXX 1185 name: ietf-mud-tls 1186 namespace: urn:ietf:params:xml:ns:yang:ietf-mud-tls 1187 maintained by IANA: N 1188 prefix: ietf-mud-tls 1189 reference: RFC XXXX 1191 IANA is requested to create an the initial version of the IANA- 1192 maintained YANG Module called "iana-tls-profile", based on the 1193 contents of Section 5.3, which will allow for new (D)TLS parameters 1194 and (D)TLS versions to be added. IANA is requested to add this note: 1196 o tls-version and dtls-version values must not be directly added to 1197 the iana-tls-profile YANG module. They must instead be 1198 respectively added to the "TLS Version Codes", and "DTLS Version 1199 Codes" registries. 1201 o (D)TLS parameters must not be directly added to the iana-tls- 1202 profile YANG module. They must instead be added to the "(D)TLS 1203 Parameters" registry. 1205 When a 'tls-version' or 'dtls-version' value is respectively added to 1206 the "TLS Version Codes" or "DTLS Version Codes" registry, a new 1207 "enum" statement must be added to the iana-tls-profile YANG module. 1208 The following "enum" statement, and substatements thereof, should be 1209 defined: 1211 "enum": Replicates the label from the registry. 1213 "value": Contains the IANA-assigned value corresponding to the 1214 'tls-version' or 'dtls-version'. 1216 "description": Replicates the description from the registry. 1218 "reference": Replicates the reference from the registry and adds 1219 the title of the document. 1221 When a (D)TLS parameter is added to "(D)TLS Parameters" registry, a 1222 new "type" statement must be added to the iana-tls-profile YANG 1223 module. The following "type" statement, and substatements thereof, 1224 should be defined: 1226 "derived type": Replicates the parameter name from the registry. 1228 "built-in type": Contains the built-in YANG type. 1230 "description": Replicates the description from the registry. 1232 When the iana-tls-profile YANG module is updated, a new "revision" 1233 statement must be added in front of the existing revision statements. 1235 IANA is requested to add this note to "TLS Version Codes", "DTLS 1236 Version Codes", and "(D)TLS Parameters" registries: 1238 When this registry is modified, the YANG module iana-tls-profile 1239 must be updated as defined in [RFCXXXX]. 1241 The registration procedure for "ietf-acl-tls" YANG module will be 1242 Specification Required, as defined by [RFC8126]. 1244 10.2. TLS Version registry 1246 IANA is requested to create a new subregistry titled "TLS Version 1247 Codes". Codes in this registry are used as valid values of 'tls- 1248 version' parameter. Further assignments are to be made through 1249 Expert Review [RFC8126]. 1251 +-------+---------+-----------------+-----------+ 1252 | Value | Label | Description | Reference | 1253 | | | | | 1254 | | | | | 1255 +-------+---------+-----------------+-----------+ 1256 | 1 | tls-1.2 | TLS Version 1.2 | [RFC5246] | 1257 +-------+---------+-----------------+-----------+ 1258 | 2 | tls-1.3 | TLS Version 1.3 | [RFC8446] | 1259 +-------+---------+-----------------+-----------+ 1261 10.3. DTLS version registry 1263 IANA is requested to create a new subregistry titled "DTLS Version 1264 Codes". Codes in this registry are used as valid values of 'dtls- 1265 version' parameter. Further assignments are to be made through 1266 Expert Review [RFC8126]. 1268 +-------+---------+----------------+-----------------------+ 1269 | Value | Label | Description | Reference | 1270 | | | | | 1271 | | | | | 1272 +-------+---------+----------------+-----------------------+ 1273 | 1 |dtls-1.2 |DTLS Version 1.2| [RFC6346] | 1274 +-------+---------+----------------+-----------------------+ 1275 | 2 |dtls-1.3 |DTLS Version 1.3|[draft-ietf-tls-dtls13]| 1276 +-------+---------+----------------+-----------------------+ 1278 10.4. (D)TLS Parameters registry 1280 IANA is requested to create a new subregistry titled "(D)TLS 1281 parameters". 1283 The values for all the (D)TLS parameters in the registry are defined 1284 in the TLS and DTLS IANA registries 1285 ( 1286 and ) excluding the tls-version, dtls-version, 1288 spki-pin-set and certificate-authority parameters. Further 1289 assignments are to be made through Expert Review [RFC8126]. The 1290 registry is initially populated with the following parameters: 1292 +----------------------------+-------------+--------+---------------------------------------------+ 1293 | Parameter Name | YANG | JSON | | 1294 | | Type | Type | Description | 1295 | | | | | 1296 +----------------------------+-------------+--------+---------------------------------------------+ 1297 | extension-type | uint16 | Number | Extension type | 1298 +----------------------------+-------------+--------+---------------------------------------------+ 1299 | supported-group | uint16 | Number | Supported group | 1300 +----------------------------+-------------+--------+---------------------------------------------+ 1301 | spki-pin-set | binary | String | Subject Public Key Info pin set | 1302 +----------------------------+-------------+--------+---------------------------------------------+ 1303 | signature-algorithm | uint16 | Number | Signature algorithm | 1304 +----------------------------+-------------+--------+---------------------------------------------+ 1305 | psk-key-exchange-mode | uint8 | Number | pre-shared key exchange mode | 1306 +----------------------------+-------------+--------+---------------------------------------------+ 1307 | application-protocol | string | String | Application protocol | 1308 +----------------------------+-------------+--------+---------------------------------------------+ 1309 | cert-compression-algorithm | uint16 | Number | Certificate compression algorithm | 1310 +----------------------------+-------------+--------+---------------------------------------------+ 1311 | certificate-authority | string | String | Distinguished Name of Certificate authority | 1312 +----------------------------+-------------+--------+---------------------------------------------+ 1313 | cipher-algorithm | uint8 | Number | AEAD encryption algorithm | 1314 +----------------------------+-------------+--------+---------------------------------------------+ 1315 | hash-algorithm | uint8 | Number | Hash algorithm | 1316 +----------------------------+-------------+--------+---------------------------------------------+ 1317 | tls-version | enumeration | String | TLS version | 1318 +----------------------------+-------------+--------+---------------------------------------------+ 1319 | dtls-version | enumeration | String | DTLS version | 1320 +----------------------------+-------------+--------+---------------------------------------------+ 1322 10.5. MUD Extensions registry 1324 IANA is requested to create a new MUD Extension Name "ietf-mud-tls" 1325 in the MUD Extensions IANA registry 1326 . 1328 11. Acknowledgments 1330 Thanks to Flemming Andreasen, Shashank Jain, Michael Richardson, 1331 Piyush Joshi, Eliot Lear, Harsha Joshi, Qin Wu, Mohamed Boucadair, 1332 Ben Schwartz, Eric Rescorla, Panwei William, Nick Lamb and Nick 1333 Harper for the discussion and comments. 1335 12. References 1337 12.1. Normative References 1339 [I-D.ietf-netconf-crypto-types] 1340 Watsen, K., "YANG Data Types and Groupings for 1341 Cryptography", draft-ietf-netconf-crypto-types-18 (work in 1342 progress), August 2020. 1344 [I-D.ietf-tls-certificate-compression] 1345 Ghedini, A. and V. Vasiliev, "TLS Certificate 1346 Compression", draft-ietf-tls-certificate-compression-10 1347 (work in progress), January 2020. 1349 [I-D.ietf-tls-dtls13] 1350 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1351 Datagram Transport Layer Security (DTLS) Protocol Version 1352 1.3", draft-ietf-tls-dtls13-38 (work in progress), May 1353 2020. 1355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1356 Requirement Levels", BCP 14, RFC 2119, 1357 DOI 10.17487/RFC2119, March 1997, 1358 . 1360 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1361 DOI 10.17487/RFC3688, January 2004, 1362 . 1364 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1365 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1366 January 2012, . 1368 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 1369 RFC 6991, DOI 10.17487/RFC6991, July 2013, 1370 . 1372 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1373 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1374 May 2017, . 1376 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1377 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1378 . 1380 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 1381 "YANG Data Model for Network Access Control Lists (ACLs)", 1382 RFC 8519, DOI 10.17487/RFC8519, March 2019, 1383 . 1385 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 1386 Sustain Extensibility (GREASE) to TLS Extensibility", 1387 RFC 8701, DOI 10.17487/RFC8701, January 2020, 1388 . 1390 [X690] ITU-T, "Information technology - ASN.1 encoding Rules: 1391 Specification of Basic Encoding Rules (BER), Canonical 1392 Encoding Rules (CER) and Distinguished Encoding Rules 1393 (DER)", ISO/IEC 8825-1:2002, 2002. 1395 12.2. Informative References 1397 [clear-as-mud] 1398 "Clear as MUD: Generating, Validating and Applying IoT 1399 Behaviorial Profiles", October 2019, 1400 . 1402 [cryto-vulnerability] 1403 Perez, B., "Exploiting the Windows CryptoAPI 1404 Vulnerability", January 2020, 1405 . 1408 [I-D.ietf-tls-esni] 1409 Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS 1410 Encrypted Client Hello", draft-ietf-tls-esni-08 (work in 1411 progress), October 2020. 1413 [I-D.ietf-uta-tls13-iot-profile] 1414 Tschofenig, H. and T. Fossati, "TLS/DTLS 1.3 Profiles for 1415 the Internet of Things", draft-ietf-uta-tls13-iot- 1416 profile-00 (work in progress), June 2020. 1418 [I-D.reddy-add-enterprise] 1419 Reddy.K, T. and D. Wing, "DNS-over-HTTPS and DNS-over-TLS 1420 Server Deployment Considerations for Enterprise Networks", 1421 draft-reddy-add-enterprise-00 (work in progress), June 1422 2020. 1424 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 1425 Malware's use of TLS (without Decryption)", July 2016, 1426 . 1428 [malware-doh] 1429 Cimpanu, C., "First-ever malware strain spotted abusing 1430 new DoH (DNS over HTTPS) protocol", July 2019, 1431 . 1434 [malware-tls] 1435 Anderson, B. and D. McGrew, "TLS Beyond the Browser: 1436 Combining End Host and Network Data to Understand 1437 Application Behavior", October 2019, 1438 . 1440 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 1441 the Network Configuration Protocol (NETCONF)", RFC 6020, 1442 DOI 10.17487/RFC6020, October 2010, 1443 . 1445 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1446 Extensions: Extension Definitions", RFC 6066, 1447 DOI 10.17487/RFC6066, January 2011, 1448 . 1450 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1451 "Transport Layer Security (TLS) Application-Layer Protocol 1452 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1453 July 2014, . 1455 [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer 1456 Security (TLS) and Datagram Transport Layer Security 1457 (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014, 1458 . 1460 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 1461 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 1462 2015, . 1464 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1465 "Recommendations for Secure Use of Transport Layer 1466 Security (TLS) and Datagram Transport Layer Security 1467 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1468 2015, . 1470 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 1471 Security (TLS) / Datagram Transport Layer Security (DTLS) 1472 Profiles for the Internet of Things", RFC 7925, 1473 DOI 10.17487/RFC7925, July 2016, 1474 . 1476 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 1477 RFC 7951, DOI 10.17487/RFC7951, August 2016, 1478 . 1480 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1481 Writing an IANA Considerations Section in RFCs", BCP 26, 1482 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1483 . 1485 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 1486 RFC 8152, DOI 10.17487/RFC8152, July 2017, 1487 . 1489 [RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport 1490 Layer Security (TLS) Extension for Token Binding Protocol 1491 Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 1492 2018, . 1494 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 1495 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 1496 . 1498 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 1499 Description Specification", RFC 8520, 1500 DOI 10.17487/RFC8520, March 2019, 1501 . 1503 [RFC8576] Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of 1504 Things (IoT) Security: State of the Art and Challenges", 1505 RFC 8576, DOI 10.17487/RFC8576, April 2019, 1506 . 1508 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1509 "Object Security for Constrained RESTful Environments 1510 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1511 . 1513 [X501] "Information Technology - Open Systems Interconnection - 1514 The Directory: Models", ITU-T X.501, 1993. 1516 Authors' Addresses 1517 Tirumaleswar Reddy 1518 McAfee, Inc. 1519 Embassy Golf Link Business Park 1520 Bangalore, Karnataka 560071 1521 India 1523 Email: kondtir@gmail.com 1525 Dan Wing 1526 Citrix Systems, Inc. 1527 4988 Great America Pkwy 1528 Santa Clara, CA 95054 1529 USA 1531 Email: danwing@gmail.com 1533 Blake Anderson 1534 Cisco Systems, Inc. 1535 170 West Tasman Dr 1536 San Jose, CA 95134 1537 USA 1539 Email: blake.anderson@cisco.com