Re: [Lurk] LURK: proposed charter for review

["Fossati, Thomas (Nokia - GB)" <[e-mail]>]

Hi Yaron, Eric,

Looks good, thanks.

A note: LURK should have a good capability discovery mechanism as well. This is key to allow protocol extensions & to accommodate other use cases that may come up in the future.  I would say this is in scope, and should be spelled out clearly in the charter?

Cheers, t

From: Lurk <[e-mail]<mailto:[e-mail]>> on behalf of Yaron Sheffer <[e-mail]<mailto:[e-mail]>>
Date: Thursday, 7 July 2016 18:50
To: LURK BoF <[e-mail]<mailto:[e-mail]>>
Subject: [Lurk] LURK: proposed charter for review

Hi Everyone,

LURK is having a second BoF meeting in Berlin, and we hope to conclude it by forming a WG. Below is proposed charter text for this tentative WG. Eric and I would like to initiate the discussion before we meet in Berlin and then use the meeting for issues that require deeper discussion and/or to get feedback from people who are not regulars on this list.

Thanks,
    Eric and Yaron

---

Classic HTTPS authenticates the server by proving ownership of a private key associated with a public-key certificate. Most trust models assume an HTTP server owns the private keys and the server is responsible for both the hosted content and network delivery. Although these assumptions were largely true in the past, today the deployment of services on the Internet largely relies on multiple, distributed instances of the service, not necessarily operated by the content owner. In such architectures, the application - like a web browser - expects to authenticate a content provider but is actually authenticating the node delivering the content. In this case, confusion results from using a secure transport layer to authenticate application layer content.

The WG will focus on a solution that allows offloading TLS termination to a content delivery network (CDN) without giving the content owner's private key to the CDN. In scope are TLS and DTLS, including TLS 1.0-1.2 and, when available, TLS 1.3. This working group will not propose any changes to the client side of the TLS protocol, and the solution should support all widely deployed TLS cipher suites.

The current work items include:

- An Informative "use cases" document, which will cover the CDN use case but may encompass additional use cases.

- A Standards Track document that defines the interface between an edge server and a content owner. Security is a key concern, specifically avoiding a "signing oracle" where possible. Provisioning/management/monitoring of the protocol's endpoint is out of scope of the working group.

Delegation of RSA/ECDSA keys for other purposes is out of the scope of the working group. Such work would require the working group to recharter.