idnits 2.17.1 draft-ietf-xmpp-posh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 10, 2014) is 3483 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: April 13, 2015 &yet 6 October 10, 2014 8 PKIX over Secure HTTP (POSH) 9 draft-ietf-xmpp-posh-02 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 April 13, 2015. 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 a JSON array of fingerprint 234 descriptors. 236 o An "expires" field whose value is a JSON number specifying the 237 number of seconds after which the TLS client ought to consider the 238 key information to be 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. It MUST be a non-negative integer. If no "expires" field 274 is included or its value is equal to 0, a TLS client SHOULD consider 275 these verification materials invalid. See Section 6 for how to 276 reconcile this "expires" field with the reference's "expires" 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 a JSON string specifying the HTTPS 286 URL where TLS clients can obtain the actual certificate 287 information. 289 o An "expires" field whose value is a JSON number specifying the 290 number of seconds after which the TLS client ought to consider the 291 delegation to be stale (further explained under Section 6). 293 Example Reference Response 295 HTTP/1.1 200 Ok 296 Content-Type: application/json 297 Content-Length: 79 299 { 300 "url":"https://hosting.example.net/.well-known/posh.foo.json", 301 "expires":86400 302 } 304 The client performs an HTTPS GET for the URL specified in the "url" 305 field value. The HTTPS server for the URL to which the client has 306 been redirected responds to the request with a JSON document 307 containing fingerprints as described in Section 3.1. The content 308 retrieved from the "url" location MUST NOT itself be a reference 309 (i.e., containing a "url" field instead of a "fingerprints" field), 310 in order to prevent circular delegations. 312 Note: The JSON document returned by the source domain HTTPS server 313 MUST contain either a reference or a fingerprints document, but 314 MUST NOT contain both. 316 Note: See Section 9 for discussion about HTTPS redirects. 318 The "expires" value is a hint regarding the expiration of the source 319 domain's delegation of service to the delegated domain. It MUST be a 320 non-negative integer. If no "expires" field is included or its value 321 is equal to 0, a TLS client SHOULD consider the delegation invalid. 322 See Section 6 for guidelines about reconciling this "expires" field 323 with the "expires" field of the fingerprints document. 325 3.3. Performing Verification 327 The TLS client compares the PKIX information obtained from the TLS 328 server against each fingerprint descriptor object in the POSH 329 results, until a match is found or the collection of POSH 330 verification materials is exhausted. If none of the fingerprint 331 descriptor objects match the TLS server PKIX information, the TLS 332 client SHOULD reject the connection (however, the TLS client might 333 still accept the connection if other verification schemes are 334 successful). 336 4. Secure Delegation 338 The delegation from the source domain to the delegated domain can be 339 considered secure if the certificate offered by the TLS server 340 matches the POSH certificate, regardless of how the POSH certificate 341 is obtained. 343 5. Order of Operations 345 In order for the TLS client to perform verification of reference 346 identifiers without potentially compromising data, POSH processes 347 MUST be complete before any application-level data is exchanged for 348 the source domain. The TLS client SHOULD perform all POSH retrievals 349 before opening any socket connections to the application protocol 350 server. For application protocols that use DNS SRV (including 351 queries for TLSA records in concert with SRV records as described in 352 [I-D.ietf-dane-srv]), the POSH processes ideally ought to be done in 353 parallel with resolving the SRV records and the addresses of any 354 targets, similar to the "happy eyeballs" approach for IPv4 and IPv6 355 [RFC6555]. 357 The following diagram illustrates the possession flow: 359 Client Domain Server 360 ------ ------ ------ 361 | | | 362 | Request POSH | | 363 |------------------------->| | 364 | | | 365 | Return POSH fingerprints | | 366 |<-------------------------| | 367 | | | 368 | Service TLS Handshake | 369 |<===================================================>| 370 | | | 371 | Service Data | 372 |<===================================================>| 373 | | | 375 Figure 1: Order of Events for Possession Flow 377 While the following diagram illustrates the reference flow: 379 Client Domain Server 380 ------ ------ ------ 381 | | | 382 | Request POSH | | 383 |------------------------->| | 384 | | | 385 | Return POSH url | | 386 |<-------------------------| | 387 | | | 388 | Request POSH | 389 |---------------------------------------------------->| 390 | | | 391 | Return POSH fingerprints | 392 |<----------------------------------------------------| 393 | | | 394 | Service TLS Handshake | 395 |<===================================================>| 396 | | | 397 | Service Data | 398 |<===================================================>| 399 | | | 401 Figure 2: Order of Events for Reference Flow 403 6. Caching Results 405 The TLS client MUST NOT cache results (reference or fingerprints) 406 indefinitely. If the source domain returns a reference, the TLS 407 client MUST use the lower of the two "expires" values when 408 determining how long to cache results (i.e., if the reference 409 "expires" value is lower than the fingerprints "expires" value, honor 410 the reference "expires" value). Once the TLS client considers the 411 results stale, it needs to perform the entire POSH process again 412 starting with the HTTPS GET to the source domain. The TLS client MAY 413 use a lower value than any provided in the "expires" field(s), or not 414 cache results at all. 416 The TLS client SHOULD NOT rely on HTTP caching mechanisms, instead 417 using the expiration hints provided in the POSH reference document or 418 fingerprints documents. To that end, the HTTPS servers for source 419 domains and derived domains SHOULD specify a 'Cache-Control' header 420 indicating a very short duration (e.g., max-age=60) or "no-cache" to 421 indicate that the response (redirect, reference, or content) is not 422 appropriate to cache at the HTTP level. 424 7. Alternates and Roll-over 426 To indicate alternate PKIX certificates (such as when an existing 427 certificate will soon expire), the returned fingerprints document MAY 428 contain multiple fingerprint descriptors. The fingerprints SHOULD be 429 ordered with the most relevant certificate first as determined by the 430 application service operator (e.g., the renewed certificate), 431 followed by the next most relevant certificate (e.g., the certificate 432 soonest to expire). Here is an example: 434 { 435 "fingerprints": [ 436 { 437 "sha-1":"UpjRI/A3afKE8/AIeTZ5o1dECTY=", 438 "sha-256":"4/mggdlVx8A3pvHAWW5sD+qJyMtUHgiRuPjVC48N0XQ" 439 }, 440 { 441 "sha-1":"T29tGO9d7kxbfWnUaac8+5+ICLM=", 442 "sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE=" 443 } 444 ], 445 "expires": 806400 446 } 448 8. IANA Considerations 450 This document registers a well-known URI [RFC5785] for protocols that 451 use POSH. The completed template follows. 453 URI suffix: posh. 455 Change controller: IETF 457 Specification document: [[ this document ]] 459 Related information: Because the "posh." string is merely a 460 prefix, protocols that use POSH need to register particular 461 URIs that are prefixed with the "posh." string. 463 Note that the registered URI is "posh." (with a trailing dot). This 464 is merely a prefix to be placed at the front of well-known URIs 465 [RFC5785] registered by protocols that use POSH, which themselves are 466 responsible for the relevant registrations with the IANA. The URIs 467 registered by such protocols SHOULD match the URI template [RFC6570] 468 path "/.well-known/posh.{servicedesc}.json"; that is, begin with 469 "posh." and end with ".json" (indicating a media type of application/ 470 json [RFC7159]). 472 For POSH-using protocols that rely on DNS SRV records [RFC2782], the 473 "{servicedesc}" part of the well-known URI SHOULD be 474 "{service}.{proto}", where the "{service}" is the DNS SRV "Service" 475 prepended by the underscore character "_" and the "{proto}" is the 476 DNS SRV "Proto" also prepended by the underscore character "_". As 477 an example, the well-known URI for XMPP server-to-server connections 478 would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers 479 a service name of "xmpp-server" and uses TCP as the underlying 480 transport protocol. 482 For other POSH-using protocols, the "{servicedesc}" part of the well- 483 known URI can be any unique string or identifier for the protocol, 484 which might be a service name registered with the IANA in accordance 485 with [RFC6335] or which might be an unregistered name. As an 486 example, the well-known URI for the mythical "Foo" service could be 487 "posh.foo.json". 489 Note: As explained in [RFC5785], the IANA registration policy 490 [RFC5226] for well-known URIs is Specification Required. 492 9. Security Considerations 494 This document supplements but does not supersede the security 495 considerations provided in specifications for application protocols 496 that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP). 497 Specifically, the security of requests and responses sent via HTTPS 498 depends on checking the identity of the HTTP server in accordance 499 with [RFC2818]. Additionally, the security of POSH can benefit from 500 other HTTP hardening protocols, such as HSTS [RFC6797] and key 501 pinning [I-D.ietf-websec-key-pinning], especially if the TLS client 502 shares some information with a common HTTPS implementation (e.g., 503 platform-default web browser). 505 Note well that POSH is used by a TLS client to obtain the public key 506 of a TLS server to which it might connect for a particular 507 application protocol such as IMAP or XMPP. POSH does not enable a 508 hosted domain to transfer private keys to a hosting service via 509 HTTPS. POSH also does not enable a TLS server to engage in 510 certificate enrollment with a certification authority via HTTPS, as 511 is done in Enrollment over Secure Transport [RFC7030]. 513 A web server at the source domain might redirect an HTTPS request to 514 another URL. The location provided in the redirect response MUST 515 specify an HTTPS URL. Source domains SHOULD use only temporary 516 redirect mechanisms, such as HTTP status codes 302 (Found) and 307 517 (Temporary Redirect). Clients MAY treat any redirect as temporary, 518 ignoring the specific semantics for 301 (Moved Permanently) and 308 519 (Permanent Redirect) [RFC7238]. To protect against circular 520 references, clients MUST NOT follow an infinite number of redirects. 521 It is RECOMMENDED that clients follow no more than 10 redirects, 522 although applications or implementations can require that fewer 523 redirects be followed. 525 10. References 527 10.1. Normative References 529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 530 Requirement Levels", BCP 14, RFC 2119, March 1997. 532 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 534 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 535 Encodings", RFC 4648, October 2006. 537 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 538 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 540 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 541 Housley, R., and W. Polk, "Internet X.509 Public Key 542 Infrastructure Certificate and Certificate Revocation List 543 (CRL) Profile", RFC 5280, May 2008. 545 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 546 Uniform Resource Identifiers (URIs)", RFC 5785, April 547 2010. 549 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 550 Verification of Domain-Based Application Service Identity 551 within Internet Public Key Infrastructure Using X.509 552 (PKIX) Certificates in the Context of Transport Layer 553 Security (TLS)", RFC 6125, March 2011. 555 [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data 556 Interchange Format", RFC 7159, March 2014. 558 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 559 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 560 2014. 562 10.2. Informative References 564 [I-D.ietf-dane-srv] 565 Finch, T., Miller, M., and P. Saint-Andre, "Using DNS- 566 Based Authentication of Named Entities (DANE) TLSA Records 567 with SRV Records", draft-ietf-dane-srv-06 (work in 568 progress), June 2014. 570 [I-D.ietf-websec-key-pinning] 571 Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 572 Extension for HTTP", draft-ietf-websec-key-pinning-14 573 (work in progress), June 2014. 575 [I-D.ietf-xmpp-dna] 576 Saint-Andre, P. and M. Miller, "Domain Name Associations 577 (DNA) in the Extensible Messaging and Presence Protocol 578 (XMPP)", draft-ietf-xmpp-dna-05 (work in progress), 579 February 2014. 581 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 582 specifying the location of services (DNS SRV)", RFC 2782, 583 February 2000. 585 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 586 Rose, "DNS Security Introduction and Requirements", RFC 587 4033, March 2005. 589 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 590 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 591 May 2008. 593 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 594 Protocol (XMPP): Core", RFC 6120, March 2011. 596 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 597 Cheshire, "Internet Assigned Numbers Authority (IANA) 598 Procedures for the Management of the Service Name and 599 Transport Protocol Port Number Registry", BCP 165, RFC 600 6335, August 2011. 602 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 603 Dual-Stack Hosts", RFC 6555, April 2012. 605 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 606 and D. Orchard, "URI Template", RFC 6570, March 2012. 608 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 609 of Named Entities (DANE) Transport Layer Security (TLS) 610 Protocol: TLSA", RFC 6698, August 2012. 612 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 613 Transport Security (HSTS)", RFC 6797, November 2012. 615 [RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over 616 Secure Transport", RFC 7030, October 2013. 618 [RFC7238] Reschke, J., "The Hypertext Transfer Protocol Status Code 619 308 (Permanent Redirect)", RFC 7238, June 2014. 621 [HASH-NAMES] 622 "Hash Function Textual Names", 623 . 626 Appendix A. Acknowledgements 628 Many thanks to Thijs Alkemade, Philipp Hancke, Joe Hildebrand, and 629 Tobias Markmann for their implementation feedback. Thanks also to 630 Dave Cridland, Chris Newton, Max Pritikin, and Joe Salowey for their 631 input on the specification. 633 Authors' Addresses 635 Matthew Miller 636 Cisco Systems, Inc. 637 1899 Wynkoop Street, Suite 600 638 Denver, CO 80202 639 USA 641 Email: mamille2@cisco.com 643 Peter Saint-Andre 644 &yet 645 P.O. Box 787 646 Parker, CO 80134 647 USA 649 Email: peter@andyet.com