Subject: [Lurk] Fwd: New Version Notification for draft-sheffer-lurk-cert-delegation-00.txt

From: Yaron Sheffer <[email-masked]>
Date: Fri, 13 May 2016 00:10:14 +0300

Hi,

To solve the CDN-shouldn't-get-my-private-key scenario, I propose an 
almost trivial REST API, where the CDN contacts the content owner once a 
day and obtains a 3 day credential (private key plus short-term cert).

Comments are welcome!

Thanks,
	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for 
draft-sheffer-lurk-cert-delegation-00.txt
Date: Thu, 12 May 2016 13:43:49 -0700
From: [email-masked]
To: Yaron Sheffer <[email-masked]>

A new version of I-D, draft-sheffer-lurk-cert-delegation-00.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-sheffer-lurk-cert-delegation
Revision:	00
Title:		Delegating TLS Certificates to a CDN
Document date:	2016-05-12
Group:		Individual Submission
Pages:		8
URL: 
https://www.ietf.org/internet-drafts/draft-sheffer-lurk-cert-delegation-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-sheffer-lurk-cert-delegation/
Htmlized: 
https://tools.ietf.org/html/draft-sheffer-lurk-cert-delegation-00

Abstract:
    An organization that owns web content often prefers to delegate
    hosting of this content to a Content Delivery Network (CDN).  To
    serve HTTP content securely, it needs to be protected with TLS.  This
    document proposes a way for the CDN to request constrained
    certificates so that it can serve web content on behalf of the
    content owner, without having the owner's long term certificate.

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: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 25 May 2016 10:00:00 +0000

Hi Yaron,

>day and obtains a 3 day credential (private key plus short-term cert).

Thanks very much for the draft.

Your proposal has a few good properties:
- It's very simple, with minimal impact on existing implementations and
deployments;
- It scales very well, because it drastically reduces the number of calls
to the LURK box (somewhere about 10 orders of magnitude less than the
other proposals), and because it removes the need for keeping the LURK
box near the edge - and thus deploying more boxes as the CDN footprint
grows -- if the application cares about time-to-first-byte, as it usually
does;
- It makes the CDN less dependent on the availability of the LURK box;
- Lastly, it seems to provide the right ecosystem for solving the well
known revocation issues ([1], [2]) -- very similarly to a proposal from
Topalovic et al. [3].

The only "minus" point is that the CDN still holds the content provider's
private key.  In fact, in your proposal, the "Remote Keys" in the LURK
acronym aren't remote at all :-)

Cheers, t

[1] https://www.imperialviolet.org/2011/03/18/revocation.html
[2] https://www.imperialviolet.org/2014/04/29/revocationagain.html
[3] http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 May 2016 16:46:36 +0300

> [3] http://www.w2spconf.com/2012/papers/w2sp12-final9.pdf

We could always rename the group LUCK - C for "cached"...

Or else we could decide that we have another use case for remote signing 
boxes, one that's better than CDNs.

Thanks,
	Yaron

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Thu, 26 May 2016 08:52:41 +0000

>boxes, one that's better than CDNs.

Just to clarify: what are you proposing above in relationship to the
proposed charter 
(https://www.ietf.org/mail-archive/web/lurk/current/msg00080.html) is:
(a) To extend it to include the "ephemeral keys" use-case/solution
alongside the TLS interface?
(b) To change LURK into LUCK and get rid of the TLS interface?

Cheers, t

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 26 May 2016 15:14:20 +0300

> (b) To change LURK into LUCK and get rid of the TLS interface?

Yes, either (a) or (b) would work for me. But if we choose (a), I think 
we ought to provide a use case that would justify the effort.

Thanks,
	Yaron