idnits 2.17.1 draft-fiebig-acme-esecacme-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2018) is 2013 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: '1' on line 364 -- Looks like a reference, but probably isn't: '2' on line 366 -- Possible downref: Non-RFC (?) normative reference: ref. 'BAMBOO' -- Possible downref: Non-RFC (?) normative reference: ref. 'CSTRIFE' -- Possible downref: Non-RFC (?) normative reference: ref. 'DVP' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACME Working Group T. Fiebig 3 Internet-Draft TU Delft 4 Intended status: Standards Track K. Borgolte 5 Expires: April 24, 2019 Princeton University 6 October 21, 2018 8 Extended Security Considerations for the Automatic Certificate 9 Management Environment (ESecACME) 10 draft-fiebig-acme-esecacme-00 12 Abstract 14 By now, most Public Key Infrastructure X.509 (PKIX) certificates are 15 issued via the ACME protocol. Recently, several attacks against 16 domain validation (DV) have been published, including IP-use-after- 17 free, (forced) on-path attacks, and attacks on protocols used for 18 validation. In general, these attacks can be mitigated by 19 (selectively) requirering additional challenges, e.g., DNS 20 validation, proof of prior-key-ownership, or in severe cases even 21 extended validation (EV) instead of DV. This document provides a 22 list of critical cases and describes which mitigations can be used to 23 reduce the threat of issuing a certificate to an 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 April 24, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. IP/Resource-use-after-free . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Summary Indicators for Additional Validation . . . . . . . . 5 71 3.1. High-Resource-Reuse Source / Cloud Provider . . . . . . . 5 72 3.2. Multi-Vantagepoint Validation Mismatch . . . . . . . . . 5 73 3.3. BGP monitoring . . . . . . . . . . . . . . . . . . . . . 6 74 3.4. DNS Fragmentation . . . . . . . . . . . . . . . . . . . . 6 75 3.5. Failed DNSSEC Validation . . . . . . . . . . . . . . . . 6 76 3.6. Recent Domain Transfer . . . . . . . . . . . . . . . . . 6 77 3.7. High-Risk Domains . . . . . . . . . . . . . . . . . . . . 6 78 4. Additional Validation Options . . . . . . . . . . . . . . . . 6 79 4.1. Proof of Prior Key Ownership . . . . . . . . . . . . . . 6 80 4.1.1. Limitations . . . . . . . . . . . . . . . . . . . . . 7 81 4.2. Additional Use of a DNS Challenge . . . . . . . . . . . . 7 82 4.2.1. Limitations . . . . . . . . . . . . . . . . . . . . . 7 83 4.3. Additional Use of an Email Challenge . . . . . . . . . . 7 84 4.3.1. Limitations . . . . . . . . . . . . . . . . . . . . . 7 85 4.3.2. Limitations . . . . . . . . . . . . . . . . . . . . . 7 86 4.4. Out-of-Band and offline validation . . . . . . . . . . . 7 87 4.4.1. Limitations . . . . . . . . . . . . . . . . . . . . . 8 88 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 90 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 91 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 93 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 96 1. Introduction 98 By now, most Public Key Infrastructure X.509 (PKIX) certificates are 99 issued via the ACME protocol. The automated nature of ACME and its 100 heavy use of Domain Validation (DV) make it susceptible to a variety 101 of attacks. These include IP-use-after-free [CSTRIFE], (forced) on- 102 path attacks [BAMBOO], and attacks on protocols used for validation 103 [DVP], e.g., DNS. In general, these attacks can be mitigated by 104 (selectively) requirering additional challenges, e.g., DNS 105 validation, proof of prior-key-ownership, or in severe cases even 106 extended validation (EV) instead of DV. 108 This document provides a list of potential attacks and how they can 109 be detected. In addition, it describes which mitigations can be used 110 to reduce the threat of issuing a certificate to an unauthorized 111 party in case a potential attack has been detected. This section 112 also holds information on how these mitigations may impact the 113 usability of CAs using ACME to issue certificates. 115 2. Attacks 117 In this section we describe common attacks against DV, how they can 118 be detected, and which additional verification methods should be used 119 in case they are detected. 121 2.1. IP/Resource-use-after-free 123 IP- and Resource-use-after-free attacks occur if a domain owner 124 points a DNS record to a resource, which they later vacate without 125 deleting the DNS record. The resource, usually in cloud scenarios, 126 can then be allocated by another party. 128 For example, one might run a service for www.example.com on a virtual 129 machine hosted with a cloud provider. One then points the AAAA 130 record of www.example.com to the IPv6 address of that virtual 131 machine, 2001:DB8:1234:1234::1. However, when the operator 132 discontinues the service, they do not delete this DNS record, leading 133 to a stale record. If another client of the cloud provider now 134 allocates a virtual machine, and receives the same IPv6 address, they 135 can proof ownership of www.example.com to an ACME compliant CA. 136 These observations similarly hold for DNS records pointing to legacy 137 IPv4 resources (A records), mail servers in case of email 138 verification using the ACME protocol (MX records), http and https 139 delegations (SRV records), and DNS delegations if DNSSEC is not being 140 used (NS records). 142 2.1.1. Detection 144 This attack type is difficult to detect from the CAs site, without 145 operators taking precautions themselves, which we describe in the 146 following section. Heuristics CAs could use depend on the 147 availability of cooperation from operators, or require proof of prior 148 key ownership. 150 Ideally, operators will use TLSA records to pin the TLS public key 151 for a name, allowing a CA to match the TLSA record to the key for 152 which a certificate is requested. 154 If a DNS challenge is used, failed DNSSEC validation may point at a 155 resource-use-after-free attack. 157 A heuristic which does not require prior cooperation by operators is 158 using Certificate Transparency (CT) logs to identify prior 159 certificate issuances. Furthermore, CAA records could be used to 160 limit the number of CT logs which have to be searched by the ACME 161 compliant CA. Furthermore, if the CA with which a certificate has 162 been requested is also the only CA allowed in the CAA, it could check 163 the ACME account ID of prior requests vs. the one used in the current 164 request. 166 2.1.2. Defense 168 On a mismatch between the TLSA public key and the public key used in 169 the request, the CA must deny the requested certificate. In case of 170 pre-existing certificates, or a mismatch in the ACME account ID, the 171 operator should use an additional validation technique. If DNSSEC is 172 being used, the DNS challenge is an option. Given that NS and MX 173 records may also suffer from resource-use-after-free attacks, 174 unauthenticated DNS and email challenges are not an option. 176 Due to the usability implications of the available defense options a 177 CA may opt to only perform mitigation on high-risk resources, e.g., 178 known cloud operators and operators with a high customer churn. 180 2.2. (Forced)-on-path Attacks 182 If an attacker can perform a Monkey-in-the-Middle (MitM) attack by 183 controlling a part of the network path between the CA and the 184 resource used for validation, they can also impersonate an operator 185 and illegitimately obtain a certificate for a domain. Attackers may 186 force this on-path situation, e.g., using BGP shorter-prefix attacks 187 [BAMBOO]. 189 2.2.1. Detection 191 To detect on-path attacks, CAs should validate challenges from 192 multiple vantage points. For this purpose, the CA should operate a 193 geographically and topologically distributed system for verification. 194 This system should contain at least one validator per IP region 195 (AfriNIC, APNIC, ARIN, LACNIC, RIPE). Similarly, a CA may monitor 196 the BGP prefix from which it received a request with a service 197 similar to https://bgpmon.net [1]. Note that, depending how close 198 the attacker is to the victim, no path without malicious activity may 199 remain, generalizing the detection issue to that outlined for 200 resource-use-after-free attacks. 202 2.2.2. Defense 204 The same defense options as for resource-use-after-free attacks 205 apply. 207 2.3. DNS Cache Poisoning Attacks 209 Paper just appeared; will be included in the next version of this 210 draft. 212 2.3.1. Detection 214 2.3.2. Defense 216 3. Summary Indicators for Additional Validation 218 In this section, we summarize indicators for using an extended 219 validation machanism. 221 3.1. High-Resource-Reuse Source / Cloud Provider 223 If the validation target for a challenge (A/AAAA/NS/MX) is located in 224 a network with a high resources churn, e.g., a cloud or hosting 225 provider, or a residential ISP, extended validation requirements 226 should be considered. 228 3.2. Multi-Vantagepoint Validation Mismatch 230 If at least one of an CAs validation notes does not match the results 231 of the other nodes, the CA must consider the requested domain to be 232 under attack, necessitating either DNSSEC signed DNS validation, 233 proof of prior-key-ownership or EV. 235 3.3. BGP monitoring 237 If any prefix for either the A, AAAA, MX, or NS records (or 238 intermediate names and CNAMEs) is considered to be under a BGP MitM 239 attack by a service similar to https://bgpmon.net [2], the CA must 240 consider the requested domain to be under attack, necessitating 241 either DNSSEC signed DNS validation, proof of prior-key-ownership or 242 EV. 244 3.4. DNS Fragmentation 246 Paper just appeared; will be included in the next version of this 247 draft. 249 3.5. Failed DNSSEC Validation 251 If DNSSEC validation for a domain for which a certificate is 252 requested fails, the CA must consider the domain to be under attack, 253 necessitating either proof of prior-key-ownership or EV. 255 3.6. Recent Domain Transfer 257 If a domain has been transfered during the last 72 hours, the CA 258 should consider the domains ownership-state as insufficiently 259 defined, and reuire either proof of prior-key-ownership or EV. 261 3.7. High-Risk Domains 263 If a domain is a high-risk domain, CAs should only offer DNSSEC 264 signed DNS validation, proof of prior-key-ownership DV, or EV. 265 Domains are high risk domains if they are part of the Alexa top 266 10,000, belong to a CA, a software or hardware vendor, or a payment 267 provider. 269 4. Additional Validation Options 271 If one or multiple of the indicators above are detected by a CA, it 272 can employ one of the following additional validation options. 274 4.1. Proof of Prior Key Ownership 276 If a CA detects an attack, it can require the requesting party to 277 proof that it has access to the private key for a previously issued 278 certificate. This can be done implicitly, by requirering DV over 279 HTTPS, using a validating certificate, or, explicitly, by using a 280 dedicated ACME-challenge. 282 4.1.1. Limitations 284 This option has several operational challenges. An operator's 285 infrastructure may not be design in a way that preserves prior 286 private keys, for example in large container setups. Similarly, the 287 prior key might have been lost due to data-loss, or because the 288 systems holding it have been discontinued. Similarly, prior 289 certificates may have expired. 291 Furthermore, an attacker may have obtained a prior private key by 292 compromising a system, or by having had legitimate authority over the 293 domain before. 295 4.2. Additional Use of a DNS Challenge 297 If the CA detects an attack on one validation, e.g., web based DV, it 298 may use ACME-DNS instead. 300 4.2.1. Limitations 302 This challenge does not provide full resillience against all attacks. 303 It however increases the effort an adversary has to put into an 304 attack significantly. 306 4.3. Additional Use of an Email Challenge 308 If the CA detects an attack on one validation, e.g., web based DV, it 309 may use ACME-EMAIL instead. 311 4.3.1. Limitations 313 This challenge does not provide full resillience against all attacks. 314 It however increases the effort an adversary has to put into an 315 attack significantly. 317 4.3.2. Limitations 319 4.4. Out-of-Band and offline validation 321 If a party is unable to proof prior-key-ownership, and any of the 322 attack indicators outlined before is detected by the CA, the CA 323 should perform a traditional extended validation, requesting 324 appropriate documentation from the requesting party. 326 4.4.1. Limitations 328 EV is a manual process which prevents ACME from being used. It is 329 significantly more costly and smaller CAs may be unable to provide 330 the necessary infrastructure to support EV. 332 5. IANA Considerations 334 There are no IANA considerations. 336 6. Security Considerations 338 This document itself serves as a summary of additional security 339 considerations. Operators of CAs should carefully follow the 340 recommendations made in this document to prevent issuing certificates 341 to unauthorized parties. 343 7. Acknowledgements 345 8. References 347 8.1. Normative References 349 [BAMBOO] Mittal, P., "Bamboozling Certificate Authorities with 350 BGP", August 2018, 351 . 354 [CSTRIFE] Vigna, G., "Cloud Strife: Mitigating the Security Risks of 355 Domain-Validated Certificates", February 2018, 356 . 358 [DVP] Waidner, M., 359 "https://www.usenix.org/conference/usenixsecurity18/ 360 presentation/birge-lee", n.d.. 362 8.2. URIs 364 [1] https://bgpmon.net 366 [2] https://bgpmon.net 368 Authors' Addresses 370 Tobias Fiebig 371 TU Delft 373 Email: t.fiebig@tudelft.nl 374 Kevin Borgolte 375 Princeton University 377 Email: kevinbo@iseclab.org