Subject: [Lurk] LURK usage scenario: cloud providers

From: Yaron Sheffer <[email-masked]>
Date: Sun, 28 Feb 2016 18:28:22 -0800

Hi,

Right now our only well understood use case is CDNs. I would like to
find out if there's community interest in a second use case.

IaaS cloud providers offer, in addition to virtual servers, also
load balancers [1] and API gateways [2]. It is very common to
terminate TLS on these "boxes" and then re-establish TLS into the
customer's cloud servers. It could make sense to use the LURK
protocol between the cloud provider and customer-controlled key
management servers, where the servers live either within the cloud
or off-cloud (e.g. using physical network connectivity [3]).

By the way, my examples all come from AWS because that's what I'm
familiar with, but other clouds do provide similar capabilities.

Please respond if you believe this is a valid and interesting use
case for LURK.

Thanks,

Yaron

[1] https://aws.amazon.com/elasticloadbalancing/

[2] https://aws.amazon.com/api-gateway/

[3] https://aws.amazon.com/directconnect/

---

From: Ted Hardie <[email-masked]>
Date: Mon, 29 Feb 2016 09:15:06 -0800

Hi Yaron,

On Sun, Feb 28, 2016 at 6:28 PM, Yaron Sheffer <[email-masked]>
wrote:

> Hi,
>
> Right now our only well understood use case is CDNs. I would like to find
> out if there's community interest in a second use case.
>
> IaaS cloud providers offer, in addition to virtual servers, also load
> balancers [1] and API gateways [2]. It is very common to terminate TLS on
> these "boxes" and then re-establish TLS into the customer's cloud servers.
> It could make sense to use the LURK protocol between the cloud provider and
> customer-controlled key management servers, where the servers live either
> within the cloud or off-cloud (e.g. using physical network connectivity
> [3]).
>
>
It seems possible to model the load balancers being offered as a
single-customer CDN, especially for the case where the load balancers are
distributed differently from the other sorts of resources (computation,
storage, etc.)  Can you unpack a bit what differences in that deployment
would mean for LURK?

regards,

Ted

By the way, my examples all come from AWS because that's what I'm familiar
> with, but other clouds do provide similar capabilities.
>
> Please respond if you believe this is a valid and interesting use case for
> LURK.
>
> Thanks,
>     Yaron
>
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk
>
>

---

From: Yoav Nir <[email-masked]>
Date: Mon, 29 Feb 2016 20:17:47 +0200

> On 29 Feb 2016, at 4:28 AM, Yaron Sheffer <[email-masked]> wrote:
> 
> Hi,
> 
> Right now our only well understood use case is CDNs. I would like to find out if there's community interest in a second use case.
> 
> IaaS cloud providers offer, in addition to virtual servers, also load balancers [1] and API gateways [2]. It is very common to terminate TLS on these "boxes" and then re-establish TLS into the customer's cloud servers. It could make sense to use the LURK protocol between the cloud provider and customer-controlled key management servers, where the servers live either within the cloud or off-cloud (e.g. using physical network connectivity [3]).
> 
> By the way, my examples all come from AWS because that's what I'm familiar with, but other clouds do provide similar capabilities.
> 
> Please respond if you believe this is a valid and interesting use case for LURK.
> 
> Thanks,
>     Yaron
> 
> [1] https://aws.amazon.com/elasticloadbalancing/ <https://aws.amazon.com/elasticloadbalancing/>
> [2] https://aws.amazon.com/api-gateway/ <https://aws.amazon.com/api-gateway/>
> [3] https://aws.amazon.com/directconnect/ <https://aws.amazon.com/directconnect/>

Hi, Yaron

The use case we have been discussing is "offload TLS without giving the CDN my private key”. 

In the use case you are describing, you have split AWS (or any other IAAS cloud) in two: one part is the load balancer, which terminates TLS. The other is the customer cloud server. Both of those nodes are under the control of Amazon. In fact, they might (although this is not likely for technical reasons) be running on the same piece of hardware. What is the justification for trusting the cloud provider to keep your private key safe on your cloud server, while not trusting that same cloud provider to not misuse your private key on the load balancer?

(hope you don’t mind that I’ve responded without believing this is a valid use case for LURK)

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 29 Feb 2016 17:04:26 -0800

On 02/29/2016 09:15 AM, Ted Hardie wrote:
> Hi Yaron,
>
> On Sun, Feb 28, 2016 at 6:28 PM, Yaron Sheffer <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Right now our only well understood use case is CDNs. I would like
>     to find out if there's community interest in a second use case.
>
> single-customer CDN, especially for the case where the load balancers 
> are distributed differently from the other sorts of resources 
> (computation, storage, etc.) Can you unpack a bit what differences in 
> that deployment would mean for LURK?
>
>
> regards,
>
> Ted
I'm not sure if this would require any changes to the protocol at all. 
But if we decide that this is an interesting use case, we'll need to 
evaluate any protocol we come up with against it.

Thanks,
     Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 29 Feb 2016 17:09:33 -0800

>> balancers [1] and API gateways [2]. It is very common to terminate 
>> TLS on these "boxes" and then re-establish TLS into the customer's 
>> cloud servers. It could make sense to use the LURK protocol between 
>> the cloud provider and customer-controlled key management servers, 
>> where the servers live either within the cloud or off-cloud (e.g. 
>> using physical network connectivity [3]).
>>
>> [1]https://aws.amazon.com/elasticloadbalancing/
>> [2]https://aws.amazon.com/api-gateway/
>> [3]https://aws.amazon.com/directconnect/
>
> Hi, Yaron
>
> In the use case you are describing, you have split AWS (or any other 
> IAAS cloud) in two: one part is the load balancer, which terminates 
> TLS. The other is the customer cloud server. Both of those nodes are 
> under the control of Amazon. In fact, they might (although this is not 
> likely for technical reasons) be running on the same piece of 
> hardware. What is the justification for trusting the cloud provider to 
> keep your private key safe on your cloud server, while not trusting 
> that same cloud provider to not misuse your private key on the load 
> balancer?
>
So the whole point of this discussion is to explain why people think 
that this is (or is not) a valid use case! Thank you for that.

And to answer your point, there are futuristic ways (Intel SGX 
architecture and its "enclaves") to protect stuff from the cloud 
provider. More realistically, you may have the TLS signing box in your 
data center, connected to the cloud with a VPN, and separate from the 
actual web server.

Thanks,
     Yaron