Subject: [Lurk] FW: New Version Notification for draft-mglt-lurk-tls-use-cases-00.txt

From: Daniel Migault <[email-masked]>
Date: Tue, 19 Jan 2016 22:20:28 +0000

Hi, 

I am starting a new threat on the use cases. I would be glad to check the document describes the problem we want to solve.

Feel free to comment. 

BR, 
Daniel 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 19, 2016 4:40 PM
To: Kevin Ma J; Daniel Migault; Kevin Ma J
Subject: New Version Notification for draft-mglt-lurk-tls-use-cases-00.txt

A new version of I-D, draft-mglt-lurk-tls-use-cases-00.txt
has been successfully submitted by Daniel Migault and posted to the IETF repository.

Name:		draft-mglt-lurk-tls-use-cases
Revision:	00
Title:		TLS/DTLS Content Provider Edge Server Split Use Case
Document date:	2016-01-19
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-mglt-lurk-tls-use-cases-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mglt-lurk-tls-use-cases/
Htmlized:       https://tools.ietf.org/html/draft-mglt-lurk-tls-use-cases-00

Abstract:
   TLS as been designed to setup and authenticate transport layer
   between endpoints.

   A lot of applications are using TLS in order to set communications
   between the applications end points.

   As long as applications end points and transport end points were
   combined into the same host, application authentication could be
   combined with the transport authentication.

   As the current internet is decoupling the transport and application
   layers, such model may not be applicable anymore.  In other words,
   TLS authentication cannot be handled on behalf of the application
   authentication.

   This document describes use cases where the authentication of the
   transport layer differs from the authentication performed at the
   application layer.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jan 2016 19:58:30 +0200

Hi Lurkers,

I understand the value of the session-key interface (SKI) protocol, as a 
way to compartmentalize the web server and the key server.

But I'm still kind of fuzzy about the threat model for LURK, because:

  * The edge server will still have access to the exact same traffic as
    the content server, including sensitive data, credentials etc.
  * Unfortunately, many or most people who use CDNs, load balancers and
    API gateways to "terminate SSL", do exactly that: traffic between
    the edge server and the content provider goes in the clear. So
    improving the security of the SSL private key is the least of our
    problems.

So it seems to me that the value of the SKI protocol is mostly in a 
tightly managed web server scenario, rather than the typical use of CDNs.

What am I missing?

Thanks,

     Yaron

On 01/20/2016 12:20 AM, Daniel Migault wrote:
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jan 2016 19:53:24 +0000

> • Unfortunately, many or most people who use CDNs, load balancers and API gateways to "terminate SSL", do exactly that: traffic between the edge server and the content provider goes in the clear. So improving the security of the SSL private key is the least of our problems.

I don't know about many or most.  Certainly all of our "secure delivery" customers terminate the TLS connection at our edge servers, but then we do TLS back to the origin.  You can't do PCI or HIPAA traffic without that.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jan 2016 20:23:45 +0000

> Unless I'm missing something, the security value of this idea is that the "key
> server" can immediately cut off a known compromised "edge server". No
> need to wait for cert revocation to propagate. It seems that this may be
> useful in some deployments.

And also the key can be maintained more securely (presumably) by the origin.  And revocation?  With browsers?  How does that work, exactly? :)

> I'm not entirely convinced that there's a need to standardize the protocol
> between the "key server" and the "edge server" (such as SKI). E.g. do you
> envision the same "content owner" using both CloudFlare's and Akamai's
> "edge servers"?

Many large sites have agreements with multiple CDN's, yes.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jan 2016 22:24:19 +0200

Hi Andrei,

The point of having a standard is not only to enable using two CDNs 
concurrently, but to enable customers to easily move between e.g. Akamai 
and CloudFlare, thereby creating competition.

Disclaimer: I am not an economist :-)

Thanks,
     Yaron

On 01/22/2016 10:14 PM, Andrei Popov wrote:
> Unless I'm missing something, the security value of this idea is that the "key server" can immediately cut off a known compromised "edge server". No need to wait for cert revocation to propagate. It seems that this may be useful in some deployments.
>
> I'm not entirely convinced that there's a need to standardize the protocol between the "key server" and the "edge server" (such as SKI). E.g. do you envision the same "content owner" using both CloudFlare's and Akamai's "edge servers"?
>
> Cheers,
>
> Andrei
>
> From: Lurk [mailto:[email-masked]] On Behalf Of Salz, Rich
> Sent: Friday, January 22, 2016 11:53 AM
> To: Yaron Sheffer <[email-masked]>; Daniel Migault <[email-masked]>; [email-masked]
> Subject: Re: [Lurk] Use cases and threats, was: Re: FW: New Version Notification for draft-mglt-lurk-tls-use-cases-00.txt
>
>> * Unfortunately, many or most people who use CDNs, load balancers and API gateways to "terminate SSL", do exactly that: traffic between the edge server and the content provider goes in the clear. So improving the security of the SSL private key is the least of our problems.
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2flurk&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c6ac4cee257df43b8de9a08d32365b3e0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=K971KDAeuLMstihr24kdrhhLA9DJwvrfSGbJvk%2fv0dw%3d

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 22 Jan 2016 22:39:57 +0200

> And also the key can be maintained more securely (presumably) by the origin.  And revocation?  With browsers?  How does that work, exactly? :)
We should also consider the use case where the CDN provider deploys a 
key server locally, and connects to it with SKI (probably for a very 
large number of customer keys). As a content owner you still need to 
surrender your precious private key, but if something happens to the 
edge server, you don't need to rely on revocation.

Thanks,
     Yaron

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Jan 2016 20:42:32 +0000

> We should also consider the use case where the CDN provider deploys a key
> server locally, and connects to it with SKI (probably for a very large number of
> customer keys). As a content owner you still need to surrender your precious
> private key, but if something happens to the edge server, you don't need to
> rely on revocation.

Also perhaps a global entity doing business in countries that might demand keys.

---

From: Andrei Popov <[email-masked]>
Date: Fri, 22 Jan 2016 20:14:41 +0000

Cheers,

Andrei

---

From: Andrei Popov <[email-masked]>
Date: Fri, 22 Jan 2016 20:44:53 +0000

> Many large sites have agreements with multiple CDN's, yes.

If this use case exists, then yes there's a benefit in standardizing.

Cheers,

Andrei

-----Original Message-----
From: Salz, Rich [mailto:[email-masked]] 
Sent: Friday, January 22, 2016 12:24 PM
To: Andrei Popov <[email-masked]>; Yaron Sheffer <[email-masked]>; Daniel Migault <[email-masked]>; [email-masked]
Subject: RE: [Lurk] Use cases and threats, was: Re: FW: New Version Notification for draft-mglt-lurk-tls-use-cases-00.txt

> Unless I'm missing something, the security value of this idea is that 
> the "key server" can immediately cut off a known compromised "edge 
> server". No need to wait for cert revocation to propagate. It seems 
> that this may be useful in some deployments.

> I'm not entirely convinced that there's a need to standardize the 
> protocol between the "key server" and the "edge server" (such as SKI). 
> E.g. do you envision the same "content owner" using both CloudFlare's 
> and Akamai's "edge servers"?