idnits 2.17.1 draft-tweedale-acme-discovery-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 : ---------------------------------------------------------------------------- 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 (16 November 2020) is 1257 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) ** Obsolete normative reference: RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 2818 (ref. 'HTTP-TLS') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Tweedale 3 Internet-Draft Red Hat 4 Intended status: Standards Track 16 November 2020 5 Expires: 20 May 2021 7 Automated Certificate Management Environment (ACME) Service Discovery 8 draft-tweedale-acme-discovery-01 10 Abstract 12 This document specifies a DNS-based Service Discovery (DNS-SD) 13 profile that enables Automated Certificate Management Environment 14 (ACME) clients to locate ACME servers in their network environment. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 20 May 2021. 33 Copyright Notice 35 Copyright (c) 2020 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Simplified BSD License text 44 as described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. DNS-SD Profile . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1. Service Instance Name . . . . . . . . . . . . . . . . . . 3 53 3.2. PTR Records (Service Instance Enumeration) . . . . . . . 3 54 3.3. SRV Records . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.4. TXT Records . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.4.1. "path" attribute (ACME Directory Path) . . . . . . . 4 57 3.4.2. "i" attribute (ACME Identifier Types) . . . . . . . . 5 58 3.4.3. "v" attribute (ACME Validation Methods) . . . . . . . 5 59 3.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Client Behaviour . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. When to Perform Service Discovery . . . . . . . . . . . . 6 62 4.2. Candidate Parent Domains . . . . . . . . . . . . . . . . 7 63 4.3. DNS-SD Queries and Validation . . . . . . . . . . . . . . 7 64 4.3.1. Service Instance Enumeration . . . . . . . . . . . . 7 65 4.3.2. Service Instance Resolution . . . . . . . . . . . . . 8 66 4.3.3. Verifying the Server . . . . . . . . . . . . . . . . 8 67 4.4. ACME Operations . . . . . . . . . . . . . . . . . . . . . 9 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. "acme-server" Service Name Registration . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 71 6.1. TLS and Certificate Validation . . . . . . . . . . . . . 10 72 6.2. Parent Domain Selection . . . . . . . . . . . . . . . . . 10 73 6.3. DNS Security . . . . . . . . . . . . . . . . . . . . . . 11 74 6.4. Service Instance Delegation . . . . . . . . . . . . . . . 12 75 6.5. Multicast DNS . . . . . . . . . . . . . . . . . . . . . . 13 76 7. Normative References . . . . . . . . . . . . . . . . . . . . 13 77 8. Informative References . . . . . . . . . . . . . . . . . . . 14 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 80 1. Introduction 82 Automatic Certificate Management Environment [ACME] specifies a 83 protocol by which a client may, in an automatable way, prove control 84 of identifiers and obtain a certificate from an Certificate Authority 85 (the ACME server). However, it did not specify a mechanism by which 86 a client can locate a suitable ACME server. It is assumed that a 87 client will be configured to use a particular ACME server, or else 88 default to some well known, publicly accessible ACME service. 90 In some environments, such as corporate networks, it may be 91 impossible for ACME clients to obtain certificates from a publicly 92 accessible ACME servers, or an organisation may prefer clients to use 93 a particular server. Explicitly configuring ACME clients to use a 94 particular ACME server presents an administrative burden. 96 Furthermore, a service discovery mechanism could allow newly 97 connected systems to opportunistically locate an ACME server and 98 acquire certificates, without operator (human or otherwise) 99 intervention. 101 This document specifies a mechanism by which ACME clients can locate 102 an ACME server using DNS-Based Service Discovery [DNS-SD]. Network 103 administrators can advertise one or more ACME servers and express 104 their endorsed capabilities (identifier types and validation methods) 105 and priorities. Capable clients can discover the advertised services 106 and use the most preferred service that satisfies its requirements 107 and is reachable. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174] when, and only when, they appear in all 115 capitals, as shown here. 117 3. DNS-SD Profile 119 3.1. Service Instance Name 121 A DNS-SD Service Instance Name has the form: 123 . . 125 The portion of the Service Instance Name SHALL be "_acme- 126 server._tcp". 128 The portion of the Service Instance Name MAY be arbitrary 129 [Net-Unicode] text. That is, this specification does not further 130 constrain what is allowed by [DNS-SD]. 132 3.2. PTR Records (Service Instance Enumeration) 134 ACME clients discover ACME service instances by querying DNS PTR 135 [RFC1035] records with the name "_acme-server._tcp.", where 136 is a "parent domain" [RFC8552] known to or derived by the 137 client. Network administrators enable ACME Service Discovery by 138 creating such PTR records. 140 The target of each PTR record MUST be an ACME Service Instance Name, 141 which MUST have the same portion. The Service Instance 142 Name SHOULD have the same portion as the PTR owner name. 143 Administrators should delegate Service Instance Resolution to other 144 domains with caution; doing so may remove control of service 145 priorities and capability endorsement to a third party. Clients MUST 146 ignore a Service Instance Name if its portion differs from 147 the portion owner of the PTR record, unless explicitly 148 configured otherwise. 150 3.3. SRV Records 152 Each ACME service, identified by its Service Instance Name, MUST have 153 an SRV [DNS-SRV] record giving the domain name and TCP port where an 154 ACME server may be found. Each service instance SHOULD have exactly 155 one SRV record. 157 This specification alters the semantics of the SRV priority field 158 from that given by [DNS-SRV] and [DNS-SD]. For ACME Service 159 Discovery, the scope of the SRV priority field is the set of all SRV 160 records for all Service Instance Names enumerated for the parent 161 domain. This allows network administrators to establish an order of 162 preference among multiple distinct ACME service instance. 164 Because of the altered semantics of the SRV priority field, 165 implementers SHALL ignore the recommendation of [DNS-SD] that where a 166 single service instance is described by exactly one SRV record, the 167 priority and weight fields of the SRV record should be set to zero. 169 3.4. TXT Records 171 Each ACME service, identified by its Service Instance Name, MUST have 172 a TXT [RFC1035] record giving additional data about the service. 173 Each service instance SHOULD have exactly one TXT record. 175 The TXT record MUST be structured according to [DNS-SD] Section 6. 176 Attributes and their interpretations are set out in the following 177 subsections. The order of the attributes in the TXT record is 178 insignificant. 180 3.4.1. "path" attribute (ACME Directory Path) 182 The "path" attribute gives the path at which the ACME directory 183 resource is located on the HTTP server identified by the service 184 instance's SRV record. The attribute value MUST be a valid [URI]. 185 This attribute is REQUIRED. 187 3.4.2. "i" attribute (ACME Identifier Types) 189 The "i" attribute gives a list of ACME identifier types supported by 190 the service. Its value MUST be a comma-separated list of ACME 191 identifier types, without whitespace. The list MAY be empty, and 192 SHOULD only include values registered in the IANA ACME Identifier 193 Type registry [IANA-ACME-ID]. 195 The list of identifier types MAY be a subset of the identifier types 196 actually supported by the ACME server. As such, this attribute 197 constitutes the network administrators' endorsement to use the 198 service instance for the listed identifier types only, but does not 199 offer a means of enforcement. Clients MUST ignore services whose "i" 200 attribute does not list the identifier type(s) they require. 202 The "i" attribute is REQUIRED. An empty list of identifier means 203 that the network administrators acknowledge the presense of the ACME 204 service, but do not endorse its use. Clients MUST ignore a service 205 instance if its "i" attribute is not present, or present with no 206 value, or present with an empty value. 208 3.4.3. "v" attribute (ACME Validation Methods) 210 The "v" attribute gives a list of ACME validation methods (also 211 called "challenge types") supported by the service. Its value MUST 212 be a comma-separated list of ACME validation methods, without 213 whitespace. The list MAY be empty, and SHOULD only include values 214 registered in the IANA ACME Validation Methods registry 215 [IANA-ACME-VAL]. 217 The list of validation methods MAY be a subset of the validation 218 methods actually supported by the ACME server. As such, this 219 attribute constitutes the network administrators' endorsement to use 220 only the listed validation methods with this service, but does not 221 offer a means of enforcement. 223 The "v" attribute is OPTIONAL. If the "v" attribute is present with 224 a value (including an empty value), and that value does not include a 225 validation method the client is capable and willing to use, the 226 client MUST ignore the service instance. If the "v" attribute is 227 present with no value, the client MUST regard it as having an empty 228 value. If the "v" value is not present, the service is implicitly 229 endorsed for all validation methods; the client SHALL assume that the 230 server will support a validation method that the client is capable 231 and willing to use. 233 3.5. Examples 235 An organisation operates a corporate ACME server 236 "https://ca.corp.example/acme" (https://ca.corp.example/acme") for 237 issuing both TLS server certificates (identifier type "dns") and user 238 S/MIME certificates (identifier type "email"). 240 In case their own ACME service cannot be reached, the administrators 241 will advise clients to fall back to the public "Certs 4 All" service 242 at "https://certs4all.example/acme/v2" 243 (https://certs4all.example/acme/v2"). This service only supports 244 "dns" identifiers. 246 The following DNS configuration achieves these goals: 248 $ORIGIN corp.example. 250 _acme-server._tcp PTR CorpCA._acme-server._tcp 251 _acme-server._tcp PTR C4A._acme-server._tcp 253 CorpCA._acme-server._tcp SRV 10 0 443 ca.corp.example. 254 CorpCA._acme-server._tcp TXT "path=/acme" "i=email,dns" 256 C4A._acme-server._tcp SRV 20 0 443 certs4all.example. 257 C4A._acme-server._tcp TXT "path=/acme/v2" "i=dns" 259 Note that the "CorpCA" SRV priority of 10 ensures that "dns" clients 260 will first attempt to use the "CorpCA" service. If "CorpCA" is 261 unavailable they will try "C4A", which has an SRV priority of 20. 263 4. Client Behaviour 265 4.1. When to Perform Service Discovery 267 If an ACME client provides for explicit configuration of an ACME 268 server, and such configuration is provided, the client MUST use the 269 configured ACME server and MUST NOT perform service discovery. 271 Otherwise, if an ACME client supports service discovery, in the 272 absense of explicit configuration of an ACME server the client MAY 273 attempt to locate an ACME server using the mechanisms specified in 274 this document. A client MAY refuse to perform service discovery 275 unless its configuration explicitly enables it. 277 4.2. Candidate Parent Domains 279 To perform service discovery, the ACME client needs a prioritised 280 list of candidate parent domains. The client will perform DNS-Based 281 Service Discovery in each parent domain until a suitable service is 282 found, or the list is exhausted. 284 If an ACME client provides for explicit configuration of parent 285 domains to use for service discovery, and such configuration is 286 provided, the candidate parent domains SHALL be the configured 287 values. 289 Otherwise, there are a variety of ways an ACME client could choose 290 candidate parent domains, including: 292 * The host's fully-qualified domain name with one or more labels 293 removed from the left. 295 * The "search" domains from the host's DNS configuration. 297 * The Kerberos [RFC4120] realm of the host. 299 * The result of a PTR lookup on one of the host's non-loopback IP 300 addresses, with one or more labels removed from the left. 302 An ACME client MAY use any or all of these or other suitable methods 303 for identifying candidate parent domains. If multiple candidate 304 parent domains are identified the client MUST establish an order of 305 preference among them. If any candidate parent domain A is a 306 subdomain of another candidate parent domain B, the client MUST 307 preference A higher than B. 309 4.3. DNS-SD Queries and Validation 311 Service discovery begins with the most preferred candidate parent 312 domain. For each candidate parent domain, the client performs DNS-SD 313 Service Instance Enumeration and Service Instance Resolution until a 314 suitable server is found, or the candidate parent domains are 315 exhausted. 317 4.3.1. Service Instance Enumeration 319 The ACME client SHALL query the DNS PTR records for 320 "." where is "_acme-server._tcp" and 321 is the candidate parent domain name. For each record 322 returned, the client SHALL verify that the target is an ACME Service 323 Instance Name, i.e. that is has the form: 325 .. 327 where instance is arbitrary Net-Unicode text, and SHALL ignore 328 targets that are not valid ACME Service Instance Names. 330 If is different from , the network 331 administrator of has delegated control of the location, 332 priority and service attributes of the service instance to 333 , which may be a third party. Clients MUST ignore a 334 Service Instance Name if its portion differs from the 335 portion owner of the PTR record, unless explicitly 336 configured otherwise. 338 4.3.2. Service Instance Resolution 340 The ACME client now has a set of ACME Service Instance Names. For 341 each ACME Service Instance Name, the client SHALL query the SRV and 342 TXT records for that name, and collect the results as (SRV,TXT) 343 pairs. The client could do this sequentially, or with some degree of 344 concurrency. The client SHALL ignore any service instance that is 345 missing either the SRV or TXT record (or both). Although each 346 service instance SHOULD have exactly one SRV record and exactly TXT 347 record, if multiple SRV and/or multiple TXT records are returned, the 348 client SHALL use the cartesian product of these. 350 The client MUST exclude any service instances whose TXT "path" 351 attribute is missing or invalid, or whose "i" or "v" attributes do 352 not contain acceptable values. 354 4.3.3. Verifying the Server 356 The client now has a list of suitable ACME service instances 357 represented as (SRV,TXT) pairs. The client SHALL attempt to contact 358 servers in an order determined by the SRV priority and weight fields, 359 according to [DNS-SRV]. 361 For each attempt, the client SHALL construct the URI: 363 https://: 365 where is the SRV target, is the SRV port value and 366 is the value of the TXT "path" attribute. If the SRV value is 367 443 the client MAY omit ":". The client SHALL perform an HTTPS 368 [HTTP] GET request for this URI and SHALL attempt to parse the 369 response body as an ACME directory object. If successful, service 370 discovery has succeeded; the client SHALL use the constructed URI as 371 the ACME server, and SHOULD NOT process the remaining service 372 instances or candidate parent domains. 374 If none of the service instances yield a valid ACME directory object, 375 service discovery for the current parent domain has failed. Failure 376 modes include: 378 * No PTR records at "_acme-server._tcp." 380 * No eligible service instances, according to the TXT attributes 382 * All HTTPS requests to eligible service instances either failed or 383 did not response with a valid ACME directory object. 385 In this case, the client MAY retry service discovery with the next 386 most preferred candidate parent domain. The client MAY continue 387 retrying until no candidate parent domains remain, or MAY give up 388 earlier (e.g. after a fixed number of attempts). 390 If service discovery does not succeed, an ACME client MAY fall back 391 to a default ACME server (e.g. a publicly accessible ACME server). 393 4.4. ACME Operations 395 An ACME client MAY record (cache) the URI of the ACME server located 396 via service discovery and MAY use the cached server for new account 397 and new order operations, without performing service discovery each 398 time. 400 When storing data about accounts and orders, ACME clients SHOULD 401 record the URI of the actual ACME server used. When retrieving or 402 revoking certificates or performing account operations, the client 403 SHOULD use the recorded URI to contact the ACME server and SHOULD NOT 404 perform service discovery. 406 When renewing or replacing a certificate, if the recorded ACME server 407 cannot be contacted or fails to issue a certificate, a client MAY 408 perform service discovery to attempt to locate an alternative ACME 409 server that may be able to issue the certificate. 411 5. IANA Considerations 413 5.1. "acme-server" Service Name Registration 415 Per [RFC6335], please add the following entry to the Service Name and 416 Transport Protocol Port Number Registry [IANA-SN]: 418 Service Name acme-server 419 Port Number N/A 420 Transport Protocol(s) tcp 421 Description Automated Certificate Management Environment 422 (ACME) server 423 Assignee IESG 424 Contact IETF Chair 425 Reference (this document) 426 Assignment Notes Defined TXT keys: path, i, v 428 6. Security Considerations 430 6.1. TLS and Certificate Validation 432 Use of TLS is REQUIRED by [ACME]. [X.509] supports the 433 uniformResourceIdentifier and [SRVName] name types in the Subject 434 Alternative Name extension, and [RFC6125] describes the DNS-ID, URI- 435 ID and SRV-ID identifier types and how to validate them against a 436 server's X.509 certificates. 438 However, the uniformResourceIdentifier and SRVName name types are not 439 in widespread use and not widely supported by TLS libraries or 440 certificate authorities. [HTTP-TLS] does not describe the use of 441 either of these name types for HTTP services. Therefore when an ACME 442 server was located via service discovery its certificate MUST be 443 validated according to both [X.509] and [RFC6125], using the target 444 of the service's SRV record as the DNS-ID. 446 6.2. Parent Domain Selection 448 An attacker who is able to influence an ACME client's candidate 449 parent domains can influence which ACME server the client uses, or 450 cause service discovery to fail. The attacker could use this 451 capability to perform a denial of service against the ACME client 452 (i.e. the client cannot acquire or renew a certificate), or against 453 parties that validate certificates issued to the client (because they 454 do not trust the issuing CA or because the certificate is invalid in 455 some way), or against a target ACME server (by directing many clients 456 to it). ACME client implementers should carefully consider which 457 methods of determining the parent domain(s) are appropriate for their 458 use cases, and the security implications of their chosen methods. 460 An ACME client might derive candidate parent domains by removing one 461 or more labels from the left side of some other DNS name (e.g. the 462 host name of the client's machine). If too many labels are removed, 463 the ACME client could perform DNS queries in zones outside the 464 control of the organisation that operates the ACME client. As a 465 result, the ACME client could locate and use an ACME server that the 466 organisation does not intend. 468 To mitigate this risk, it is RECOMMENDED that clients limit the 469 amount of label pruning that occurs. It is not possible to make a 470 concrete recommendation that is suitable for all environments. 471 Implementers must consider what is appropriate for their use cases 472 and environments. The candidate parent domain ordering requirements 473 also mitigate this risk. 475 6.3. DNS Security 477 Without ACME Service Discovery, an ACME client must be configured or 478 hard-coded to use a particular ACME server, specified as the HTTPS 479 URI of the server's directory resource. Typically the host will be a 480 DNS name rather than an IP address, and one or more DNS queries are 481 necessary to resolve the host's DNS name to an IP address. 483 When service discovery is used, the URI of the ACME server is 484 obtained from a DNS URI record. If an attacker is able to spoof the 485 _acme-server URI record for a candidate parent domain name, the 486 attacker could cause service discovery to fail or could direct the 487 client to an ACME server of the attacker's choosing. This could 488 constitute a denial of service attack against the client, against 489 parties that validate certificates issued to the client, or against 490 the target server. 492 Therefore it is RECOMMENDED that URI records used for ACME Service 493 Discovery be secured using DNSSEC. It is RECOMMENDED that ACME 494 clients make DNS URI queries via DNSSEC-validating stub or recursive 495 resolvers. 497 Some methods of candidate parent domain selection may involve DNS 498 queries. For example, a client could query PTR records to find a 499 host name, from which it derives a candidate parent domain. 500 Implementers must consider the security of DNS data used for parent 501 domain selection. 503 6.4. Service Instance Delegation 505 As noted in [DNS-SD] Section 4.2, it is possible for a service 506 enumeration in one domain to return the names of services in a 507 different domain. It is necessary to consider the security 508 implications for ACME Service Discovery in this scenario. 510 Consider an organisation that operates a corporate ACME server 511 "https://ca.corp.example/acme" (https://ca.corp.example/acme") for 512 issuing user "email" certificates, and intends to use the public ACME 513 CA "https://certs4all.example/acme/v2" 514 (https://certs4all.example/acme/v2") for "dns" certificates. If the 515 public CA has DNS-SD service instance records in their own domain: 517 $ORIGIN certs4all.example. 518 C4A._acme-server._tcp SRV 10 0 443 certs4all.example. 519 C4A._acme-server._tcp TXT "path=/acme/v2" "i=dns" 521 then the network administrators could avoid maintaining variants of 522 these records in their own domain, with a configuration such as: 524 $ORIGIN corp.example. 526 _acme-server._tcp PTR CorpCA._acme-server._tcp 527 _acme-server._tcp PTR C4A._acme-server._tcp.certs4all.example. 529 CorpCA._acme-server._tcp SRV 10 0 443 ca.corp.example. 530 CorpCA._acme-server._tcp TXT "path=/acme" "i=email" 532 This is a risky configuration because, for some of the service 533 instances, a third party controls both SRV priority and weight, and 534 the TXT attributes, which are used to select eligible service 535 instances. In the configuration above, everything works as intended. 536 ACME "email" clients go to "CorpCA" and "dns" clients go to "C4A". 537 But if the administrators of certs4all.example change their service 538 instance records to: 540 $ORIGIN certs4all.example. 541 C4A._acme-server._tcp SRV 5 0 443 certs4all.example. 542 C4A._acme-server._tcp TXT "path=/acme" "i=dns,email" 544 then the organisation's "email" clients will now prefer "C4A". This 545 could lead to denial of service (C4A may not be trusted by mail 546 agents and systems) or breaches of privacy (corporate email addresses 547 will be exposed to the CA, and possibly to the world via Certifiate 548 Transparency [RFC6962]) 549 For these reasons, delegation of service instance records to third 550 parties is NOT RECOMMENDED. As stated elsewhere in this document, 551 clients MUST ignore Service Instance Names whose part 552 differs from the parent domain that owns the PTR records, unless 553 explicitly configured otherwise. 555 6.5. Multicast DNS 557 DNS-SD is compatible with Multicast DNS [RFC6762]. Devices on the 558 local network can advertise their services by responding to mDNS 559 Service Instance Enumeration (PTR) queries. For example, a client 560 can search for printers by querying "_printer._tcp.local.", and 561 printers respond with their Service Instance Names (and will also 562 respond to requests for the associated SRV and TXT records). 564 There may be real use cases for ACME service discovery via DNS-SD/ 565 mDNS. But there are also risks. The same issues arise as for 566 service instance delegation, but these are compounded because the 567 parent domain is always "local." and service providers (devices) may 568 be ephemeral. This increases the risk of denial of service for ACME 569 clients and relying parties. 571 The author of this document does not wish to dissuade people from 572 considering use cases and developing and analysing an ACME service 573 discovery profile for DNS-SD/mDNS. It remains an open topic. This 574 specification only requires that a client MUST NOT use DNS-SD/mDNS 575 for ACME Service Discovery unless explicitly configured to do so. 577 7. Normative References 579 [ACME] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 580 Kasten, "Automatic Certificate Management Environment 581 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 582 . 584 [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service 585 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 586 . 588 [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 589 specifying the location of services (DNS SRV)", RFC 2782, 590 DOI 10.17487/RFC2782, February 2000, 591 . 593 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 594 Protocol (HTTP/1.1): Message Syntax and Routing", 595 RFC 7230, DOI 10.17487/RFC7230, June 2014, 596 . 598 [Net-Unicode] 599 Klensin, J. and M. Padlipsky, "Unicode Format for Network 600 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 601 . 603 [RFC1035] Mockapetris, P., "Domain names - implementation and 604 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 605 November 1987, . 607 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 608 Verification of Domain-Based Application Service Identity 609 within Internet Public Key Infrastructure Using X.509 610 (PKIX) Certificates in the Context of Transport Layer 611 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 612 2011, . 614 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 615 Resource Identifier (URI): Generic Syntax", STD 66, 616 RFC 3986, DOI 10.17487/RFC3986, January 2005, 617 . 619 [X.509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 620 Housley, R., and W. Polk, "Internet X.509 Public Key 621 Infrastructure Certificate and Certificate Revocation List 622 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 623 . 625 8. Informative References 627 [HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, 628 DOI 10.17487/RFC2818, May 2000, 629 . 631 [IANA-ACME-ID] 632 IANA, "ACME Identifier Types", 633 . 636 [IANA-ACME-VAL] 637 IANA, "ACME Validation Methods", 638 . 641 [IANA-SN] IANA, "Service Name and Transport Protocol Port Number 642 Registry", . 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 651 Kerberos Network Authentication Service (V5)", RFC 4120, 652 DOI 10.17487/RFC4120, July 2005, 653 . 655 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 656 Cheshire, "Internet Assigned Numbers Authority (IANA) 657 Procedures for the Management of the Service Name and 658 Transport Protocol Port Number Registry", BCP 165, 659 RFC 6335, DOI 10.17487/RFC6335, August 2011, 660 . 662 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 663 DOI 10.17487/RFC6762, February 2013, 664 . 666 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 667 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 668 . 670 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 671 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 672 May 2017, . 674 [RFC8552] Crocker, D., "Scoped Interpretation of DNS Resource 675 Records through "Underscored" Naming of Attribute Leaves", 676 BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, 677 . 679 [SRVName] Santesson, S., "Internet X.509 Public Key Infrastructure 680 Subject Alternative Name for Expression of Service Name", 681 RFC 4985, DOI 10.17487/RFC4985, August 2007, 682 . 684 Author's Address 686 Fraser Tweedale 687 Red Hat 689 Email: ftweedal@redhat.com