idnits 2.17.1 draft-fiebig-security-acme-01.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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 358: '...ts an attack, it MAY require the reque...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 09, 2019) is 1689 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 438 -- Looks like a reference, but probably isn't: '2' on line 440 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Security Dispatch T. Fiebig 3 Internet-Draft TU Delft 4 Intended status: Informational K. Borgolte 5 Expires: March 12, 2020 Princeton University 6 September 09, 2019 8 Extended Security Considerations for the Automatic Certificate 9 Management Environment (ESecACME) 10 draft-fiebig-security-acme-01 12 Abstract 14 Most Public Key Infrastructure X.509 (PKIX) certificates are issued 15 via the ACME protocol. Recently, several attacks against domain 16 validation (DV) have been published, including IP-use-after-free and 17 (forced) on-path attacks. These attacks can often be mitigated by 18 (selectively) requiring additional challenges, such as DNS 19 validation, proof of ownership of a prior certificate, and by being 20 more diligent in operating a certificate authority. This document 21 provides a list of currently known attacks and describes mitigations 22 and operational procedures to prevent issuing a certificate to an 23 unauthorized party. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on March 12, 2020. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. IP and Resource-use-after-free Attacks . . . . . . . . . 3 62 2.1.1. Detection . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. (Forced)-On-path Attacks . . . . . . . . . . . . . . . . 4 65 2.2.1. Detection . . . . . . . . . . . . . . . . . . . . . . 5 66 2.2.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.3. DNS Cache Poisoning Attacks . . . . . . . . . . . . . . . 5 68 2.3.1. Detection . . . . . . . . . . . . . . . . . . . . . . 5 69 2.3.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.4. DNS Cache Staleness Attacks . . . . . . . . . . . . . . . 6 71 2.4.1. Detection . . . . . . . . . . . . . . . . . . . . . . 6 72 2.4.2. Defense . . . . . . . . . . . . . . . . . . . . . . . 6 73 3. Summary of CA Operational Improvements . . . . . . . . . . . 6 74 3.1. Hardening Against Attacks Without DNS Control . . . . . . 7 75 3.2. Multi-Vantage Point Validation . . . . . . . . . . . . . 7 76 3.3. BGP Monitoring . . . . . . . . . . . . . . . . . . . . . 7 77 3.4. DNS Resolver Configuration and Monitoring . . . . . . . . 7 78 3.5. DNSSEC Validation Failure and Lack of DNSSEC . . . . . . 8 79 3.6. Recent Domain Transfer . . . . . . . . . . . . . . . . . 8 80 4. Additional Validation Options . . . . . . . . . . . . . . . . 8 81 4.1. Proof of Ownership of a Prior Certificate . . . . . . . . 8 82 4.1.1. Limitations . . . . . . . . . . . . . . . . . . . . . 8 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 85 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 88 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 Today, most Public Key Infrastructure X.509 (PKIX) certificates are 94 issued via the ACME protocol. The automated nature of ACME and its 95 heavy use of domain validation (DV) render it susceptible to a 96 variety of attacks. These attacks include IP-use-after-free 98 [CSTRIFE], (forced) on-path attacks [BAMBOO], and attacks on 99 protocols used for validation [DVP], like DNS. In general, these 100 attacks can be mitigated by (selectively) requiring additional 101 challenges, e.g., validation of DNSSEC signatures, proof of ownership 102 of a prior certificate, and by being more diligent when operating a 103 certificate authority. 105 This document provides a list of known attacks and how they can be 106 detected. It also describes mitigations and operational procedures 107 that CAs should implement to reduce the threat of issuing a 108 certificate to an unauthorized party. This section holds information 109 on how these mitigations may impact the usability of CAs using ACME 110 to issue certificates. 112 2. Attacks 114 In this section, we describe practical attacks against DV, how to 115 detect them, and which additional verification methods should be used 116 in case of an attack. 118 2.1. IP and Resource-use-after-free Attacks 120 IP and resource-use-after-free attacks occur if a domain owner points 121 a DNS record to a resource, which they later vacate without deleting 122 the corresponding DNS record. The resource, such as in cloud 123 scenarios, could then be allocated by another party, thus, allowing 124 an attacker to impersonate the owner. 126 For example, assuming that the web server for www.example.com is 127 hosted on a virtual machine a cloud provider and the AAAA record of 128 www.example.com points to the IPv6 address of that virtual machine, 129 e.g., 2001:db8:1234:1234::1, and, when the operator terminates the 130 virtual machine and frees the resource, they do not remove the DNS 131 record. Then, it leads to a stale or dangling DNS record. If then 132 another user of the cloud provider allocates a virtual machine, and 133 receives the same IPv6 address (by luck or through other means), then 134 this user could proof ownership of www.example.com to an ACME 135 compliant CA. 137 These observations also hold for DNS records pointing to legacy IPv4 138 resources (A records), email servers in case of email-based ownership 139 verification (MX records), SIP or other service delegations (SRV 140 records), and even DNS delegations if DNSSEC is not being used (NS 141 records). The attacks' feasibility is further increased by the fact 142 that some validation challenges may validate a domain by verifying 143 only one resource in case of multiple equivalent DNS records. 145 2.1.1. Detection 147 These attacks are difficult to detect from the CAs point of view, 148 without domain owners taking additional precautions themselves. 149 Techniques to detect the attack that CAs should use depend on the 150 cooperation from domain owners. 152 Domain owners should use TLSA records to pin the TLS public key for a 153 name, allowing the CA to verify the TLSA record to the key for which 154 a certificate is requested. 156 A detection technique which does not require prior cooperation by 157 domain owners leverages Certificate Transparency (CT) logs to 158 identify certificates that were issued for the domain in the past, 159 which can then be verified to still exist (thus, proving ownership of 160 a previous certificate). Furthermore, CAA records can be used to 161 restrict the number of CT logs that the processing CA needs to 162 search. Additionally, if the processing CA is the only CA allowed to 163 issue a certificate restricted through CAA records, then it may check 164 that the certificate request is made by the same ACME account as 165 prior successful certificate issuance requests. 167 2.1.2. Defense 169 If the TLSA public key and the public key used in making the 170 certificate request do not match, then the CA must deny the requested 171 certificate. In case of a preexisting certificate or a mismatch in 172 the requesting ACME account, the operator must use additional 173 validation techniques. If the domain has valid DNSSEC records, then 174 a DNS challenge should be used. Alternatively, the CA should use a 175 validation method that requires ownership of a previously issued 176 certificate's key. Considering that NS and MX records may also 177 suffer from resource-use-after-free attacks, unauthenticated DNS and 178 email challenges must not be used. 180 Due to the inherent usability implications of the defense the CA may 181 mitigate on high-risk resources only, such as known cloud providers 182 or for operators with a high customer churn. 184 2.2. (Forced)-On-path Attacks 186 If an attacker can perform a man-in-the-middle (MitM) attack by 187 controlling part of the network path between the CA and the resource 188 used for validation, then they can also impersonate an operator and 189 illegitimately obtain a certificate for a domain. Attackers may 190 force this on-path situation, e.g., by using BGP shorter-prefix 191 attacks [BAMBOO]. 193 2.2.1. Detection 195 To detect on-path attacks, a CA should validate challenges from 196 multiple vantage points. For this purpose, the CA must operate a 197 geographically and topologically distributed system for verification. 198 This system must contain at least one validator per IP region 199 (AfriNIC, APNIC, ARIN, LACNIC, and RIPE). A CA monitor should also 200 monitor the BGP prefix from which it the request originated, e.g., 201 via a service similar to https://bgpmon.net [1]. However, note that, 202 depending how close the attacker is to the victim on the network 203 path, there may no path without malicious activity. Therefore, it 204 generalizes the detection issue to that outlined for resource-use- 205 after-free attacks. 207 2.2.2. Defense 209 The same defenses as for resource-use-after-free attacks apply. If 210 an ongoing attack on a network prefix is detected, the CA must not 211 issue certificates for the affected domains until the attack is over. 213 2.3. DNS Cache Poisoning Attacks 215 If an attacker is able to poison the DNS cache [CPOIS] of a CA while 216 the CA validates a domain, then they may change the target of the DNS 217 name to be authenticated. In turn, it allows the attacker to 218 redirect the validation attempt to a host that they control. DNS 219 cache poisoning may be successful regardless of [RFC5452] if the 220 attacker can exploit packet fragmentation. By forcing a small on- 221 path maximum transmission unit (MTU) between the CA's DNS resolver 222 and a domain's authoritative DNS name server(s) using spoofed ICMP 223 messages, an attacker may be able to fragment DNS responses. 224 Correspondingly, by selecting the MTU so that fragmentation occurs 225 after immediately the headers, an attacker can control the second 226 part of a DNS packet, which then reassembles with with header of a 227 benign packet. In an ideal scenario, it allows an attacker to 228 overwrite the additional section of DNS responses, which the attacker 229 could then use to change the content of an additional section for a 230 MX, NS, CNAME, or any other type of record chain to point to a system 231 unde the attacker's control. 233 2.3.1. Detection 235 A CA can identify that this attack takes place by measuring the MTU 236 of inbound packets. If the MTU is smaller than 512 octets, the 237 operator must assume that the domain is under attack. 239 2.3.2. Defense 241 To mitigate DNS cache poisoning attacks, the CA must validate DNSSEC, 242 as already mandated by the CA browser forum [BFOR] for CAA records. 243 If DNSSEC cannot be validated, then the CA's resolvers must ignore 244 fragmented UDP packets with a UDP payload size of less than 512 245 octets. 247 The CA may require DNSSEC validation to succeed and TLSA records to 248 be in place for name servers of domains that require a MTU below 1000 249 octets. The CA may also opt to enforce DNS-over-TCP [RFC7766], DNS- 250 over-TLS [RFC7858], or DNS-over-HTTPS [RFC8484]. 252 As the additional section of incoming answers at the end of a DNS 253 response is particularly vulnerable to this attack, the CA's 254 resolvers must not use data from the additional section, but resolve 255 all names themselves. 257 2.4. DNS Cache Staleness Attacks 259 An attacker can execute an attack similar to resource-use-after-free 260 attacks if a CA's DNS resolver caches a DNS record although the 261 benign party may have updated the corresponding record. Then, the 262 CA's resolver might serve the cached record to the validation 263 systems. If the CA's resolver implements draft-ietf-dnsop-serve- 264 stale, then an attacker has an even longer window of opportunity. 265 This window can even be extended by launching a Denial-of-Service 266 (DoS) attack on a domain's authoritative name servers, in which case 267 the CA's resolver may serve a stale cached record with an expired TTL 268 for up to a week. 270 2.4.1. Detection 272 For a CA, these attacks are not distinguishable from legitimate 273 errors and downtimes. 275 2.4.2. Defense 277 To prevent DNS cache attacks, the CA's validation system's DNS 278 recursor must not serve cached records, and it must not implement 279 draft-ietf-dnsop-serve-stale. If an authoritative server is 280 unreachable, a certificate must not be issued. 282 3. Summary of CA Operational Improvements 284 In this section, we summarize the operational changes and mechanisms 285 to reduce the chance of issuing a certificate to an unauthorized 286 party. 288 3.1. Hardening Against Attacks Without DNS Control 290 If the validation target for a challenge (A/AAAA/NS/MX) is considered 291 at-risk or located in a network with a high resource churn, e.g., a 292 cloud provider or a residential ISP, then the CA should require the 293 domain for which the certificate is to be issued to be DNSSEC signed, 294 as well as a CAA and TLSA record to be present. If the domain is not 295 DNSSEC signed, or there is a mismatch between the TLSA record, then 296 the CA should consider the domain under attack and must not issue a 297 certificate. 299 If the CA can identify a certificate has been issued for the same 300 name before, it may consider requiring a challenge proving ownership 301 of the identified certificate, or a DNSSEC signed DNS challenge. 303 3.2. Multi-Vantage Point Validation 305 A CA should validate challenges from more than one network vantage 306 point. They should validate from at least three distinct 307 geographical and topological locations. If at least one of the CA's 308 validation nodes does not match the results of the other nodes, then 309 the CA must consider the requested domain to be under attack and must 310 not issue a certificate. 312 3.3. BGP Monitoring 314 A CA should monitor the current state of the BGP ecosystem, e.g., by 315 using a service similar to https://bgpmon.net [2]. If any network 316 prefix for the A, AAAA, MX, or NS records (or intermediate names and 317 CNAMEs) is considered to be under a BGP MitM attack, then the CA must 318 consider the requested domain to be under attack, and must not issue 319 a certificate. 321 3.4. DNS Resolver Configuration and Monitoring 323 To mitigate DNS fragmentation attacks, a CA's DNS resolvers should 324 ignore fragmented packets with UDP payload below 512 octets. If a CA 325 encounters UDP fragments of less than 1000 octets, it may require 326 DNSSEC and TLSA records to be presented and validated for the zone 327 before issuing a certificate. The CA's resolvers must not trust the 328 additional section of DNS responses and resolve all names on their 329 own. 331 To prevent attacks relying on stale DNS records, CAs must not utilize 332 draft-ietf-dnsop-serve-stale on their recursors. In fact, resolvers 333 must not serve records from their cache to the validation system. If 334 the authoritative DNS servers of a domain are unreachable, then the 335 CA must not issue a certificate. 337 3.5. DNSSEC Validation Failure and Lack of DNSSEC 339 If DNSSEC validation for a domain for which a certificate is 340 requested fails, the CA must consider the domain to be under attack, 341 and must not issue a certificate until DNSSEC validation is 342 successful. Depending on whether the domain is considered at-risk, 343 the CA may decide to not issue a certificate in the absence of DNSSEC 344 or CAA records. 346 3.6. Recent Domain Transfer 348 If a domain has been transfered within the last 72 hours, a CA may 349 consider the domain's state of ownership as insufficiently defined. 350 It may require proof of ownership of a prior certificate, or the zone 351 to be DNSSEC signed, and TLSA as well as CAA records to be present 352 before issuing a certificate. 354 4. Additional Validation Options 356 4.1. Proof of Ownership of a Prior Certificate 358 If a CA detects an attack, it MAY require the requesting party to 359 prove that it has access to the private key for a previously issued 360 certificate. This can be done implicitly by requiring validation 361 over HTTPS, using a validating prior certificate, or explicitly by 362 using a dedicated challenge. 364 4.1.1. Limitations 366 This option has several operational challenges. An domain owner's 367 infrastructure may not be design in a way that preserves prior 368 private keys, for example in large container setups. Similarly, the 369 prior key might have been lost due to data loss. Additionally, prior 370 certificates may have expired. 372 An attacker may have also obtained a prior private key by 373 compromising a system, or by having had legitimate authority over the 374 domain before. 376 5. IANA Considerations 378 There are no IANA considerations. 380 6. Security Considerations 382 This document itself serves as a summary of additional security 383 considerations. CA operators should carefully follow the 384 recommendations made in this document to prevent issuing certificates 385 to unauthorized parties. 387 7. Acknowledgements 389 8. References 391 8.1. Normative References 393 [BAMBOO] Birge-Lee, H., Sun, Y., Edmundson, A., Rexford, J., and P. 394 Mittal, "Bamboozling Certificate Authorities with BGP", 395 August 2018, 396 . 399 [BFOR] CA/Browser Forum, ., "Baseline Requirements for the 400 Issuance and Management of Publicly-Trusted Certificates", 401 October 2018, . 404 [CPOIS] IOActive Inc, ., "Black ops 2008: It's the end of the 405 cache as we know it", 2008, 406 . 408 [CSTRIFE] Borgolte, K., Fiebig, T., Hao, S., Kruegel, C., and G. 409 Vigna, "Cloud Strife: Mitigating the Security Risks of 410 Domain-Validated Certificates", February 2018, 411 . 413 [DVP] Brandt, M., Dai, T., Klein, A., Schulman, H., and M. 414 Waidner, "Domain Validation++ For MitM-Resilient PKI", 415 n.d., . 417 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 418 Resilient against Forged Answers", RFC 5452, 419 DOI 10.17487/RFC5452, January 2009, 420 . 422 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 423 D. Wessels, "DNS Transport over TCP - Implementation 424 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 425 . 427 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 428 and P. Hoffman, "Specification for DNS over Transport 429 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 430 2016, . 432 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 433 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 434 . 436 8.2. URIs 438 [1] https://bgpmon.net 440 [2] https://bgpmon.net 442 Authors' Addresses 444 Tobias Fiebig 445 TU Delft 447 Email: t.fiebig@tudelft.nl 449 Kevin Borgolte 450 Princeton University 452 Email: kevin@iseclab.org