[Lurk] Proposed Lurk Charter

[Eric Burger <[e-mail]>]

It seems we are making progress on the scope discussion on the list, as much about what we want to do as we do not want to do. Given that, and with an eye to BA, let us tear apart the following charter. It would be fantastic to have some thought out text to show the broader IETF community in April.

Note the charter references at least two different proposals for achieving the goals. I see this as a good thing: it means we are not researching science fiction (a hallmark of failed IETF work groups) and rather are doing engineering (a hallmark of successful IETF work groups). It also says we are not rubber-stamping some vendor’s proprietary protocol, which just tastes bad.

Comments please!




Description of Working Group:
HTTPS in typical use authenticates the server by proving ownership of a private key, which is associated with a public-key certificate. Currently most trust models assume the HTTP server owns the private keys, and that the server is responsible for both the hosted content and for the network delivery. Although these assumptions were somewhat true in the past, today, the deployment of services on the current Internet largely relies on multiple distributed instances of the service. Similarly, the delivery of popular content often splits the roles of providing the content and delivering the content. 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, the confusion mostly results from using a secure transport layer to authenticate application layer content.

This work group will provide a solution to the  "offload TLS without giving the CDN my private key" use-case. The work group may also provide support for DTLS in anticipation of future secure protocols.

Email has a related use case, specifically how to off-load DKIM signing. However, DKIM already has fielded solutions to address this problem and there does not appear to be a significant need. SIP has a related use case, specifically the STIR use case of an enterprise or individual delegating their private key to a service provider for signing messages on their behalf. However, the use and management of the keys in that case are sufficiently different from the LURK use cases that it is not in scope for this work group.

Related Work:
OASIS developed the Key Management Interoperability Protocol (KMIP) <http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html> as well as PCKS #11, Cryptographic Token Interface <http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html>.


Goals and Milestones:
Oct 2016	  Requirements and Use Cases Document to IESG
Feb 2017   HTTPS delegated protocol Document to IESG
Jun 2017   DTLS delegated protocol Document to IESG




Reading list
• ​https://tools.ietf.org/html/draft-mglt-lurk-tls-requirements
• ​https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases
• ​https://tools.ietf.org/html/draft-cairns-tls-session-key-interface
• ​https://tools.ietf.org/html/draft-hallambaker-mesh-architecture