idnits 2.17.1 draft-reddy-opswg-mud-tls-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 262 has weird spacing: '...warding ide...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2019) is 1754 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: '31354' on line 567 -- Looks like a reference, but probably isn't: '4865' on line 567 -- Looks like a reference, but probably isn't: '4866' on line 567 -- Looks like a reference, but probably isn't: '4867' on line 567 -- Looks like a reference, but probably isn't: '10' on line 568 -- Looks like a reference, but probably isn't: '29' on line 569 == Unused Reference: 'RFC7478' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'RFC8445' is defined on line 686, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-netconf-crypto-types-10 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-31 ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-22 == Outdated reference: A later version (-09) exists of draft-ietf-tls-sni-encryption-04 == Outdated reference: A later version (-08) exists of draft-reddy-dprive-bootstrap-dns-server-04 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSWG WG T. Reddy 3 Internet-Draft McAfee 4 Intended status: Standards Track D. Wing 5 Expires: January 9, 2020 Citrix 6 July 8, 2019 8 MUD (D)TLS profiles for IoT devices 9 draft-reddy-opswg-mud-tls-00 11 Abstract 13 This memo extends Manufacturer Usage Description (MUD) to model DTLS 14 and TLS usage. This allows a network element to notice abnormal DTLS 15 or TLS usage which has been strong indicator of other software 16 running on the endpoint, typically malware. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 9, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview of MUD (D)TLS profiles for IoT devices . . . . . . . 4 55 4. (D)TLS profile YANG module . . . . . . . . . . . . . . . . . 5 56 4.1. Tree Structure . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6 58 5. (D)TLS 1.3 handshake . . . . . . . . . . . . . . . . . . . . 10 59 5.1. Encrypted SNI . . . . . . . . . . . . . . . . . . . . . . 10 60 5.2. Full (D)TLS 1.3 handshake inspection . . . . . . . . . . 11 61 6. MUD File Example . . . . . . . . . . . . . . . . . . . . . . 12 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 67 10.2. Informative References . . . . . . . . . . . . . . . . . 15 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 70 1. Introduction 72 Encryption is necessary to protect the privacy of end users using IoT 73 devices. In a network setting, TLS [RFC8446] and DTLS 74 [I-D.ietf-tls-dtls13] are the dominant protocols to provide 75 encryption for IoT device traffic. Unfortunately in conjunction with 76 IoT applications rise of encryption, malware is also using encryption 77 which thwarts network-based analysis such as deep packet inspection 78 (DPI). Other mechanisms are needed to notice malware is running on 79 the IoT device. 81 Malware frequently uses its own libraries for its activities, and 82 those libraries are re-used much like any other software engineering 83 project. Research [malware] indicates there are observable 84 differences in how malware uses encryption compared with non-malware 85 uses encryption. There are several interesting findings specific to 86 DTLS and TLS which were found common to malware: 88 o Older and weaker cryptographic parameters (e.g., 89 TLS_RSA_WITH_RC4_128_SHA). 91 o TLS SNI and server certificates are composed of subjects with 92 characteristics of a domain generation algorithm (DGA) (e.g., 93 www.33mhwt2j.net). 95 o Higher use of self-signed certificates compared with typical 96 legitimate software. 98 o Discrepancies in the server name indication (SNI) TLS extension in 99 the ClientHello message and the DNS names in the 100 SubjectAltName(SAN) X.509 extension in the server certificate 101 message. 103 o Discrepancies in the key exchange algorithm and the client public 104 key length in comparison with legitimate flows. As a reminder, 105 Client Key Exchange message has been removed from TLS 1.3. 107 o Lower diversity in TLS client advertised TLS extensions compared 108 to legitimate clients. 110 If observable (D)TLS profile parameters are used, the following 111 discusses the favorable impact on network security: 113 o Although IoT devices that have a single or small number of uses 114 might have very broad communication patterns. In such a case, MUD 115 rules using ACLs on its own is not suitable for these IoT devices 116 but observable (D)TLS profile parameters can be used for such IoT 117 devices to permit intended use and to block malicious behaviour of 118 IoT devices. 120 o Several TLS deployments have been vulnerable to active Man-In-The- 121 Middle (MITM) attacks because of lack of certificate validation. 122 By observing (D)TLS profile parameters, a network element can 123 detect when the TLS SNI mismatches the SubjectAltName and detect 124 when the server's certificate is invalid, and alert those 125 situations. 127 o IoT device can learn a new skill, and the new skill changes the 128 way the IoT device communicates with other devices located in the 129 local network and Internet. In other words, if IP addresses and 130 domain names the IoT device connects to rapidly changes and MUD 131 rules using ACLs cannot be rapidly updated, observable (D)TLS 132 profile parameters can be used to permit intended use and to block 133 malicious behaviour of IoT device. 135 This document extends MUD [RFC8520] to model observable (D)TLS 136 profile parameters. Using these (D)TLS profile parameters, an active 137 MUD-enforcing firewall can identify MUD non-compliant DTLS and TLS 138 behavior that can indicate malware is running on the IoT device. 139 This detection can prevent malware download, block access to 140 malicious domains, enforce use of strong ciphers, stop data 141 exfiltration, etc. In addition, organizations may have policies 142 around acceptable ciphers and certificates on the websites the IoT 143 devices connect to. Examples include no use of old and less secure 144 versions of TLS, no use of self-signed certificates, deny-list or 145 accept-list of Certificate Authorities, valid certificate expiration 146 time, etc. These policies can be enforced by observing the (D)TLS 147 profile parameters. Enterprise firewall can use the IoT device's 148 (D)TLS profile parameters to identify legitimate flows by observation 149 of (D)TLS sessions, and can make inferences to permit legitimate 150 flows and to block malicious flows. The proposed technique is also 151 suitable in deployments where decryption techniques are not ideal due 152 to privacy concerns, non-cooperating end-points and expense. 154 2. Terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described in BCP 159 14 [RFC2119][RFC8174] when, and only when, they appear in all 160 capitals, as shown here. 162 "(D)TLS" is used for statements that apply to both Transport Layer 163 Security [RFC8446] and Datagram Transport Layer Security [RFC6347]. 164 Specific terms are used for any statement that applies to either 165 protocol alone. 167 3. Overview of MUD (D)TLS profiles for IoT devices 169 In Enterprise networks, protection and detection are typically done 170 both on end hosts and in the network. Host agents have deep 171 visibility on the devices where they are installed, whereas the 172 network has broader visibility. Installing host agents may not be a 173 viable option on IoT devices, and network-based security can only be 174 used to protect such IoT devices. (D)TLS profile parameters of IoT 175 device can be used by middle-boxes to detect and block malware 176 communication, while at the same time preserving the privacy of 177 legitimate uses of encryption. Middle-boxes need not proxy (D)TLS 178 but can passively observe the parameters of (D)TLS handshakes from 179 IoT devices and gain good visibility into TLS 1.0 to 1.2 parameters 180 and partial visibility into TLS 1.3 parameters. Malicious agents can 181 try to use the (D)TLS profile parameters as legitimate agents to 182 evade detection but it becomes a challenge to mimic the behavior of 183 various IoT device types and IoT device models from several 184 manufacturers. In other words, malware developers will have to 185 develop malicious agents per IoT device type, manufacturer and model 186 (which will be several thousands), infect the device with specific 187 malware agent and will have keep up with the updates to (D)TLS 188 profile parameters of IoT devices. Further, the malware command and 189 control server certificates needs to be signed by the same certifying 190 authorities trusted by the IoT devices. 192 4. (D)TLS profile YANG module 194 This document specifies a YANG module for representing (D)TLS 195 profile. The (D)TLS profile YANG module provides a method for 196 firewall to observe the (D)TLS profile parameters in the (D)TLS 197 handshake to permit intended use and to block malicious behavior. 198 This module uses the common YANG types defined in [RFC6991] , rules 199 defined in [RFC8519] and cryptographic types defined in 200 [I-D.ietf-netconf-crypto-types]. 202 The (D)TLS profile parameters include the following: 204 o (D)TLS versions supported by the IoT device 206 o List of supported symmetric encryption algorithms 208 o List of supported compression methods 210 o List of extension types 212 o List of client key exchange algorithms and the client public key 213 lengths in versions prior to (D)TLS 1.3 215 o List of trust anchor certificates used by the IoT device. Note 216 that server certificate is encrypted in (D)TLS 1.3 and the middle- 217 box without acting as (D)TLS proxy cannot validate the server 218 certificate. 220 o List of DHE or ECDHE groups supported by the client 222 o List signature algorithms the client can validate in X.509 server 223 certificates 225 o List of SPKI pin sets pre-configured on the client to validate 226 self-signed server certificates or raw public keys 228 o If SNI mismatch is allowed or not, and if SNI mismatch is allowed, 229 the server names for which SNI mismatch is allowed. 231 If the (D)TLS profile parameters are not observed in a (D)TLS session 232 from the IoT device, the default behaviour is to block the (D)TLS 233 session. 235 4.1. Tree Structure 237 This document augments the "ietf-mud" MUD YANG module defined in 238 [RFC8520] for signaling the IoT device (D)TLS profile. This document 239 defines the YANG module "reddy-opsawg-mud-tls-profile", which has the 240 following tree structure: 242 module: reddy-opsawg-mud-tls-profile 243 augment /mud:mud/mud:from-device-policy: 244 +--rw client-profile 245 +--rw tls-profiles* [protocol-version supported_versions] 246 +--rw protocol-version uint16 247 +--rw supported_versions boolean 248 +--rw encryption-algorithms* encryption-algorithm 249 +--rw compression-methods* compression-method 250 +--rw extension-types* extension-type 251 +--rw acceptlist-ta-certs* ct:trust-anchor-cert-cms 252 +--rw SPKI-pin-sets* SPKI-pin-set 253 +--rw SPKI-hash-algorithm ct:hash-algorithm-t 254 +--rw supported-groups* supported-group 255 +--rw signature-algorithms* signature-algorithm 256 +--rw client-public-keys 257 | +--rw key-exchange-algorithms* key-exchange-algorithm 258 | +--rw client-public-key-lengths* client-public-key-length 259 +--rw SNI-mismatch-allowed? boolean 260 +--rw server-name* inet:domain-name 261 +--rw actions 262 +--rw forwarding identityref 264 4.2. YANG Module 266 module reddy-opsawg-mud-tls-profile { 267 yang-version 1.1; 268 namespace "urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile"; 269 prefix mud-tls-profile; 271 import ietf-crypto-types { 272 prefix ct; 273 reference "draft-ietf-netconf-crypto-types-01: 274 Common YANG Data Types for Cryptography"; 275 } 277 import ietf-inet-types { 278 prefix inet; 279 reference "Section 4 of RFC 6991"; 280 } 282 import ietf-mud { 283 prefix mud; 284 reference "RFC 8520"; 285 } 286 import ietf-access-control-list { 287 prefix ietf-acl; 288 reference 289 "RFC 8519: YANG Data Model for Network Access 290 Control Lists (ACLs)"; 291 } 293 organization 294 "IETF Operations and Management Area Working Group Working Group"; 295 contact 296 "Editor: Konda, Tirumaleswar Reddy 297 "; 299 description 300 "This module contains YANG definition for configuring 301 aliases for resources and filtering rules using DOTS 302 data channel. 304 Copyright (c) 2019 IETF Trust and the persons identified as 305 authors of the code. All rights reserved. 307 Redistribution and use in source and binary forms, with or 308 without modification, is permitted pursuant to, and subject 309 to the license terms contained in, the Simplified BSD License 310 set forth in Section 4.c of the IETF Trust's Legal Provisions 311 Relating to IETF Documents 312 (http://trustee.ietf.org/license-info). 314 This version of this YANG module is part of RFC XXXX; see 315 the RFC itself for full legal notices."; 317 revision 2019-06-12 { 318 description 319 "Initial revision."; 320 } 322 typedef compression-method { 323 type uint8; 324 description "Compression method."; 325 } 327 typedef extension-type { 328 type uint16; 329 description "Extension type."; 330 } 332 typedef encryption-algorithm { 333 type uint16; 334 description "Encryption algorithms."; 335 } 337 typedef supported-group { 338 type uint16; 339 description "supported DHE or ECDHE group."; 340 } 342 typedef SPKI-pin-set { 343 type binary; 344 description "Subject Public Key Info pin set."; 345 } 347 typedef signature-algorithm { 348 type uint16; 349 description "Signature algorithm"; 350 } 352 typedef key-exchange-algorithm { 353 type uint8; 354 description "key exchange algorithm"; 355 } 356 typedef client-public-key-length { 357 type uint8; 358 description "client public key length"; 359 } 361 augment "/mud:mud/mud:from-device-policy" { 362 container client-profile { 363 list tls-profiles { 364 key "protocol-version supported_versions"; 365 description 366 "(D)TLS version profiles supported by the client"; 367 leaf protocol-version { 368 type uint16; 369 description "Legacy protocol version"; 370 } 371 leaf supported_versions { 372 type boolean; 373 description "supported versions extension for TLS 1.3"; 374 } 375 leaf-list encryption-algorithms { 376 type encryption-algorithm; 377 description "Encryption algorithms"; 378 } 379 leaf-list compression-methods { 380 type compression-method; 381 description "Compression methods"; 383 } 384 leaf-list extension-types { 385 type extension-type; 386 description "Extension Types"; 387 } 388 leaf-list acceptlist-ta-certs { 389 type ct:trust-anchor-cert-cms; 390 description 391 "A list of trust anchor certificates used by the client"; 392 } 393 leaf-list SPKI-pin-sets { 394 type SPKI-pin-set; 395 description 396 "A list of SPKI pin sets pre-configured on the client 397 to validate self-signed server certificate or 398 raw public key"; 399 } 400 leaf SPKI-hash-algorithm { 401 type ct:hash-algorithm-t; 402 description 403 "cryptographic hash algorithm used to generate the SPKI pinset"; 404 } 405 leaf-list supported-groups { 406 type supported-group; 407 description 408 "A list of DHE or ECDHE groups supported by the client"; 409 } 410 leaf-list signature-algorithms { 411 type signature-algorithm; 412 description 413 "A list signature algorithms the client can validate 414 in X.509 certificates."; 415 } 416 container client-public-keys { 417 when "../supported_versions = 'false'"; 418 leaf-list key-exchange-algorithms { 419 type key-exchange-algorithm; 420 description 421 "Key exchange algorithms supported by the client"; 422 } 423 leaf-list client-public-key-lengths { 424 type client-public-key-length; 425 description 426 "client public key lengths"; 427 } 428 } 429 leaf SNI-mismatch-allowed { 430 type boolean; 431 default "false"; 432 description 433 "If set to 'false', SNI mismatch is not allowed."; 434 } 435 leaf-list server-name { 436 when "../SNI-mismatch-allowed = 'true'"; 437 type inet:domain-name; 438 description 439 "Server names (FQDN) for which SNI mismatch is allowed."; 440 } 441 container actions { 442 description 443 "Definitions of action for this profile."; 444 leaf forwarding { 445 type identityref { 446 base ietf-acl:forwarding-action; 447 } 448 mandatory true; 449 description 450 "Specifies the forwarding action for the (D)TLS profile."; 451 reference 452 "RFC 8519: YANG Data Model for Network Access 453 Control Lists (ACLs)"; 454 } 455 } 456 } 457 } 458 } 459 } 461 5. (D)TLS 1.3 handshake 463 In (D)TLS 1.3, full (D)TLS handshake inspection is not possible since 464 all (D)TLS handshake messages excluding the ClientHello message are 465 encrypted. (D)TLS 1.3 has introduced new extensions in the handshake 466 record layers called Encrypted Extensions. Using these extensions 467 handshake messages will be encrypted and network devices (such as a 468 firewall) are incapable deciphering the handshake, thus cannot view 469 the server certificate. However, a few parameters in the ServerHello 470 are still visible such as the chosen cipher. Note that Client Key 471 Exchange message has been removed from (D)TLS 1.3. 473 5.1. Encrypted SNI 475 To increase privacy, encrypted SNI [I-D.ietf-tls-sni-encryption] 476 prevents passive observation of the TLS Server Name Indication and to 477 effectively provide privacy protection, SNI encryption needs to be 478 used in conjunction with DNS encryption (e.g., DNS-over-(D)TLS or 479 DNS- over-HTTPS). Firewall inspecting the (D)TLS 1.3 handshake 480 cannot decrypt encrypted SNI. If an IoT device is configured to use 481 public DNS-over-(D)TLS or DNS- over-HTTPS servers, the policy 482 enforcement point is moved to that public server, which cannot 483 enforce the MUD policy based on domain names (Section 8 of 484 [RFC8520]). Thus the use of a public DNS-over-(D)TLS or DNS- over- 485 HTTPS server is incompatible with MUD. A local DNS server is 486 necessary to allow MUD policy enforcement on the local network 487 ([I-D.ietf-doh-resolver-associated-doh] and 488 [I-D.reddy-dprive-bootstrap-dns-server]). 490 5.2. Full (D)TLS 1.3 handshake inspection 492 Middle-box needs to act as a (D)TLS 1.3 proxy to observe the 493 parameters of (D)TLS handshakes from IoT devices and gain good 494 visibility into TLS 1.3 parameters. The following steps explain the 495 mechanism to automatically bootstrap IoT devices with local network's 496 CA certificates and to enable the middle-box to act as a (D)TLS 1.3 497 proxy. 499 o Bootstrapping Remote Secure Key Infrastructures (BRSKI) discussed 500 in [I-D.ietf-anima-bootstrapping-keyinfra] provides a solution for 501 secure automated bootstrap of devices. BRSKI specifies means to 502 provision credentials on devices to be used to operationally 503 access networks. In addition, BRSKI provides an automated 504 mechanism for the bootstrap distribution of CA certificates from 505 the Enrollment over Secure Transport (EST) [RFC7030] server. The 506 IoT device can use BRSKI to automatically bootstrap the IoT device 507 using the IoT manufacturer provisioned X.509 certificate, in 508 combination with a registrar provided by the local network and IoT 509 device manufacturer's authorizing service (MASA). 511 1. The IoT device authenticates to the local network using the 512 IoT manufacturer provisioned X.509 certificate. The IoT 513 device can request and get a voucher from the MASA service via 514 the registrar. The voucher is signed by the MASA service and 515 includes the local network's CA public key. 517 2. The IoT device validates the signed voucher using the 518 manufacturer installed trust anchor associated with the MASA, 519 stores the CA's public key and validates the provisional TLS 520 connection to the registrar. 522 3. The IoT device requests the full EST distribution of current 523 CA certificates (Section 5.9.1 in 524 [I-D.ietf-anima-bootstrapping-keyinfra]) from the registrar 525 operating as a BRSKI-EST server. The IoT device stores the CA 526 certificates as Explicit Trust Anchor database entries. The 527 IoT device uses the Explicit Trust Anchor database to validate 528 the server certificate. 530 4. The middle-box uses the "supported_versions" TLS extension 531 (defined in TLS 1.3 to negotiate the supported TLS versions 532 between client and server) to determine the TLS version. 533 During the (D)TLS handshake, If (D)TLS version 1.3 is used, 534 the middle-box ((D)TLS proxy) modifies the certificate 535 provided by the server and signs it with the private key from 536 the local CA certificate. The middle-box has visibility into 537 further exchanges between the IoT device and server which 538 enables it to inspect the (D)TLS 1.3 handshake, enforce the 539 MUD (D)TLS profile and can inspect subsequent network traffic. 541 5. The IoT device uses the Explicit Trust Anchor database to 542 validate the server certificate. 544 The proposed technique empowers the middle-box to reject (D)TLS 1.3 545 sessions that violate the MUD (D)TLS profile. 547 6. MUD File Example 549 This example below contains (D)TLS profile parameters for a IoT 550 device. JSON encoding of YANG modelled data [RFC7951] is used to 551 illustrate the example. 553 { 554 "ietf-mud:mud": { 555 "mud-version": 1, 556 "mud-url": "https://example.com/IoTDevice", 557 "last-update": "2019-18-06T03:56:40.105+10:00", 558 "cache-validity": 100, 559 "is-supported": true, 560 "systeminfo": "IoT device name", 561 "reddy-opsawg-mud-tls-profile:from-device-policy": { 562 "client-profile": { 563 "tls-version-profile" : [ 564 { 565 "protocol-version" : 771, 566 "supported_versions_ext" : "FALSE", 567 "encryption-algorithms" : [31354, 4865, 4866, 4867], 568 "extension-types" : [10], 569 "supported-groups" : [29], 570 "actions": { 571 "forwarding": "accept" 572 } 573 } 574 ] 575 } 576 } 577 } 578 } 580 7. Security Considerations 582 Security considerations in [RFC8520] need to be taken into 583 consideration. 585 8. IANA Considerations 587 This document requests IANA to register the following URIs in the 588 "ns" subregistry within the "IETF XML Registry" [RFC3688]: 590 URI: urn:ietf:params:xml:ns:yang:reddy-opsawg-mud-tls-profile 591 Registrant Contact: The IESG. 592 XML: N/A; the requested URI is an XML namespace. 594 9. Acknowledgments 596 TODO 598 10. References 600 10.1. Normative References 602 [I-D.ietf-netconf-crypto-types] 603 Watsen, K. and H. Wang, "Common YANG Data Types for 604 Cryptography", draft-ietf-netconf-crypto-types-10 (work in 605 progress), July 2019. 607 [I-D.ietf-tls-dtls13] 608 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 609 Datagram Transport Layer Security (DTLS) Protocol Version 610 1.3", draft-ietf-tls-dtls13-31 (work in progress), March 611 2019. 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, 615 DOI 10.17487/RFC2119, March 1997, 616 . 618 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 619 DOI 10.17487/RFC3688, January 2004, 620 . 622 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 623 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 624 January 2012, . 626 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 627 RFC 6991, DOI 10.17487/RFC6991, July 2013, 628 . 630 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 631 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 632 May 2017, . 634 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 635 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 636 . 638 [RFC8519] Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 639 "YANG Data Model for Network Access Control Lists (ACLs)", 640 RFC 8519, DOI 10.17487/RFC8519, March 2019, 641 . 643 10.2. Informative References 645 [I-D.ietf-anima-bootstrapping-keyinfra] 646 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 647 S., and K. Watsen, "Bootstrapping Remote Secure Key 648 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 649 keyinfra-22 (work in progress), June 2019. 651 [I-D.ietf-doh-resolver-associated-doh] 652 Hoffman, P., "Associating a DoH Server with a Resolver", 653 draft-ietf-doh-resolver-associated-doh-03 (work in 654 progress), March 2019. 656 [I-D.ietf-tls-sni-encryption] 657 Huitema, C. and E. Rescorla, "Issues and Requirements for 658 SNI Encryption in TLS", draft-ietf-tls-sni-encryption-04 659 (work in progress), November 2018. 661 [I-D.reddy-dprive-bootstrap-dns-server] 662 K, R., Wing, D., Richardson, M., and M. Boucadair, "A 663 Bootstrapping Procedure to Discover and Authenticate DNS- 664 over-(D)TLS and DNS-over-HTTPS Servers", draft-reddy- 665 dprive-bootstrap-dns-server-04 (work in progress), June 666 2019. 668 [malware] Anderson, B., Paul, S., and D. McGrew, "Deciphering 669 Malware's use of TLS (without Decryption)", July 2016, 670 . 672 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 673 "Enrollment over Secure Transport", RFC 7030, 674 DOI 10.17487/RFC7030, October 2013, 675 . 677 [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 678 Time Communication Use Cases and Requirements", RFC 7478, 679 DOI 10.17487/RFC7478, March 2015, 680 . 682 [RFC7951] Lhotka, L., "JSON Encoding of Data Modeled with YANG", 683 RFC 7951, DOI 10.17487/RFC7951, August 2016, 684 . 686 [RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive 687 Connectivity Establishment (ICE): A Protocol for Network 688 Address Translator (NAT) Traversal", RFC 8445, 689 DOI 10.17487/RFC8445, July 2018, 690 . 692 [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage 693 Description Specification", RFC 8520, 694 DOI 10.17487/RFC8520, March 2019, 695 . 697 Authors' Addresses 699 Tirumaleswar Reddy 700 McAfee, Inc. 701 Embassy Golf Link Business Park 702 Bangalore, Karnataka 560071 703 India 705 Email: kondtir@gmail.com 707 Dan Wing 708 Citrix Systems, Inc. 709 4988 Great America Pkwy 710 Santa Clara, CA 95054 711 USA 713 Email: danwing@gmail.com