Network Working Group F. Fieau, Ed. Internet-Draft E. Stephan Intended status: Standards Track Orange Expires: January 9, 2017 July 8, 2016 Limited Use of Remote Keys for Interconnected CDNs draft-cdni-fieau-lurk-https-delegation-00 Abstract Sharing private keys amongst administrative entities raises numerous issues for end-users, intermediaries and content origins. The IETF envisions the standardization of protocols to limit the exchange of private keys (LURK). This document presents CDN Interconnection (CDNI) use cases based on the Limited Use of Remote Keys (LURK) protocol and architecture and identifies a set of requirements. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 9, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Fieau & Stephan Expires January 9, 2017 [Page 1] Internet-Draft LURK for CDNI July 2016 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. CDNI architecture using LURK . . . . . . . . . . . . . . . . 3 4. LURK use cases for CDNI . . . . . . . . . . . . . . . . . . . 6 4.1. Use case A: uCDN Key Server . . . . . . . . . . . . . . . 6 4.2. Use case B: CSP Key Server . . . . . . . . . . . . . . . 9 4.3. Other use cases . . . . . . . . . . . . . . . . . . . . . 11 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. CDNI Control Interface requirements . . . . . . . . . . . 11 5.3. CDNI Footprint and Capabilities Advertisement interface requirements . . . . . . . . . . . . . . . . . . . . . . 12 5.4. CDNI Logging Interface requirements . . . . . . . . . . . 12 5.5. Key Server Interface requirements . . . . . . . . . . . . 12 6. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. HTTPS and TLS . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Cyphersuites in CDNI . . . . . . . . . . . . . . . . . . 13 6.3. PFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.4. TLS version . . . . . . . . . . . . . . . . . . . . . . . 13 6.5. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 6.6. Certificates and security . . . . . . . . . . . . . . . . 13 6.7. Revocation . . . . . . . . . . . . . . . . . . . . . . . 14 6.8. Certificate provisioning . . . . . . . . . . . . . . . . 14 6.9. CSP side . . . . . . . . . . . . . . . . . . . . . . . . 14 6.10. Acquisition . . . . . . . . . . . . . . . . . . . . . . . 14 6.11. CDNI Control Interface vs CDNI Metadata Interface . . . . 14 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. TLS session resuming . . . . . . . . . . . . . . . . . . 14 7.2. Stack Evolution . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction CDNI requirements [RFC7337] and use cases [RFC6770] specify the requirements and use cases of HTTP content delivery between CDNs. The intent of this document is to pursue the work by proposing a solution for delegating content delivery over secure protocols like Fieau & Stephan Expires January 9, 2017 [Page 2] Internet-Draft LURK for CDNI July 2016 HTTPS or DTLS. Conversely to HTTP delivery, HTTPS [RFC2818] allows content delivery between Content Service Provider (CSP) and End-users with integrity and confidentiality. From the CDNI perspective, all parties - UAs, CSPs origin servers, and CDNs - are involved in the chain of trust and preserving this chain of trust in HTTPS raises concerns. Indeed, regarding TLS certificates, CSPs and CDN providers are reluctant to share private keys mainly because of legal and security issues about private keys. Therefore the CDNI working group must specify a solution that avoids the exchange of private keys between CDNs. This document leverages the work of the LURK initiative [LURK_Mailing_List] and discusses the introduction of a Limited Use of Remote Keys (LURK) solution in the CDNI architecture. It presents 2 use cases which complement those described in [I-D.mglt-lurk-tls-use-cases] and identifies a set of requirements for CDNI. Finally it discusses different options and identifies a set of open issues. The proposed use cases are based on DNS redirection. The user agent is redirected to a dCDN to establish a TLS session to get HTTPS content. Additional use cases are expected in future versions of the draft. This version focus on the delivery over HTTPS only. 2. Terminology This document uses terminology from CDNI framework documents such as CDNI requirements [RFC7337] and CDNI interface specifications documents - CDNI metadata interface [I-D.ietf-cdni-metadata], CDNI Control interface [I-D.ietf-cdni-control-triggers] and Logging interface [I-D.ietf-cdni-logging]. 3. CDNI architecture using LURK This document introduces a Key Server in the CDNI architecture. The general LURK architecture is described in the Session Key interface draft [I-D.cairns-tls-session-key-interface]. +------------+ Handshake +------------------+ LURK +------------+ | TLS Client | <---------> | TLS Server | <-------> | Key Server | +------------+ +------------------+ +------------+ Fieau & Stephan Expires January 9, 2017 [Page 3] Internet-Draft LURK for CDNI July 2016 Figure 1: General Key Server Architecture In CDNI, a LURK interface allows private keys to remain under the authority of its owner - typically the CSP or the uCDN - while delivering the content over HTTPS. The LURK interface can be introduced at different locations in the CDNI architecture. The location of the LURK function depends on the use cases. Additionally, this architecture may support variants where the Key server is owned by a third party. +------------+ Handshake +------------------+ LURK +--------------------------------+ | TLS Client | <---------> |dCDN TLS Surrogate| <-------> |(uCDN/CSP/3rd Party) Key Server | +------------+ +------------------+ +--------------------------------+ Figure 2: Key Server in CDNI Architecture This document complements the LURK architecture of [I-D.mglt-lurk-tls-use-cases] with CDNI use cases. In those use cases, content delivery is decoupled from both content acquisition and signaling information needed to route and control the request. Currently CDNI signaling exchanges occur over the Request Routing Redirection interface (information to route the request across CDNs), the Metadata interface (per content or group of content information about the acquisition and the delivery), the Logging interface (exchange of monitoring information about the delivery) and the Control interface (information for controlling the lifecycle of the aforementioned interfaces). The LURK interface for CDNI adds two types of exchange: one for acquiring the certificate associated with the origin domain and the other for establishing delivery confidentiality and integrity. This document presents two use cases of HTTPS delivery which rely on a LURK function to avoid exchanging private keys between CDNs: A. uCDN Key server: the CSP has provided his certificate and private keys to the uCDN. the uCDN provides the LURK key server and interface. B. CSP Key server: the CSP provides the LURK Key Server and interface. The table below presents the use cases developed in the Section 3. Fieau & Stephan Expires January 9, 2017 [Page 4] Internet-Draft LURK for CDNI July 2016 +-------------+--------------+----------------+-------------------+ |Use Case name|UA Redirection|uCDN redirection|CSP Cert delegation| +-------------+--------------+----------------+-------------------+ |UC A: uCDN KS|DNS CNAME |recursive |uCDN | +-------------+--------------+----------------+-------------------+ |UC B: CSP KS |DNS CNAME |recursive |No | +-------------+--------------+----------------+-------------------+ Figure 3: Use cases description table The use cases' call flows are respectful of the CDNI redirection [I-D.ietf-cdni-redirection] for the description of redirection methods in CDNI. They share the same steps. The figure below illustrates the framework use cases where the surrogate doesn't handle the CSP private keys and where the surrogate remotely accesses materials to sign and encrypt information exchanged over the TLS connection. +----+ +----------+ +----------+ +------+ | UA | |surrogate*| |Key Server| |Origin| +----+ +----------+ +----------+ +------+ |... | | | |1. TLS clientHello | | | |------------------->| | | | | | | | | | | |2. TLS serverHello |+-----------------+| | |<-------------------|| || | | || || | |3. Certificate || || | |<-------------------|| LURK Exchanges || | | ||<--------------->|| | | || || | | || || | | || || | | |+-----------------+| | |4. ServerKeyExchange| | | |<-------------------| | | |... Continued | | | Figure 4: LURK exchanges in CDNI architecture Fieau & Stephan Expires January 9, 2017 [Page 5] Internet-Draft LURK for CDNI July 2016 4. LURK use cases for CDNI Two use cases are considered in this document to implement LURK in CDNI: Use Case A. uCDN Key Server Use Case B. CSP Key Server 4.1. Use case A: uCDN Key Server In this use case, the dCDN has a LURK interface to a Key Server hosted at the uCDN side. It may be typically a case of CDNI regional delivery delegation. This following example is based on ECDHE cypher suite. The UA is first redirected from the uCDN to a dCDN using a recursive DNS redirection. Then the UA initiates a TLS connection with the dCDN to get his content. Since the dCDN does not store the private keys for the requested certificate, it queries the uCDN Key Server (KS) to get the credential to establish the TLS session with the User Agent. Finally the dCDN can deliver the content in HTTPS to the UA using the CSP certificate. The UA sends an HTTPS request to the CSP to get a content. a. to d. As seen on figure 5, once the DNS resolution is over, i.e., UA was able to resolve dCDN surrogate IP@ steps [a.] to [d.], the user agent connects to the dCDN surrogate. Note that DNS cache is not shown on the figure. 1. The UA sends a ClientHello, as defined in the TLS protocol [RFC5246]. The SNI field of the ClientHello includes the CSP domain name. 2. The surrogate receives the ClientHello from the UA, and sends a ServerHello to the UA. 3. The surrogate parses the SNI field, and determines the Key Server interface of the CSP domain name. The surrogate uses this piece of information to determine the certificate of the delivery. The surrogate sends the public certificate to the UA. The UA validates the certificate. 4. The surrogate determines the ECDHE parameters, and requests the Key Server to sign these parameters with the CSP private key. The request includes the domain name received by the surrogate in the SNI field of the ClientHello. Fieau & Stephan Expires January 9, 2017 [Page 6] Internet-Draft LURK for CDNI July 2016 5. The Key Server returns the necessary credentials to the dCDN surrogate over a secure tunnel. 6. and 7. the UA and the surrogate exchange public DH parameters and compute session keys. 8. The UA and the surrogate establish a secure connection. The UA issues its request for content over HTTPS. The surrogate then processes the original request. Below is an example of the handshake establishment: Fieau & Stephan Expires January 9, 2017 [Page 7] Internet-Draft LURK for CDNI July 2016 +----+ +----+ +-------+ +----+ | UA | |dCDN| |uCDN KS| |uCDN| +----+ +----+ +-------+ +----+ |a. DNS A? FQDN CSP | | | |---------------------------------------------------------------->| | | | | |b. DNS CNAME dCDN | | | |<----------------------------------------------------------------| | | | | |c. DNS A? dCDN | | | |------------------->| | | | | | | |d. DNS A IP Surrogate | | |<-------------------| | | | | | | |1. ClientHello (Client Random) | | |------------------->| | | | | | | |2. ServerHello (Server Random) | | |<-------------------| | | | | | | |3. Certificate (Server certificate) | | |<-------------------| | | | | | | | |4. LURK query for Signature (ECDHEParams) | | |------------------>| | | | | | | |5. LURK response: signature (ECDHEParams) | | |<------------------| | | | | | |6. ServerKeyExchange (ECDHParams, Signature) | |<-------------------| | | | | | | |7. ClientKeyExchange (clientDHpublic) | | |------------------->| | | |Finished | | | |<------------------>| | | | | | | |8. HTTPS request | | | |------------------->| | | Figure 5: Key Server hosted by uCDN Fieau & Stephan Expires January 9, 2017 [Page 8] Internet-Draft LURK for CDNI July 2016 4.2. Use case B: CSP Key Server This section describes a use case in CDNI where the CSP provides the Key Server (KS). In this example, the CSP delegates the HTTPS content delivery to an uCDN that in turn delegates the HTTPS delivery to a dCDN. For obvious legal or security reasons, the CSP does not want his private keys to be stored on all CDNs involved in the interconnection. In that case, the dCDN relies on credentials received from a CSP Key Server (KS) to deliver HTTPS content. The dCDN cannot here request the KS directly. Instead, the dCDN LURK request will be relayed by the uCDN to the Key Server. Prior to that, the uCDN has to check whether the received LURK request is valid, e.g., complies with Content Distribution policies [I-D.ietf-cdni-metadata]. In the following example, the CSP stores his certificates and private keys on a Key Server that is able to compute and provide credentials for TLS establishment. 1. The UA sends a ClientHello to the dCDN's surrogate, as defined in the TLS protocol [RFC5246]. The SNI field of the ClientHello includes the CSP domain name. 2. The dCDN's surrogate receives the ClientHello from the UA, and sends a ServerHello to the UA.. 3. The surrogate parses the SNI field, and determines the Key Server interface of the CSP domain name and determine the certificate of the delivery. The surrogate sends the public certificate to the UA. The UA checks the certificate signature with the public key. 4. The dCDN's surrogate requests the uCDN to sign parameters with the private key. 5. The uCDN parses the SNI field, and determines the Key Server interface of the CSP domain name. The uCDN relaies the LURK request received from the dCDN's surrogate, to the Key Server to sign parameters with the private key. 6. The Key Server returns the necessary credentials to the uCDN surrogate. 7. The uCDN returns the necessary credentials to the dCDN's surrogate. Fieau & Stephan Expires January 9, 2017 [Page 9] Internet-Draft LURK for CDNI July 2016 8. and 9. the UA and the surrogate exchange public DH parameters and compute session keys. 10. The UA and the surrogate establish a secure connection. The UA issues its request for content over HTTPS. The surrogate then processes the original request. +----+ +----+ +----+ +------+ | UA | |dCDN| |uCDN| |CSP KS| +----+ +----+ +----+ +------+ | (DNS redirection) | | | | | | | |d. DNS A IP Surrogate | | |<-------------------| | | | | | | |1. ClientHello (Client Random) | | |------------------->| | | | | | | |2. ServerHello (Server Random) | | |<-------------------| | | | | | | |3. Certificate (Server certificate) | | |<-------------------| | | | | | | | |4. LURK query for Signature (ECDHEParams) | | |------------------>| | | | |5. LURK query for sign. | | | |----------------------->| | | | | | | |6. LURK response | | | |<-----------------------| | | | | | |7. LURK response: signature (ECDHEParams) | | |<------------------| | | | | | |8. ServerKeyExchange (ECDHParams, Signature) | |<-------------------| | | | | | | |9. ClientKeyExchange (clientDHpublic) | | |------------------->| | | |Finished | | | |<------------------>| | | | | | | |10. HTTPS request | | | |------------------->| | | Fieau & Stephan Expires January 9, 2017 [Page 10] Internet-Draft LURK for CDNI July 2016 Figure 6: Cascaded delegation with LURK 4.3. Other use cases Other use cases will be described in a further version of this draft. 5. Requirements This section is a first attempt to identify the requirements introduced by the delivery of HTTPS content. Some of the requirements are new, whereas others may update existing CDNI requirements [RFC7337]. 5.1. General LURK-GEN-1: The specification should not require any change in User Agent. This is already stated in [RFC7337]/GEN-2 Discussion: Despite this is obvious, it is important to notice that recent limitation in TLS (version, cyphers...) or HTTP (cyphers) documents may constrain User Agent. LURK-GEN-2: The user agent should be able to see that the requested content is delivered by the CDN using the CSP domain. Delivery domain name SHOULD be the same as the CSP portal domain name (or a sub-domain request name) LURK-GEN-3: The Certificate delivered by the dCDN and CSP must match the domain of the URL [RFC2818]. As an example, it means that no certificate error occurs on the UA when the dCDN has redirected the UA a dCDN. LURK-GEN-4: The dCDN's surrogates which implements LURK interface should support the delivery of content of the protocol HTTPS. LURK-GEN-5: The dCDNs must be able to present the CSP certificate and credentials to the user agent when establishing a TLS session 5.2. CDNI Control Interface requirements LURK-CI-1: The CDNI Control Interface may allow the bootstrapping of a Key Server interface. For example this may include: - discovery the Key Server interface endpoint. - credentials for Key Server and CDN mutual authentication. - TLS version, Certificate types, TLS crypto suites. Fieau & Stephan Expires January 9, 2017 [Page 11] Internet-Draft LURK for CDNI July 2016 Proposal: add this requirement to the section CDNI Control Interface of [RFC7337]. 5.3. CDNI Footprint and Capabilities Advertisement interface requirements LURK-FC-1: The CDNI Footprint and Capabilities Advertisement interface should allow the downstream CDN to communicate to the upstream CDN about its capabilities regarding the support of client side of the Key Server interface. 5.4. CDNI Logging Interface requirements This section identifies additional requirements related to the CDNI Logging interface (LI). TLS-LI-1: the CDNI Logging interface should allow a dCDN to report to the uCDN logging for deliveries which fail during the establishment of the secure connection, e.g., ability to report certificate validation error. TLS-LI-2: The CDNI Logging interface should allow dCDN to report to uCDN logging incomplete deliveries due to encryption errors. Discussion: this requirement is mostly a subcase of LI-2 about incomplete deliveries. LURK-LI-3: the CDNI Logging interface should allow a dCDN to report to the uCDN secure connections failures when using LURK interface. As an example, the UA can't establish a secure connection to a dCDN because either, the credentials provided by a Key Server are invalid, or because the Key Server has refused to provide them to the dCDN. 5.5. Key Server Interface requirements LURK-KS-1: A Key Server interface must not allow the exchange private keys. This is the centrality of the LURK interface. LURK-KS-2: The Key Server and the requesting CDN must authenticate each other, according to the information provided by the CDNI Control interface. LURK-KS-3: The dCDN Key Server interface must be able to send a LURK request to a Key Server. As an example (UC A, step 4), the dCDN surrogate determines ECDHE parameters (...), and requests the Key Server to sign these Fieau & Stephan Expires January 9, 2017 [Page 12] Internet-Draft LURK for CDNI July 2016 parameters with the CSP private key. The request includes the domain name received by the surrogate in the SNI field of the ClientHello. 6. Discussions 6.1. HTTPS and TLS HTTPS contents are delivered with the dCDN credentials. The introduction of a Key Server in the CDNI architecture allows the HTTPS content to be delivered with the CSP origin server certificate. It conforms to the end-to-end HTTPS framework [RFC7230]. 6.2. Cyphersuites in CDNI CDNI WG and LURK WG should use a common set of cyphersuites, or CDNI WG should specify or points to the set of suites to support. TLS and HTTP2 recommend different set of cypher suites. CDNI WG should clarify which one should be supported in the case of a HTTPS delivery based on LURK credentials: HTTP2 Cipher Suite, refer to appendix A of [RFC7540] and "backwards-compatibility-security- restrictions" in [I-D.draft-ietf-tls-tls13"]. 6.3. PFS Should the delivery be PFS proof? 6.4. TLS version Which version of TLS should be supported by LURK: TLS/LTS, TLS1.2, TLS1.3? 6.5. Scalability For each TLS session initialization on the dCDNs, the dCDNs need to request the KS to get the necessary credentials. To be scalable, the KS may need to be replicated. 6.6. Certificates and security At least one private key per CSP is stored on the KS. Therefore the use of a KS avoids the complexity of duplicating private keys on uncontrolled servers. This also allows the uCDN to maintain a single domain name for the CDN interconnection. Fieau & Stephan Expires January 9, 2017 [Page 13] Internet-Draft LURK for CDNI July 2016 6.7. Revocation In the case of an HTTPS delegation revocation, a dCDN has no longer the delegation right to deliver a content for a given CSP. The uCDN would then deny access to CSP certificates and credentials derived from private keys, and therefore the dCDN would not be able to establish the TLS session without triggering a warning on UA Side. 6.8. Certificate provisioning The dCDN may have to retrieve at least once the CSP public certificate related to the targeted domain name. The certificates may be cached on the dCDN for a given duration. . Is certificate provisioning in the scope of CDNI as it seems implementation dependant? Which interface provides the certificates to the uCDN (Control, Metadata, LURK, ..)? 6.9. CSP side With regard to the use case B, the CSP may provide a Key server. As a consequence the requirement [RFC7337]/GEN-3 should be updated accordingly. 6.10. Acquisition Usage of the LURK interface when acquiring content: when the dCDN acquires content directly from the origin server, would it have to request first the KS to get the uCDN credentials ? 6.11. CDNI Control Interface vs CDNI Metadata Interface What should be carried by the CI or the MI ? 7. Open issues 7.1. TLS session resuming Not yet addressed in this document, contributors are welcome. 7.2. Stack Evolution Contents might be delivered over other protocols than TCP and than HTTP/1.1 in a close future. The CDNI WG must discuss the support of HTTPS delivery over TLS/LTS, TLSv3, DTLS, QUIC and HTTP2. Fieau & Stephan Expires January 9, 2017 [Page 14] Internet-Draft LURK for CDNI July 2016 8. IANA Considerations This document has no IANA considerations. 9. Security Considerations The entire document is about security. 10. Acknowledgments Many thanks to Benoit Gaussen who contributed to this draft. 11. References 11.1. Normative References [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, . [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, . [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . Fieau & Stephan Expires January 9, 2017 [Page 15] Internet-Draft LURK for CDNI July 2016 11.2. Informative References [I-D.cairns-tls-session-key-interface] Cairns, K., Mattsson, J., Skog, R., and D. Migault, "Session Key Interface (SKI) for TLS and DTLS", draft- cairns-tls-session-key-interface-01 (work in progress), October 2015. [I-D.erb-lurk-rsalg] Erb, S. and R. Salz, "A PFS-preserving protocol for LURK", draft-erb-lurk-rsalg-01 (work in progress), May 2016. [I-D.ietf-cdni-control-triggers] Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Triggers", draft-ietf-cdni-control-triggers-15 (work in progress), May 2016. [I-D.ietf-cdni-logging] Faucheur, F., Bertrand, G., Oprescu, I., and R. Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- logging-27 (work in progress), June 2016. [I-D.ietf-cdni-metadata] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "CDN Interconnection Metadata", draft-ietf-cdni- metadata-18 (work in progress), June 2016. [I-D.ietf-cdni-redirection] Niven-Jenkins, B. and R. Brandenburg, "Request Routing Redirection interface for CDN Interconnection", draft- ietf-cdni-redirection-18 (work in progress), April 2016. [I-D.ietf-tls-tls13] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", draft-ietf-tls-tls13-13 (work in progress), May 2016. [I-D.mglt-lurk-tls-use-cases] Migault, D., Ma, K., Salz, R., Mishra, S., and O. Dios, "LURK TLS/DTLS Use Cases", draft-mglt-lurk-tls-use- cases-02 (work in progress), June 2016. [LURK_Mailing_List] "LURK Mailing List", . Fieau & Stephan Expires January 9, 2017 [Page 16] Internet-Draft LURK for CDNI July 2016 Authors' Addresses Frederic Fieau (editor) Orange 40-48, avenue de la Republique Chatillon 92320 France Email: frederic.fieau@orange.com Emile Stephan Orange 2, avenue Pierre Marzin Lannion 22300 France Email: emile.stephan@orange.com Fieau & Stephan Expires January 9, 2017 [Page 17]