Subject: [Lurk] Proposed Lurk Charter

From: Eric Burger <[email-masked]>
Date: Sun, 6 Mar 2016 09:40:48 -0600

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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 6 Mar 2016 16:01:57 +0000

Hiya,

Thanks for that. Tell me when you want me to put some version
of this into the datatracker.

A couple of mostly process points below...

On 06/03/16 15:40, Eric Burger 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.
> 
> 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.

While it is useful to have the above text for now, for a final
charter, I think that'd be better reduced to e.g. "Email and STIR
are out of scope" without saying why. (The logic being that saying
why allows someone to argue with that and try to bring 'em back
in scope;-) I'm fine that a change like that is done at the last
minute.

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

There are mixed opinions within the IESG about the value of documents
such as the above. I'm agnostic myself, but in this case I do wonder
if we'd be better off spending time getting consensus on the text of
the above, or on working on the stuff below. IOW, it might be better
if the requirements text that is needed ends up as part of one of the
docs below. Another option might be to develop the requirements text
in an I-D, do a WGLC on that, but then to not send it to the IESG
until the end of the game. That way the WG could agree the few hard
things about requirements that'll need be agreed, but the WG might
avoid the overhead and energy-sapping work of doing use-cases docs.

Cheers,
S.

> 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
> 
> 
> 
> _______________________________________________ Lurk mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/lurk
>

---

From: Eric Burger <[email-masked]>
Date: Sun, 6 Mar 2016 10:06:39 -0600

> On Mar 6, 2016, at 10:01 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
[snip]
> in scope;-) I'm fine that a change like that is done at the last

I think that is great.

[snip]

> avoid the overhead and energy-sapping work of doing use-cases docs.

As laziness is the mother of invention, less work for you, me, and the work group sounds great.
[snip]

---

From: Eric Burger <[email-masked]>
Date: Sun, 13 Mar 2016 15:29:36 -0500

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 <[email-masked]> wrote:

Comments please!

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:

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

---

From: Василий Долматов <[email-masked]>
Date: Mon, 14 Mar 2016 09:31:11 +0300

> 13 марта 2016 г., в 23:29, Eric Burger <[email-masked]> написал(а):
> 

OK for the start

dol@

> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 14 Mar 2016 09:46:28 +0300

Dear Eric,

On Sun, Mar 13, 2016 at 11:29 PM, Eric Burger <[email-masked]>
wrote:

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

Ok.

-- 
SY, Dmitry Belyavsky

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Tue, 15 Mar 2016 22:44:24 -0400

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:[email-masked]] On Behalf Of Eric Burger
Sent: Sunday, March 13, 2016 4:30 PM
To: LURK BoF
Subject: [E] Re: [Lurk] Proposed Lurk Charter

Thanks.

Comments please!

Related Work:

Goals and Milestones:

Reading list

---

From: Eric Burger <[email-masked]>
Date: Thu, 17 Mar 2016 12:20:55 -0400

Looks good to me. Anyone else with comments?

> On Mar 15, 2016, at 10:44 PM, Mishra, Sanjay <[email-masked]> wrote:
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 17 Mar 2016 12:29:25 -0400

I think we should meet and discuss before wordsmithing a charter.

When you start to consider how this would be implemented in practice
it is obvious that it is actually a three party protocol, not two as
the charter seems to assume.

The Key Service is ideally going to be in some form of HSM that does
not have a keyboard or a screen. You are going to want to control the
operation of that HSM. And you are going to want to bound those
operations using cryptography wherever possible.

So the administration interface is going to be separate from the
use-key interface.

It is even quite likely that you are going to want to outsource the Key Service.