Re: [Lurk] [E] Re: Proposed Lurk Charter

["Mishra, Sanjay" <[e-mail]>]

Eric -- My suggested change to charter text is below 
> HTTPS in typical use authenticates the server by proving ownership of a private key
Should you say " HTTPS in typical use authenticates the server by verifying ownership of a private key?

> 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.

I think this assumption can still be true and not entirely in the past. If you agree then the tweak could be something like this:
 "Although these assumptions may still be true, today, the deployment of services on the current Internet largely relies on multiple distributed instances of the service."

Thanks
Sanjay

-----Original Message-----
From: Lurk [mailto:[e-mail]] On Behalf Of Eric Burger
Sent: Sunday, March 13, 2016 4:30 PM
To: LURK BoF
Subject: [E] Re: [Lurk] Proposed Lurk Charter

I updated the draft charter with Stephen’s comments.  Not hearing anything for a week tells me either no one has read the proposed charter, everyone thinks it is great, or everyone thinks it is a waste of time and would like their two hours back in BA (BOF scheduled for 2PM on Tuesday, 5 April, in Atlantico C).

I’m trying something totally new and unknown in the IETF for the first deliverable.  Let me know your opinions.

This is one of those times when it is OK to simply say ‘OK’ or +1 or ‘Yuck’ or -1.

Thanks.



On Mar 6, 2016, at 9:40 AM, Eric Burger <[e-mail]> wrote:

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.

This work group will not address the Email and STIR use cases of an enterprise or individual delegating their private key to a service provider for signing messages on their behalf.

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 stable with consensus to content
Feb 2017   HTTPS delegated protocol Document to IESG
Jun 2017   DTLS delegated protocol Document to IESG
Oct 2016	  Requirements and Use Cases 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