Subject: [Lurk] Understanding the problem space better

From: Watson Ladd <[email-masked]>
Date: Mon, 29 Feb 2016 18:33:10 -0800

Dear all,
Apologies if this was discussed before, but there are some aspects of
the problem that I need to think through a bit more.

1: Do we want a private key operation to be done for each TLS
connection to a CDN by the content provider? If so, what does the use
of the CDN gain?

2: What stops a CDN from modifying the content provided with LURK any
more than if it had the private key?

3: What stops CDNs from using very long tickets to prevent ending the
online signing from immediately ending the ability to impersonate a
site?

Sincerely,
Watson

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Mar 2016 08:55:11 +0200

Hi, Watson

> connection to a CDN by the content provider? If so, what does the use

We should separate the problem or requirement (“I don’t want to give my private key to the CDN or the cloud provider”) from the proposed solution (“I’ll sign the ServerKeyExchange using my own box, in my own datacenter for each TLS handshake”). 

I think the big reason to use CDNs and cloud services is to save the costs associated with maintaining a server in my datacenter with the scalability, reliability, availability and other buzzwords. A “sign every transaction” solution negates all that. Another reason to use CDNs is that they reduce latency by having a server close to the client. That goes out the window as well if you have to go back to the customer’s data center to sign each handshake.

> more than if it had the private key?

Nothing. You still trust the CDN to distribute *your* content rather than MRA propaganda.

> online signing from immediately ending the ability to impersonate a

Nothing that I know of. You still need to trust the CDN to be ethical.

IMO a better solution to the problem would be some sort of secure delegation. If you dig www.ietf.com you will find that it is a CNAME for www.ietf.org.cdn.cloudflare-dnssec.net. What would be a good solution IMO is if the CloudFlare server could present a certificate for www.ietf.org.cdn.cloudflare-dnssec.net. There are two obstacles for this:
 1. DNSSEC is not everywhere, so browsers can’t trust the CNAME
 2. Browsers don’t know any new secure delegation mechanism that we might invent here.

So any secure delegation mechanism would only work with new browsers that implemented it. The proposal in the drafts works with existing browsers.

Yoav