Subject: [Lurk] LURK: proposed charter for review

From: Yaron Sheffer <[email-masked]>
Date: Thu, 7 Jul 2016 23:20:23 +0530

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.

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Thu, 7 Jul 2016 20:32:59 -0400

Yaron,

On the charter text, I have one minor change as follows:

> Classic HTTPS authenticates the server by proving ownership of a private key …
Classic HTTPS authenticates the server by verifying ownership of a private key …

-Sanjay

From: Lurk [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Thursday, July 07, 2016 1:50 PM
To: LURK BoF
Subject: [E] [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.

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

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 08:02:02 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 7 July 2016 18:50
To: LURK BoF <[email-masked]<mailto:[email-masked]>>
Subject: [Lurk] LURK: proposed charter for review

Hi Everyone,

Thanks,
    Eric and Yaron

---

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 8 Jul 2016 18:52:30 +0530

Hi Thomas,

I agree that we should not preclude future extensions. But this can be 
done with a variety of tools, including a simple protocol version 
number. Do you think something more extensive is called for? If so, can 
you offer some charter text?

Thanks,
	Yaron

On 08/07/16 13:32, Fossati, Thomas (Nokia - GB) wrote:
> 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 <[email-masked] <mailto:[email-masked]>> on
> behalf of Yaron Sheffer <[email-masked]
> <mailto:[email-masked]>>
> To: LURK BoF <[email-masked] <mailto:[email-masked]>>
> 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.
>
> - 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.
>

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 8 Jul 2016 15:13:00 +0000

Hi Yaron,

On 08/07/2016 14:22, "Lurk on behalf of Yaron Sheffer"
<[email-masked] on behalf of [email-masked]> wrote:
>number.

A version number works well in the context of a single interface, not if
we want have multiple interfaces under the LURK umbrella (see below).

>Do you think something more extensive is called for?

At the moment we have two main competing solutions: yours (let's call it
"cert-delegation") and Daniel's/Rich&Sam's (the "tls-signing-box").

I'm not sure whether only one will survive, or both will be standardised
as LURK interfaces?

If the latter, I'd probably want to have a way to know whether my edge
cache has to talk using the "cert-delegation" and/or "tls-signing-box"
interface with content provider X without having to turn knobs here and
there to make it happen :-)

Cheers, t

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 8 Jul 2016 15:15:05 +0000

> there to make it happen :-)

If it's REST-based, then we just have different URL's, right?

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Sat, 9 Jul 2016 10:00:38 +0000

Hi Rich,

On 08/07/2016 16:15, "Lurk on behalf of Salz, Rich" <[email-masked]
>If it's REST-based, then we just have different URL's, right?

Could you unpack this a bit?

(In particular I don't see REST interfaces defined in draft-erb-lurk-rsalg
or draft-mglt-lurk-tls... Do you plan to have one?)

Cheers, t

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 9 Jul 2016 14:35:51 +0000

> (In particular I don't see REST interfaces defined in draft-erb-lurk-rsalg or
> draft-mglt-lurk-tls... Do you plan to have one?)

Those documents only describe the content, not the HTTP/REST bindings.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 17 Jul 2016 16:06:29 +0200

Hi Thomas,

For the record (and sorry for the late reply): I think it would be a 
terrible idea to standardize both approaches. I obviously prefer one of 
them, but I think it is way more important to have one single standard 
solution for the industry to use. If we form a working group, it will be 
up to the WG to decide which of the options solves best the use case in 
question.

Thanks,
     Yaron

---

From: Василий Долматов <[email-masked]>
Date: Sun, 17 Jul 2016 23:43:37 +0200

> 17 июля 2016 г., в 16:06, Yaron Sheffer <[email-masked]> написал(а):
> 
> Hi Thomas,
> 
> For the record (and sorry for the late reply): I think it would be a terrible idea to standardize both approaches. I obviously prefer one of them, but I think it is way more important to have one single standard solution for the industry to use. If we form a working group, it will be up to the WG to decide which of the options solves best the use case in question.
Ein Reiche, ein Volk, ein Fuehrer?

Pfff..,,

dol@

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 18 Jul 2016 01:59:56 -0400

I think we are making a classic error here.

A standard should always have a use case driving it. But standards that are
designed to only meet the needs of one use case tend to end up in systems
that are more complicated and less powerful than those designed to provide
a particular function.

PKIX got the way it did because it is an agglomeration of point solutions
to narrow use cases.

On Sun, Jul 17, 2016 at 5:43 PM, Василий Долматов <[email-masked]>
wrote:

> solution for the industry to use. If we form a working group, it will be up
> to the WG to decide which of the options solves best the use case in
> question.