idnits 2.17.00 (12 Aug 2021) /tmp/idnits19090/draft-nygren-service-bindings-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 are 5 instances 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 -- The document date (July 3, 2014) is 2878 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 750 == Outdated reference: draft-ietf-tls-applayerprotoneg has been published as RFC 7301 ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) == Outdated reference: draft-ietf-httpbis-alt-svc has been published as RFC 7838 == Outdated reference: draft-ietf-httpbis-http2 has been published as RFC 7540 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Nygren 3 Internet-Draft Akamai Technologies 4 Intended status: Standards Track July 3, 2014 5 Expires: January 4, 2015 7 Service Binding DNS Records (DNS B) 8 draft-nygren-service-bindings-00 10 Abstract 12 This document describes a DNS "B" RR which binds together information 13 needed to establish connection to a service across multiple protocol 14 layers, including the location of the server, the application-level 15 protocol, and security bootstrap information. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 4, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Overview and rationale . . . . . . . . . . . . . . . . . . . 2 52 1.1. Relationship to SRV RR type . . . . . . . . . . . . . . . 3 53 1.2. Introductory example . . . . . . . . . . . . . . . . . . 3 54 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 4 55 3. Applicability Statement . . . . . . . . . . . . . . . . . . . 4 56 4. The Service Binding Record . . . . . . . . . . . . . . . . . 5 57 4.1. B record RDATA encoding . . . . . . . . . . . . . . . . . 6 58 4.2. Service Binding Parameters . . . . . . . . . . . . . . . 6 59 4.3. Standard Service Binding Parameters . . . . . . . . . . . 7 60 4.4. Optional Security Parameters . . . . . . . . . . . . . . 8 61 4.5. Examples for other possible future Parameters . . . . . . 9 62 5. Selecting a Service Binding to Use . . . . . . . . . . . . . 10 63 5.1. Handling B record responses . . . . . . . . . . . . . . . 10 64 5.2. Handling a lack of Service Binding records . . . . . . . 10 65 6. Operational Examples . . . . . . . . . . . . . . . . . . . . 11 66 6.1. Example: Moving a service and domain between operators . 11 67 7. Open Areas for Discussion . . . . . . . . . . . . . . . . . . 12 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 11.2. Informative References . . . . . . . . . . . . . . . . . 16 74 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Overview and rationale 79 As the protocols underlying services evolve to provide enhanced 80 performance and security properties, clients have an increasing 81 number of ways to contact any given service on a domain. Contacting 82 any given implementation instance of a service on a domain may 83 require parameters across multiple protocol layers. Different 84 servers with different address records may even desire to implement 85 the same service, especially in the case where older protocols lacked 86 functionality required to make a smooth transition to newer 87 protocols. 89 The DNS B RR allows administrators to bind together the parameters 90 needed to contact an instance of a service on a domain into a single 91 record, or "service binding". Multiple service bindings (multiple B 92 records in an RRset) may provide a client with multiple ways to 93 contact a given service, each with its own associated protocol(s) and 94 related parameters. 96 Service bindings give clients a single DNS query [RFC1035] to resolve 97 to obtain the B RRset for a service and domain. Clients are able to 98 then filter B RRs based on which protocols they support. After 99 selecting an B RR within this RRset, it should then be clear to the 100 client whether other RRs need to be resolved prior to establishing 101 communication with the service for a given protocol. 103 1.1. Relationship to SRV RR type 105 The B RR has close similarities of purpose to the SRV RR [RFC2782] 106 but the B RR covers additional use-cases, including: 108 o Multiple application-level protocol implementations for a service 110 o Providing information for improving the security of a connection 111 to a service (such as constraints on server certificates as well 112 as handshake encryption keys) 114 o A single RRset name that can be queried that covers multiple 115 lower-level protocol implementations for a service, such as when 116 the same service is offered over multiple transport-layer 117 protocols 119 Similar to SRV, the B RR provides: 121 o Multiple address records for a given domain 123 o Priorities and weights to guide client selection 125 o The information needed to contact a given server (such as target 126 hostname and port number) is bound together in a single record 128 1.2. Introductory example 130 If a web browser supporting B records wishes to fetch the URL 131 https://www.example.com/, it would use the URI scheme ("https") as 132 the the service and perform a lookup of: 134 QNAME=_https._b.www.example.com, QCLASS=IN, QTYPE=B 136 which might return an RRset with multiple resource records: 138 1 0 server-experimental.example.com. 139 { "a": "h2", "t": "fictionfast", "tp": 9443 } 141 3 0 server-primary.example.com. 142 { "a": "h2", "t": "tcp", "tp": 443, 143 "dane": "_443._tcp.server-primary-www-cert.example.com.", 144 "tlshp": ["JgxJkCv0va0", "OBZVN8LPo+SB9eQ/"] } 146 5 0 server-legacy.example.com. 147 { "a": "http/1.1", "t": "tcp", "tp": 443, 148 "dane": "_443._tcp.server-legacy-www-cert.example.com" } 150 The first of these specifies using HTTP/2 over a fictional 151 experimental secure transport protocol "fictionfast" over UDP port 152 9443 from the server(s) with address record server- 153 experimental.example.com. 155 For clients not supporting this first item, HTTP/2 156 [I-D.ietf-httpbis-http2] is available over TLS via TCP port 443 with 157 certificate information available from a DANE record at 158 "_443._tcp.server-primary-www-cert.example.com." and with TLS 1.3 159 server handshake encryption parameters specified 160 [I-D.rescorla-tls13-new-flows] from server(s) with the server- 161 primary.example.com address record. 163 For clients not supporting HTTP/2, a separate set of legacy servers 164 is available for HTTP/1.1 which happens to have different certificate 165 information available from a separate DANE record. 167 *NOTE:* HTTPS is selected above for illustrative purposes only, and 168 the HTTPS examples within this document should not be considered to 169 be a definitive statement on the way for HTTPS to use B records. 171 2. Notational Conventions 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 177 3. Applicability Statement 179 In general, it is expected that service binding records will be used 180 by clients for applications where the relevant protocol specification 181 indicates that clients should use the B record. Such specification 182 MUST define the symbolic name to be used in the Service field of the 183 B record as described below. Such specification MUST also define the 184 Parameters available as well as their interpretation. It also MUST 185 include security considerations. Service binding records SHOULD NOT 186 be used in the absence of such specification. 188 The current version of this proposal includes specifics for how 189 service bindings might be used in the context of HTTP/2 as well as 190 TLS/1.3. It is expected that those would be split out to a separate 191 draft. 193 4. The Service Binding Record 195 The service binding record is of the format: 197 _Service._b.Name TTL Class B Priority Weight Target Parameters 199 where: 201 Service The symbolic name of the desired service. 202 An underscore (_) is prepended to the service identifier to avoid 203 collisions with DNS labels that occur in nature. In many 204 specifications it is expected that the Service is likely to be the 205 same as the URI Scheme [RFC3986] (such as "http" or "https"). 207 _b The literal label "_b", intended to prevent collisions with DNS 208 labels that occur in nature. 210 Name The domain this RR refers to. Similar to SRV RR [RFC2782], the 211 name one searches for is not this name. 213 TTL Standard DNS meaning [RFC1035]. 215 Class Standard DNS meaning [RFC1035]. B records occur in the IN 216 Class. 218 Priority The priority of this service binding. After filtering 219 service bindings for protocols that it supports, the client MUST 220 attempt to contact the target host with the lowest-numbered 221 priority it can reach; target hosts with the same priority SHOULD 222 be tried in an order defined by the weight field. The range is 223 0-65535. This is a 16 bit unsigned integer in network byte order. 225 Weight A server selection mechanism. The weight field specifies a 226 relative weight for entries with the same priority. Larger 227 weights SHOULD be given a proportionately higher probability of 228 being selected. The range of this number is 0-65535. This is a 229 16 bit unsigned integer in network byte order. Domain 230 administrators SHOULD use Weight 0 when there isn't any server 231 selection to do, to make the RR easier to read for humans (less 232 noisy). In the presence of records containing weights greater 233 than 0, records with weight 0 should have a very small chance of 234 being selected. Clients SHOULD use the same weight selection 235 algorithm as described in [RFC2782]. 237 Target The domain name of the target host. There MUST be one or 238 more address records for this name (A RR's and/or AAAA RR's, or 239 their most modern equivalent). The name MAY be a CNAME alias (in 240 the sense of [RFC1034]). Implementors are encouraged, but not 241 required, to return the address record(s) in the Additional Data 242 section where possible and appropriate. Unless and until 243 permitted by future standards action, name compression is not to 244 be used for this field. 246 The special target value of "." indicates that this service is not 247 available on this domain. When used, the RRset MUST contain only 248 this single record. However, the record MAY have additional 249 parameters (not yet defined), such as to specify that an alternate 250 service should be used instead. 252 Parameters A collection of tag:value parameters specifying 253 additional attributes for this service binding. These are encoded 254 in canonicalized CBOR [RFC7049] using the map data type. Their 255 textual representation is JSON, with binary byte arrays (such as 256 literal keys) being base64 [RFC4648] encoded. While some tags are 257 defined here, additional tags may be defined in the specifications 258 for the particular Service, as well as in specifications for 259 additional protocols for implementing the Service. 261 4.1. B record RDATA encoding 263 _A more formal definition of the RDATA encoding and parameter textual 264 representation syntax will be included in a future version of this 265 draft once the core concepts have stabilized._ 267 4.2. Service Binding Parameters 269 The parameters of the B record provide extensibility, allowing 270 additional parameters to be specified depending on the particular 271 service and protocol. 273 Clients MUST use parameters to filter out service bindings specifying 274 protocols or other parameters that they do not support, as specified 275 by those parameters. 277 Any parameters not specified in the initial specification of Service 278 Binding usage for a given Service and protocol combination must be 279 capable of being safely ignored by a client. 281 Some parameters MUST NOT be used by a client unless all relevant DNS 282 records can be securely validated, such as with DNSSEC [RFC2535]. 283 This means that both the B record, any aliases leading to it, and any 284 aliases and records leading from names specified in that parameter 285 must be validated. This is discussed in more length in Security 286 Considerations [1]. 288 The specification for any given parameter SHOULD include: 290 o The tag used to identify the parameter 292 o The valid type and allowed value ranges for the parameter 294 o Whether the parameter is optional, and its default value if not 296 o What is the behavior if the DNS records can not be securely 297 validated 299 o A description of how the client should use the parameter value 301 4.3. Standard Service Binding Parameters 303 Application Layer Protocol (tag "a") A string representing the 304 application layer protocol to be used when contacting the service. 305 The valid values are service-dependent and should be the same 306 values as used in ALPN [I-D.ietf-tls-applayerprotoneg]. For 307 example, "h2" represents HTTP/2. 309 If not specified, the default application-layer protocol for the 310 given service is assumed. 312 Clients MUST filter out service bindings utilizing application 313 layer protocols that they do not support or recognize, as well as 314 to use the proper application protocol when contacting servers 315 using this binding. 317 Transport Layer Protocol (tag "t") A string representing the 318 transport layer protocol to be used when contacting the service. 319 The valid values are service dependent. For example, "tcp" is 320 likely to be used for many services. 322 If not specified, the default transport-layer protocol for the 323 given service is assumed. 325 Clients MUST filter out service bindings utilizing transport layer 326 protocols that they do not support or recognize, as well as to use 327 the proper transport protocol when contacting servers using this 328 binding. 330 _Note for discussion: it may make sense to omit this as a separate 331 parameter and to have the Application Layer Protocol tag describe 332 the entire stack, as in_ [I-D.ietf-httpbis-http2]. 334 Transport Layer Port (tag "tp") An integer specifying the transport 335 layer protocol port to be used when contacting the service. The 336 valid values are transport layer protocol dependent. 338 If not specified, the default port for the given service and 339 transport protocol is assumed. 341 4.4. Optional Security Parameters 343 The following parameters should likely move to separate 344 specifications: 346 DANE Certificate Controls (tag "dane") The value of this optional 347 parameter is a DNS domain name pointing to a DANE TLSA [RFC6698] 348 record associated with this service binding. 350 This is particularly useful to bind TLSA records with specific 351 servers, especially in the case where different servers have 352 different certificates and perhaps even different operators. 354 This is also useful to indicate that TLSA records are available 355 (to reduce the need for speculative DNS lookups) 357 If relevant DNS records can not be securely validated, clients 358 MUST NOT loosen their security policies based on the TLSA record. 359 However, clients MAY use the record to apply more restrictive 360 policies even if the TLSA record could not be securely validated. 362 In particular, if this parameter is present, a client SHOULD 363 resolve the named TLSA record and use it to constrain the TLS 364 server certificates that it will accept. If the the relevant DNS 365 records can not be securely validated, the TLSA record must only 366 be used in addition to policies already enforced by the client. 367 For example, if a "CA Constraint" certificate usage is specified, 368 then this SHOULD limit the CA allowed to those specified in the 369 TLSA record(s), but only if the CA is also in a trust chain that 370 the client would already accept. 372 TLS Handshake Parameters (tag "tlshp") This optional parameter 373 specifies ServerParameters for bootstrapping the TLS 1.3 374 handshake, such as for encrypting the SNI and other parts of the 375 ClientHello to make them less vulnerable to passive eavesdropping 376 [I-D.rescorla-tls13-new-flows]. 378 The value of this parameter is a list containing the binary values 379 of the ServerParameter label followed by the ServerDHParams or 380 ServerECDHParams. 382 Clients MAY use these values even if the B record is not securely 383 validated, as the intent of these parameters is to protect against 384 passive eavesdropping. Note that there may be limited value in 385 handshake encryption unless DNS lookups are also encrypted. 387 4.5. Examples for other possible future Parameters 389 Some of these may also make sense to include in an future version of 390 this draft: 392 o A parameter indicating that this DNS record must have been 393 securely validated (such as with DNSSEC) or must otherwise be 394 skipped. This could allow for incremental deployment of DANE- 395 managed certificates on some alternate set of servers even without 396 universal DNSSEC adoption. 398 o Minimum and/or maximum version of a protocol supported. (For 399 example, this could be helpful to mitigate downgrade attacks.) 401 o Which extensions to a protocol are supported, allowing a client to 402 opportunistically send them in its handshake. 404 o Hints as to whether a target address record has A and/or AAAA 405 records. (Careful consideration would need to be given to how 406 this played with DNS64 as well as other transition technologies.) 407 A reasonable compromise would be to have a hint indicating that a 408 AAAA record was available and encouraged (such that clients might 409 wait longer to get a response from nameservers) as well as a 410 separate hint indicating that no A record is available. 412 o Selected Service Binding Indicator - a label that can be passed 413 from client to server indicating which service binding it 414 selected. This may be helpful for both load reporting/feedback, 415 and diagnostics. 417 o HSTS-style [RFC6797] indicator parameter. This would be returned 418 along with a target of "." on a less secure service to indicate 419 that a more secure scheme/service should be used (such as "https" 420 instead of "http"). This might be a boolean "sts=1" parameter, 421 such as with a record like: 423 _http._b.www.example.com 2D IN B 0 0 . { "sts": 1 } 425 5. Selecting a Service Binding to Use 427 When a client supporting Service Bindings wishes to make a connection 428 to a service, it SHOULD query the B records for the service. It MAY 429 choose to opportunistically also issue DNS queries for the address 430 records (eg, A and AAAA) to reduce the latency for the case where no 431 B record is available. 433 5.1. Handling B record responses 435 In the case where an RRset for B records is returned, the client 436 should: 438 1. Filter out any B RR's from the RRset which it does not support. 439 In particular, it MUST ignore any B records containing an 440 Application Layer Protocol that is unknown, unsupported, or 441 explicitly disallowed for the particular service. 443 2. The remaining B RR's should be sorted by priority. An entry 444 should be selected from the top priority (lowest numeric priority 445 value). It multiple records have the same priority, the 446 weighting algorithm specified in [RFC2782] SHOULD be used to 447 order them. 449 3. The client should attempt to contact the service using the 450 parameters specified in the first selected record from the sorted 451 list. 453 4. If a given attempt fails, the client MAY attempt to contact the 454 service using the next record in the sorted list. After some 455 number of tries, the client MAY attempt to contact the service 456 directly using the address records for the domain. 458 5.2. Handling a lack of Service Binding records 460 Not all clients will immediately implement Service Binding records 461 for any given Service, and administrators may not always put Service 462 Binding records in-place. Just as importantly, experiments have 463 shown that new DNS RR types take awhile before they are accessible to 464 most clients. (_Reference needed_) 466 As such, client SHOULD directly lookup and use the address records 467 for the domain name when no valid B record is unavailable. In this 468 case, the default application and transport layer protocols SHOULD be 469 used. Clients and Servers MAY then use inline upgrade or signaling 470 mechanisms such as AltSvc [I-D.ietf-httpbis-alt-svc] or ALPN 471 [I-D.ietf-tls-applayerprotoneg] for upgrading to newer protocols 472 instantiating the Service. 474 6. Operational Examples 476 A few illustrative examples follow to help to demonstrate how Service 477 Binding records might be used. More examples may be added in a 478 future version of this draft. (_In particular, an example should be 479 added on how a client might resolve and use some specific B records.) 481 6.1. Example: Moving a service and domain between operators 483 A common deployment model is for different administrators (and 484 sometimes entirely separate organizations) to operate the DNS for a 485 domain than those that operate a service on the domain. Either or 486 both might even be out-sourced to separate entities such as a 487 hosting/infrastructure provider or Content Delivery Network (CDN). 488 It is critical that it be possible to move domains and services 489 between operators and administrators without any disruption in 490 service and with minimal coordination between the different 491 organizations. Service Binding records simplify this by allowing a 492 delegation of name via a single DNS alias per service/domain. All 493 other properties (such as TLSA records) then follow directly along 494 from this. 496 For example with: 498 _https._b.www.example.com. 499 6H IN CNAME _https._b.www.example.com.example-1.net. 501 _https._b.www.example.com.example-1.net. 502 6H IN B 0 0 server-primary.example-1.net. 503 { "a": "h2", 504 "dane": "_443._tcp.server-primary-www-cert.example-1.net.", 505 "tlshp": ["JgxJkCv0va0", "OBZVN8LPo+SB9eQ/"] } 507 the administrator of the example.com DNS zone delegated control over 508 www.example.com to an operator example-1.net. 510 In the example above, it would be recommended for the example-1.net 511 authorities to also return ADDITIONAL records for the "server- 512 primary.example-1.net." address records and for the 513 "_443._tcp.server-primary-www-cert.example-1.net." TLSA record along 514 with the B record response. 516 The DANE TLSA records and TLS 1.3 handshake parameters and supported 517 Application Layer Protocols are bound in this case to the "server- 518 primary.example-1.net." target as they should be. If the 519 administrator of example.com were to move the "www.example.com." 520 CNAME to point to a different operator (eg, "example-2.net"), that 521 second operator would provide their own service bindings which 522 clients would use as a unit. 524 The value of this Service Binding approach can be seen here when 525 contrasting against having multiple independent records, each with 526 their own TTL. For example, if "www.example.com" is a CNAME to 527 address records on example-1.net and "_443._tcp.www.example.com" is a 528 CNAME to TLSA records on example-1.net, there is no way to change 529 either of these CNAMEs to point to example-2.net without a situation 530 where some clients are getting address records for example-1 and TLSA 531 records for example-2, resulting in a possible denial-of-service. 533 7. Open Areas for Discussion 535 As this is a early version of this draft, a number of design choices 536 are still open for active discussion: 538 o What encoding should be used for the Parameters? Some options 539 include: 541 * CBOR [RFC7049] - has the advantage of allowing new parameters 542 to be added with self-describing types in a way that unknown 543 new parameters can be ignored. 545 * Something ad-hoc, such as the tag-value system of DKIM 546 [RFC6376] section 3.2. This might be more compact, but also 547 ends up being more ad-hoc. 549 * What textual representation should be used? JSON, or something 550 more in-line with other DNS record types? The illustrative 551 examples here use JSON for the time-being. 553 o Should there be a more formal general definition of the transport 554 vs protocol layering and filtering? It may be preferable to have 555 a single identifier (ALPN) specifying the full stack. 557 * Which layers should be included? More or less? 559 * How does TLS fit in? 561 * What more examples should we give? 563 o How much do we need to worry about packet size limitations, and 564 what can we do about them? 566 * Should we do any form of name compression? 568 * Should we allow names (such as the DANE names) to be relative? 570 o Should the TLS 1.3 handshake parameters move to their own record 571 that is just named from the B record? 573 o What should be the name of the Resource Record type: is "B" a good 574 name, or should something longer such as "SB" or "SBND" be used? 576 o What should be a standard part of the record and what should be 577 parameters? Everything could be a parameter, including priority 578 and target and weight. In the other direction, some existing 579 parameters could be standard. There may be a reasonable balance 580 in the current proposal. 582 o There is an operational risk that the B record and normal address 583 records (A and AAAA) could diverge over time due to administrative 584 management skew. For a CDN or hosting provider, taking advantage 585 of B records also means that the content provider would need to 586 CNAME over an additional records per-service. 588 o We may want to give examples of additional use-cases where this is 589 helpful: 591 1. Apex zone domain names - can be used instead of a CNAME to 592 delegate over to a CDN or hosting provider 594 2. Dealing with the SNI challenge for TLS: specify that clients 595 using a Service Binding MUST send TLS SNI. This would allow 596 the use of a larger set of SNI-only servers for the B record 597 targets than for the normal address records on the domain, 599 o Should there be a parameter to indication which service binding 600 was used when making a connection? In particular, a parameter 601 which is a label or string that gets passed from the client to the 602 server (such as a response header or as "Indicated Service")? 604 o Why a separate domain name (eg, "_http._b.www.example.com") rather 605 than just a record on "www.example.com" (as in the DANISH 606 proposal)? 608 * The reason is that you _do_ want a separate name-per-service, 609 as otherwise the RRset will get too big if you have multiple 610 names. 612 * Is the "_b" actually needed? Or could this just be 613 "_http.www.example.com" ? 615 o Which of the additional parameters above should we include in 616 subsequent versions of this draft? 618 8. IANA Considerations 620 The IANA will need to assign an RR type value to the B RR. 622 The IANA will also need to maintain a registry of Parameters allowed 623 B RRs. (Details on this will need to be expanded in a future version 624 of this draft.) 626 9. Security Considerations 628 Service Bindings have many of the same security issues as SRV records 629 or most other DNS record types (such as A and AAAA address records). 630 In particular, if the client is not securely validating DNS 631 resolutions then a man-in-the-middle attacker could trick a client 632 into contacting an attacker selected server and port and protocol. 633 Similar attacks could also force a client to downgrade to a less 634 secure protocol or to fall back to using address records. 636 Clients MAY chose to bound the TTLs of B RRsets to a reasonable value 637 and/or forget B RRsets on network changes to limit the damage that 638 can be done by such a man-in-the-middle. 640 For each service binding parameter type, specific attention must be 641 paid to the security considerations relevant to it. In particular: 643 Application Layer Protocol Care must be taken to disallow and filter 644 out any invalid ALPN and Service combinations. For example, 645 clients MUST NOT allow ALPN "h2c" in combination with Service 646 "https". 648 DANE Certificate Controls DANE TLSA records can be used to either 649 restrict the set of allowed server certificates to a subset of 650 those that a client would normally allow. They can also be used 651 to specify alternate certificates or trust roots to use for 652 validation, relying on DNSSEC instead of the CA hierarchy. 654 If a man-in-the-middle attacker can inject DNS responses (and the 655 client is not securely validating the responses), then in the 656 former case the attacker can only force a denial-of-service by 657 causing the client to fail its validation. Allowing this may be 658 an acceptable trade-off to allow administrators to limit the scope 659 of allowed certificates even for clients not performing 660 validation. As such, clients MAY use B and TLSA records to 661 constrain allowed certificates to a strict subset of those that 662 would otherwise be allowed. 664 However, in the former case (where alternate certificates that are 665 not ones a client would already trust can be specified), an 666 attacker or unscrupulous DNS resolver operator could utilize this 667 to force a client to trust an adversary-controlled server. As 668 such, clients MUST NOT use DANE TLSA records unless the B RRset, 669 the TLSA RRset, all aliases (eg, CNAMEs) pointing to them, and all 670 authorities of these can be securely validated. 672 (_Additional security considerations will need to be added to a 673 future version of this draft._) 675 10. Acknowledgments 677 This draws heavily on many previous DNS RFCs such as [RFC2782]. 679 Discussions with Eric Rescorla, Daniel Kahn Gilmore, Mark Nottingham, 680 and others on the TLS and HTTPBIS working groups have heavily 681 influenced this proposal. Suggestions from Richard Barnes and others 682 have also been incorporated into this draft. 684 11. References 686 11.1. Normative References 688 [I-D.ietf-tls-applayerprotoneg] 689 Friedl, S., Popov, A., Langley, A., and S. Emile, 690 "Transport Layer Security (TLS) Application Layer Protocol 691 Negotiation Extension", draft-ietf-tls-applayerprotoneg-05 692 (work in progress), March 2014. 694 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 695 STD 13, RFC 1034, November 1987. 697 [RFC1035] Mockapetris, P., "Domain names - implementation and 698 specification", STD 13, RFC 1035, November 1987. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC2535] Eastlake, D., "Domain Name System Security Extensions", 704 RFC 2535, March 1999. 706 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 707 specifying the location of services (DNS SRV)", RFC 2782, 708 February 2000. 710 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 711 Resource Identifier (URI): Generic Syntax", STD 66, RFC 712 3986, January 2005. 714 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 715 Encodings", RFC 4648, October 2006. 717 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 718 of Named Entities (DANE) Transport Layer Security (TLS) 719 Protocol: TLSA", RFC 6698, August 2012. 721 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 722 Transport Security (HSTS)", RFC 6797, November 2012. 724 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 725 Representation (CBOR)", RFC 7049, October 2013. 727 11.2. Informative References 729 [I-D.ietf-httpbis-alt-svc] 730 Nottingham, M., McManus, P., and J. Reschke, "HTTP 731 Alternative Services", draft-ietf-httpbis-alt-svc-01 (work 732 in progress), April 2014. 734 [I-D.ietf-httpbis-http2] 735 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 736 Protocol version 2", draft-ietf-httpbis-http2-13 (work in 737 progress), June 2014. 739 [I-D.rescorla-tls13-new-flows] 740 Rescorla, E., "New Handshake Flows for TLS 1.3", draft- 741 rescorla-tls13-new-flows-01 (work in progress), February 742 2014. 744 [RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 745 Identified Mail (DKIM) Signatures", STD 76, RFC 6376, 746 September 2011. 748 11.3. URIs 750 [1] #security 752 Author's Address 754 Erik Nygren 755 Akamai Technologies 757 Email: erik+ietf@nygren.org 758 URI: http://erik.nygren.org/