idnits 2.17.1 draft-ietf-xmpp-posh-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 (June 19, 2014) is 3596 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 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-14) exists of draft-ietf-dane-srv-06 == Outdated reference: A later version (-21) exists of draft-ietf-websec-key-pinning-14 == Outdated reference: A later version (-11) exists of draft-ietf-xmpp-dna-05 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) -- Obsolete informational reference (is this intentional?): RFC 7238 (Obsoleted by RFC 7538) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 XMPP Working Group M. Miller 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track P. Saint-Andre 5 Expires: December 21, 2014 &yet 6 June 19, 2014 8 PKIX over Secure HTTP (POSH) 9 draft-ietf-xmpp-posh-01 11 Abstract 13 Experience has shown that it is extremely difficult to deploy proper 14 PKIX certificates for TLS in multi-tenanted environments, since 15 certification authorities will not issue certificates for hosted 16 domains to hosting services, hosted domains do not want hosting 17 services to hold their private keys, and hosting services wish to 18 avoid liability for holding those keys. As a result, domains hosted 19 in multi-tenanted environments often deploy non-HTTP applications 20 such as email and instant messaging using certificates that identify 21 the hosting service, not the hosted domain. Such deployments force 22 end users and peer services to accept a certificate with an improper 23 identifier, resulting in obvious security implications. This 24 document defines two methods that make it easier to deploy 25 certificates for proper server identity checking in non-HTTP 26 application protocols. The first method enables the TLS client 27 associated with a user agent or peer application server to obtain the 28 end-entity certificate of a hosted domain over secure HTTP as an 29 alternative to standard PKIX techniques. The second method enables a 30 hosted domain to securely delegate a non-HTTP application to a 31 hosting service using redirects provided by HTTPS itself or by a 32 pointer in a file served over HTTPS at the hosted domain. While this 33 approach was developed for use in the Extensible Messaging and 34 Presence Protocol (XMPP) as a Domain Name Association prooftype, it 35 can be applied to any non-HTTP application protocol. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 21, 2014. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Obtaining Verification Materials . . . . . . . . . . . . . . 4 74 3.1. Source Domain Possesses PKIX Certificate Information . . 5 75 3.2. Source Domain References PKIX Certificate . . . . . . . . 6 76 3.3. Performing Verification . . . . . . . . . . . . . . . . . 7 77 4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8 78 5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8 79 6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 9 80 7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 89 1. Introduction 91 We start with a thought experiment. 93 Imagine that you work on the operations team of a hosting company 94 that provides the "foo" service (or email or instant messaging or 95 social networking service) for ten thousand different customer 96 organizations. Each customer wants their service to be identified by 97 the customer's domain name (e.g., foo.example.com), not the hosting 98 company's domain name (e.g., hosting.example.net). 100 In order to properly secure each customer's "foo" service via 101 Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX 102 certificates [RFC5280] containing identifiers such as 103 foo.example.com, as explained in the "CertID" specification 104 [RFC6125]. Unfortunately, you can't obtain such certificates 105 because: 107 o Certification authorities won't issue such certificates to you 108 because you work for the hosting company, not the customer 109 organization. 111 o Customers won't obtain such certificates and then give them (plus 112 the associated private keys) to you because their legal department 113 is worried about liability. 115 o You don't want to install such certificates (plus the associated 116 private keys) on your servers anyway because your legal department 117 is worried about liability, too. 119 Given your inability to deploy public keys / certificates containing 120 the right identifiers, your back-up approach has always been to use a 121 certificate containing hosting.example.net as the identifier. 122 However, more and more customers and end users are complaining about 123 warning messages in user agents and the inherent security issues 124 involved with taking a "leap of faith" to accept the identity 125 mismatch between the source domain (foo.example.com) and the 126 delegated domain (hosting.example.net). 128 This situation is both insecure and unsustainable. You have 129 investigated the possibility of using DNS Security [RFC4033] and DNS- 130 Based Authentication of Named Entities (DANE) [RFC6698] to solve the 131 problem. However, your customers and your operations team have told 132 you that it will be several years before they will be able to deploy 133 DNSSEC and DANE for all of your customers (because of tooling 134 updates, slow deployment of DNSSEC at some top-level domains, etc.). 135 The product managers in your company are pushing you to find a method 136 that can be deployed more quickly to overcome the lack of proper 137 server identity checking for your hosted customers. 139 One possible approach that your team has investigated is to ask each 140 customer to provide the public key / certificate for the "foo" 141 service at a special HTTPS URL on their website 142 ("https://foo.example.com/.well-known/posh.foo.json" is one 143 possibility). This could be a public key that you generate for the 144 customer, but because the customer hosts it via HTTPS, any user agent 145 can find that public key and check it against the public key you 146 provide during TLS negotiation for the "foo" service (as one added 147 benefit, the customer never needs to hand you a private key). 148 Alternatively, the customer can redirect requests for that special 149 HTTPS URL to an HTTPS URL at your own website, thus making it 150 explicit that they have delegated the "foo" service to you. 152 The approach sketched out above, called POSH ("PKIX Over Secure 153 HTTP"), is explained in the remainder of this document. While this 154 approach was developed for use in the Extensible Messaging and 155 Presence Protocol (XMPP) as a prooftype for Domain Name Associations 156 (DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP 157 application protocol. 159 2. Terminology 161 This document inherits security terminology from [RFC5280]. The 162 terms "source domain", "derived domain", "reference identifier", and 163 "presented identifier" are used as defined in the "CertID" 164 specification [RFC6125]. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 168 "OPTIONAL" in this document are to be interpreted as described in 169 [RFC2119]. 171 3. Obtaining Verification Materials 173 Server identity checking (see [RFC6125]) involves three different 174 aspects: 176 1. A proof of the TLS server's identity (in PKIX, this takes the 177 form of a PKIX certificate [RFC5280]). 179 2. Rules for checking the certificate (which vary by application 180 protocol, although [RFC6125] attempts to harmonize those rules). 182 3. The materials that a TLS client uses to verify the TLS server's 183 identity or check the TLS server's proof (in PKIX, this takes the 184 form of chaining the end-entity certificate back to a trusted 185 root and performing all validity checks as described in 186 [RFC5280], [RFC6125], and the relevant application protocol 187 specification). 189 When POSH is used, the first two aspects remain the same: the TLS 190 server proves it identity by presenting a PKIX certificate [RFC5280] 191 and the certificate is checked according to the rules defined in the 192 appropriate application protocol specification (such as [RFC6120] for 193 XMPP). However, the TLS client obtains the materials it will use to 194 verify the server's proof by retrieving a JSON document [RFC7159] 195 containing hashes of the PKIX certificate over HTTPS ([RFC7230] and 196 [RFC2818]) from a well-known URI [RFC5785]. 198 The process for retrieving a PKIX certificate over secure HTTP is as 199 follows. 201 1. The TLS client performs an HTTPS GET at the source domain to the 202 path "/.well-known/posh.{servicedesc}.json". The value of 203 "{servicedesc}" is application-specific; see Section 8 of this 204 document for more details. For example, if the application 205 protocol is some hypothetical "Foo" service, then "{servicedesc}" 206 could be "foo"; thus if a Foo client were to use POSH to verify a 207 Foo server for the domain "foo.example.com", the HTTPS GET 208 request would be as follows: 210 GET /.well-known/posh.foo.json HTTP/1.1 211 Host: foo.example.com 213 2. The source domain HTTPS server responds in one of three ways: 215 * If it possesses PKIX certificate information for the requested 216 path, it responds as detailed in Section 3.1. 218 * If it has a reference to where the PKIX certificate 219 information can be obtained, it responds as detailed in 220 Section 3.2. 222 * If it does not have any PKIX certificate information or a 223 reference to such information for the requested path, it 224 responds with an HTTP client error status code (e.g., 404). 226 3.1. Source Domain Possesses PKIX Certificate Information 228 If the source domain HTTPS server possesses the certificate 229 information, it responds to the HTTPS GET with a success status code 230 and the message body set to a JSON document [RFC7159]; the document 231 is a JSON object which MUST have the following: 233 o A "fingerprints" field whose value is an array of fingerprint 234 descriptors. 236 o An "expires" field whose value is the number of seconds after 237 which the TLS client ought to consider the key information to be 238 stale (further explained under Section 6). 240 Each included fingerprint descriptor is a JSON object, where each 241 member name is the textual name of a hash function (as listed in 242 [HASH-NAMES]) and its associated value is the base 64 encoded 243 fingerprint hash generated using the named hash function (where the 244 encoding adheres to the definition in Section 4 of [RFC4648] and 245 where the padding bits are set to zero). Each fingerprint descriptor 246 MUST possess at least one named hash function. 248 The fingerprint hash for a given hash algorithm is generated by 249 performing the named hash function over the DER encoding of the PKIX 250 X.509 certifiate; for example, a "sha-1" fingerprint is generated by 251 performing the SHA-1 hash function over the DER encoding of the PKIX 252 certificate. 254 The following example illustrates the usage described above. 256 Example Content Response 258 HTTP/1.1 200 OK 259 Content-Type: application/json 260 Content-Length: 134 262 { 263 "fingerprints": [ 264 { 265 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 266 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ=" 267 } 268 ], 269 "expires": 604800 270 } 272 The "expires" value is a hint regarding the expiration of the keying 273 materials. If no "expires" field is included, a TLS client SHOULD 274 consider these verification materials invalid. See Section 6 for how 275 to reconcile this "expires" field with the reference's "expires" 276 field. 278 3.2. Source Domain References PKIX Certificate 280 If the source domain HTTPS server has a reference to the certificate 281 information, it responds to the HTTPS GET with a success status code 282 and message body set to a JSON document. The document is a JSON 283 object which MUST contain the following: 285 o A "url" field whose value is the HTTPS URL where TLS clients can 286 obtain the actual certificate information. 288 o An "expires" field whose value is the number of seconds after 289 which the TLS client ought to consider the delegation to be stale 290 (further explained under Section 6). 292 Example Reference Response 294 HTTP/1.1 200 Ok 295 Content-Type: application/json 296 Content-Length: 79 298 { 299 "url":"https://hosting.example.net/.well-known/posh.foo.json", 300 "expires":86400 301 } 303 The client performs an HTTPS GET for the URL specified in the "url" 304 field value. The HTTPS server for the URL to which the client has 305 been redirected responds to the request with a JSON document 306 containing fingerprints as described in Section 3.1. The content 307 retrieved from the "url" location MUST NOT itself be a reference 308 (i.e., containing a "url" field instead of a "fingerprints" field), 309 in order to prevent circular delegations. 311 Note: The JSON document returned by the source domain HTTPS server 312 MUST contain either a reference or a fingerprints document, but 313 MUST NOT contain both. 315 Note: See Section 9 for discussion about HTTPS redirects. 317 The "expires" value is a hint regarding the expiration of the source 318 domain's delegation of service to the delegated domain. If no 319 "expires" field is included, a TLS client SHOULD consider the 320 delegation invalid. See Section 6 for guidelines about reconciling 321 this "expires" field with the "expires" field of the fingerprints 322 document. 324 3.3. Performing Verification 326 The TLS client compares the PKIX information obtained from the TLS 327 server against each fingerprint descriptor object in the POSH 328 results, until a match is found or the collection of POSH 329 verification materials is exhausted. If none of the fingerprint 330 descriptor objects match the TLS server PKIX information, the TLS 331 client SHOULD reject the connection (however, the TLS client might 332 still accept the connection if other verification schemes are 333 successful). 335 4. Secure Delegation 337 The delegation from the source domain to the delegated domain can be 338 considered secure if the certificate offered by the TLS server 339 matches the POSH certificate, regardless of how the POSH certificate 340 is obtained. 342 5. Order of Operations 344 In order for the TLS client to perform verification of reference 345 identifiers without potentially compromising data, POSH processes 346 MUST be complete before any application-level data is exchanged for 347 the source domain. The TLS client SHOULD perform all POSH retrievals 348 before opening any socket connections to the application protocol 349 server. For application protocols that use DNS SRV (including 350 queries for TLSA records in concert with SRV records as described in 351 [I-D.ietf-dane-srv]), the POSH processes ideally ought to be done in 352 parallel with resolving the SRV records and the addresses of any 353 targets, similar to the "happy eyeballs" approach for IPv4 and IPv6 354 [RFC6555]. 356 The following diagram illustrates the possession flow: 358 Client Domain Server 359 ------ ------ ------ 360 | | | 361 | Request POSH | | 362 |------------------------->| | 363 | | | 364 | Return POSH fingerprints | | 365 |<-------------------------| | 366 | | | 367 | Service TLS Handshake | 368 |<===================================================>| 369 | | | 370 | Service Data | 371 |<===================================================>| 372 | | | 374 Figure 1: Order of Events for Possession Flow 376 While the following diagram illustrates the reference flow: 378 Client Domain Server 379 ------ ------ ------ 380 | | | 381 | Request POSH | | 382 |------------------------->| | 383 | | | 384 | Return POSH url | | 385 |<-------------------------| | 386 | | | 387 | Request POSH | 388 |---------------------------------------------------->| 389 | | | 390 | Return POSH fingerprints | 391 |<----------------------------------------------------| 392 | | | 393 | Service TLS Handshake | 394 |<===================================================>| 395 | | | 396 | Service Data | 397 |<===================================================>| 398 | | | 400 Figure 2: Order of Events for Reference Flow 402 6. Caching Results 404 The TLS client MUST NOT cache results (reference or fingerprints) 405 indefinitely. If the source domain returns a reference, the TLS 406 client MUST use the lower of the two "expires" values when 407 determining how long to cache results (i.e., if the reference 408 "expires" value is lower than the fingerprints "expires" value, honor 409 the reference "expires" value). Once the TLS client considers the 410 results stale, it needs to perform the entire POSH process again 411 starting with the HTTPS GET to the source domain. The TLS client MAY 412 use a lower value than any provided in the "expires" field(s), or not 413 cache results at all. 415 The TLS client SHOULD NOT rely on HTTP caching mechanisms, instead 416 using the expiration hints provided in the POSH reference document or 417 fingerprints documents. To that end, the HTTPS servers for source 418 domains and derived domains SHOULD specify a 'Cache-Control' header 419 indicating a very short duration (e.g., max-age=60) or "no-cache" to 420 indicate that the response (redirect, reference, or content) is not 421 appropriate to cache at the HTTP level. 423 7. Alternates and Roll-over 425 To indicate alternate PKIX certificates (such as when an existing 426 certificate will soon expire), the returned fingerprints document MAY 427 contain multiple fingerprint descriptors. The fingerprints SHOULD be 428 ordered with the most relevant certificate first as determined by the 429 application service operator (e.g., the renewed certificate), 430 followed by the next most relevant certificate (e.g., the certificate 431 soonest to expire). Here is an example: 433 { 434 "fingerprints": [ 435 { 436 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 437 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ" 438 }, 439 { 440 "sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=", 441 "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=" 442 } 443 ], 444 "expires": 806400 445 } 447 8. IANA Considerations 449 This document registers a well-known URI [RFC5785] for protocols that 450 use POSH. The completed template follows. 452 URI suffix: posh. 454 Change controller: IETF 456 Specification document: [[ this document ]] 458 Related information: Because the "posh." string is merely a 459 prefix, protocols that use POSH need to register particular 460 URIs that are prefixed with the "posh." string. 462 Note that the registered URI is "posh." (with a trailing dot). This 463 is merely a prefix to be placed at the front of well-known URIs 464 [RFC5785] registered by protocols that use POSH, which themselves are 465 responsible for the relevant registrations with the IANA. The URIs 466 registered by such protocols SHOULD match the URI template [RFC6570] 467 path "/.well-known/posh.{servicedesc}.json"; that is, begin with 468 "posh." and end with ".json" (indicating a media type of application/ 469 json [RFC7159]). 471 For POSH-using protocols that rely on DNS SRV records [RFC2782], the 472 "{servicedesc}" part of the well-known URI SHOULD be 473 "{service}.{proto}", where the "{service}" is the DNS SRV "Service" 474 prepended by the underscore character "_" and the "{proto}" is the 475 DNS SRV "Proto" also prepended by the underscore character "_". As 476 an example, the well-known URI for XMPP server-to-server connections 477 would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers 478 a service name of "xmpp-server" and uses TCP as the underlying 479 transport protocol. 481 For other POSH-using protocols, the "{servicedesc}" part of the well- 482 known URI can be any unique string or identifier for the protocol, 483 which might be a service name registered with the IANA in accordance 484 with [RFC6335] or which might be an unregistered name. As an 485 example, the well-known URI for the mythical "Foo" service could be 486 "posh.foo.json". 488 Note: As explained in [RFC5785], the IANA registration policy 489 [RFC5226] for well-known URIs is Specification Required. 491 9. Security Considerations 493 This document supplements but does not supersede the security 494 considerations provided in specifications for application protocols 495 that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). 496 Specifically, the security of requests and responses sent via HTTPS 497 depends on checking the identity of the HTTP server in accordance 498 with [RFC2818]. Additionally, the security of POSH can benefit from 499 other HTTP hardening protocols, such as HSTS [RFC6797] and key 500 pinning [I-D.ietf-websec-key-pinning], especially if the TLS client 501 shares some information with a common HTTPS implementation (e.g., 502 platform-default web browser). 504 Note well that POSH is used by a TLS client to obtain the public key 505 of a TLS server to which it might connect for a particular 506 application protocol such as IMAP or XMPP. POSH does not enable a 507 hosted domain to transfer private keys to a hosting service via 508 HTTPS. POSH also does not enable a TLS server to engage in 509 certificate enrollment with a certification authority via HTTPS, as 510 is done in Enrollment over Secure Transport [RFC7030]. 512 A web server at the source domain might redirect an HTTPS request to 513 another URL. The location provided in the redirect response MUST 514 specify an HTTPS URL. Source domains SHOULD use only temporary 515 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 516 (Temporary Redirect). Clients MAY treat any redirect as temporary, 517 ignoring the specific semantics for 301 (Moved Permanently) and 308 518 (Permanent Redirect) [RFC7238]. To protect against circular 519 references, clients MUST NOT follow an infinite number of redirects. 520 It is RECOMMENDED that clients follow no more than 10 redirects, 521 although applications or implementations can require that fewer 522 redirects be followed. 524 10. References 526 10.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 533 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 534 Encodings", RFC 4648, October 2006. 536 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 537 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 539 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 540 Housley, R., and W. Polk, "Internet X.509 Public Key 541 Infrastructure Certificate and Certificate Revocation List 542 (CRL) Profile", RFC 5280, May 2008. 544 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 545 Uniform Resource Identifiers (URIs)", RFC 5785, April 546 2010. 548 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 549 Verification of Domain-Based Application Service Identity 550 within Internet Public Key Infrastructure Using X.509 551 (PKIX) Certificates in the Context of Transport Layer 552 Security (TLS)", RFC 6125, March 2011. 554 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 555 Interchange Format", RFC 7159, March 2014. 557 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 558 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 559 2014. 561 10.2. Informative References 563 [I-D.ietf-dane-srv] 564 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 565 Based Authentication of Named Entities (DANE) TLSA Records 566 with SRV Records", draft-ietf-dane-srv-06 (work in 567 progress), June 2014. 569 [I-D.ietf-websec-key-pinning] 570 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 571 Extension for HTTP", draft-ietf-websec-key-pinning-14 572 (work in progress), June 2014. 574 [I-D.ietf-xmpp-dna] 575 Saint-Andre, P. and M. Miller, "Domain Name Associations 576 (DNA) in the Extensible Messaging and Presence Protocol 577 (XMPP)", draft-ietf-xmpp-dna-05 (work in progress), 578 February 2014. 580 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 581 specifying the location of services (DNS SRV)", RFC 2782, 582 February 2000. 584 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 585 Rose, "DNS Security Introduction and Requirements", RFC 586 4033, March 2005. 588 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 589 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 590 May 2008. 592 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 593 Protocol (XMPP): Core", RFC 6120, March 2011. 595 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 596 Cheshire, "Internet Assigned Numbers Authority (IANA) 597 Procedures for the Management of the Service Name and 598 Transport Protocol Port Number Registry", BCP 165, RFC 599 6335, August 2011. 601 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 602 Dual-Stack Hosts", RFC 6555, April 2012. 604 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 605 and D. Orchard, "URI Template", RFC 6570, March 2012. 607 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 608 of Named Entities (DANE) Transport Layer Security (TLS) 609 Protocol: TLSA", RFC 6698, August 2012. 611 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 612 Transport Security (HSTS)", RFC 6797, November 2012. 614 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 615 Secure Transport", RFC 7030, October 2013. 617 [RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code 618 308 (Permanent Redirect)", RFC 7238, June 2014. 620 [HASH-NAMES] 621 "Hash Function Textual Names", . 625 Appendix A. Acknowledgements 627 Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and 628 Tobias Markmann for their implementation feedback. Thanks also to 629 Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their 630 input on the specification. 632 Authors' Addresses 634 Matthew Miller 635 Cisco Systems, Inc. 636 1899 Wynkoop Street, Suite 600 637 Denver, CO 80202 638 USA 640 Email: mamille2@cisco.com 642 Peter Saint-Andre 643 &yet 644 P.O. Box 787 645 Parker, CO 80134 646 USA 648 Email: peter@andyet.com