Subject: [Lurk] New Document

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 18 Mar 2016 22:09:06 -0400

The following document describes my proposed LURK protocol and
contains examples from the code:

https://tools.ietf.org/html/draft-hallambaker-lurk-00

I will upload the code for the client/server/documentation to GitHub next week.

The document formatting is a little off in places but I should have
that fixed. Thought I would get the -00 out of the way so I was not
racing to fix formatting errors.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 20 Mar 2016 22:30:19 +0200

Hi Phillip,

The focus of the document is on a split-key solution for the "key 
server" problem. But from an engineering perspective, the ACME-based 
solution may be much more appropriate for our sole use case. In this 
solution, the CDN only gets a 1-day valid certificate at any given time.

Sec. 2.1 of the draft [1] describes this solution at a high level, but 
it glances over the gaps that remain, even with ACME specified and 
implemented. What it is missing (and we might want to add) is a way for 
the CDN to ask the Content Owner for a policy-restricted (e.g., 1 day) 
cert+key. Alternatively, a way for the Content Owner to obtain a 
restricted credential for ACME that would allow the CDN to provision its 
policy-restricted certs directly from the ACME server, until the 
long-term credential is revoked.

Thanks,
     Yaron

[1] https://tools.ietf.org/html/draft-hallambaker-lurk-00#section-2.1

On 03/19/2016 04:09 AM, Phillip Hallam-Baker wrote:
> _______________________________________________
> Lurk mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lurk

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Mar 2016 17:21:13 -0400

On Sun, Mar 20, 2016 at 4:30 PM, Yaron Sheffer <[email-masked]> wrote:
> Hi Phillip,
>
> The focus of the document is on a split-key solution for the "key server"
> problem. But from an engineering perspective, the ACME-based solution may be
> much more appropriate for our sole use case. In this solution, the CDN only
> gets a 1-day valid certificate at any given time.

Yes, I do not consider CDNs to be a compelling use case for remote keys.

Hence the idea of picking CDNs as the use case and doing the usual
thing of 'lets focus on just one use case' looks even worse than
usual.

There are many compelling use cases for remote keying. CDNs is not one of them.

> Sec. 2.1 of the draft [1] describes this solution at a high level, but it
> glances over the gaps that remain, even with ACME specified and implemented.
> What it is missing (and we might want to add) is a way for the CDN to ask
> the Content Owner for a policy-restricted (e.g., 1 day) cert+key.
> Alternatively, a way for the Content Owner to obtain a restricted credential
> for ACME that would allow the CDN to provision its policy-restricted certs
> directly from the ACME server, until the long-term credential is revoked.

That is all good stuff that I think we need to transfer to ACME.

To the extent that CDNs are a use case, I think it is clear that ACME
and LURK should look as similar as possible. So the control interfaces
should be JSON over HTTP, etc.

This is one reason I really want to get rid of the flat encoding in
ACME. A data serialization should put the data type ahead of the data
in the output stream, not at a random location inside it.

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 20 Mar 2016 22:28:09 +0000

> Hence the idea of picking CDNs as the use case and doing the usual thing of
> 'lets focus on just one use case' looks even worse than usual.
> 

This doesn't seem to be what has been discussed so far.  Have I missed anything?  

> To the extent that CDNs are a use case, I think it is clear that ACME and LURK
> should look as similar as possible. So the control interfaces should be JSON
> over HTTP, etc.

FWIW, I disagree.  I see zero reason for them to be the same.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Mar 2016 00:29:41 +0200

On 20 Mar 2016, at 11:21 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> and LURK should look as similar as possible.

I must be missing something. What this proposed WG is trying to do is "offload TLS without giving the CDN my private key”. The end result of the CDN running ACME is that the CDN has a private key with a certificate for your domain that matches the private key. How is that not “giving the CDN my private key”?

I don’t believe that restricting a certificate to one day is enough of a mitigation to whatever evils the CDN might do that caused us to avoid giving them the private key in the first place. 

Besides, do 1-day certs really work?  Are the clocks in HTTPS clients (not just browsers!) set accurately enough that we won’t get a bunch of them screaming that the certificate is not yet valid or already expired?

Yoav

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Mar 2016 21:19:25 -0400

On Sun, Mar 20, 2016 at 6:29 PM, Yoav Nir <[email-masked]> wrote:
> I must be missing something. What this proposed WG is trying to do is "offload TLS without
>giving the CDN my private key”. The end result of the CDN running ACME is that the CDN has a
>private key with a certificate for your domain that matches the private key. How is that not “giving
>the CDN my private key”?

That is a mechanism, not a requirement. The requirement was to
mitigate risk of private key reuse in the CDN case.

> Besides, do 1-day certs really work?  Are the clocks in HTTPS clients (not just browsers!) set accurately enough that we won’t get a bunch of them screaming that the certificate is not yet valid or…

Last time I heard the figures, they were pretty good but that was a
year ago. I will ask what the latest numbers are.

My point is not 'lets not do this' but rather that there are more ways
to address that particular use scenario.

There are many compelling use cases for a remote key service that are
much stronger and don't have alternative approaches. So why on earth
pick one of the least compelling use cases and design as if that is
the only one? That makes no sense to me.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Mar 2016 14:46:12 +0200

> the only one? That makes no sense to me.

So far the only use case we have mailing list consensus on is the CDN. 
If you have other, more compelling use cases in mind, I suggest that you 
describe them on the list (and in the F2F meeting) and rally more people 
behind them.

Personally, I think the CDN use case is justified, and I think it 
deserves a good solution even if that solution is not a key service but 
something a lot simpler.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Mar 2016 15:11:41 +0200

>> To the extent that CDNs are a use case, I think it is clear that
>> ACME and LURK should look as similar as possible.
>
> I must be missing something. What this proposed WG is trying to do is
> "offload TLS without giving the CDN my private key”. The end result
> of the CDN running ACME is that the CDN has a private key with a
> certificate for your domain that matches the private key. How is that
> not “giving the CDN my private key”?
>
> I don’t believe that restricting a certificate to one day is enough
> of a mitigation to whatever evils the CDN might do that caused us to
> avoid giving them the private key in the first place.
>
> Besides, do 1-day certs really work?  Are the clocks in HTTPS clients
> (not just browsers!) set accurately enough that we won’t get a bunch
> of them screaming that the certificate is not yet valid or already
> expired?
>
> Yoav

Hi Yoav,

I think the precise point is not "without giving my private key" but 
rather "without giving my long-term credentials" or "without allowing 
the CDN to impersonate me forever". So something that can be revoked 
immediately is ideal, and something that expires within a day is IMHO a 
good compromise.

Re: clock skew, I suspect that nowadays a 1- or 2-day cert should work. 
But I don't have any data to support it, maybe the CDN folks do.

To restate the obvious, the job of a CDN in a browser setting is to 
return data to a user with the shortest possible latency. Adding a "key 
server" for the initial handshake can add up to 1000ms to this latency 
(e.g., PoP in Australia, key server in the US). This is not going to 
make CDN customers very happy.

Thanks,
	Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Mar 2016 09:40:15 -0400

On Mon, Mar 21, 2016 at 8:46 AM, Yaron Sheffer <[email-masked]> wrote:
> So far the only use case we have mailing list consensus on is the CDN. If
> you have other, more compelling use cases in mind, I suggest that you
> Personally, I think the CDN use case is justified, and I think it deserves a
> good solution even if that solution is not a key service but something a lot
> simpler.

We have not met for the BOF yet. It is far too early for anyone to
start claiming any sort of consensus.

I don't see likely industry consensus for CDN. I think it much more
likely that the industry would prefer short lived certs. But they
probably won't show up at the BOF because people don't show up at a
meeting just to point out that they aren't interested.

Short lived certs is already a use case in ACME.

I can't see many of my customers wanting to support outsource their
content delivery to a CDN and still be on the hook as a point of
failure. Remember CIA - Confidentiality, Integrity, Availability. For
these people, the absolute top priority is keeping the site online
100% of the time. Integrity is a much lower priority and
confidentiality usually isn't much of a consideration at all.

If people want to do the CDN case, the way I would want to go about it
would involve a LURK Service inside a HSM that is being remotely
administered by the site holder on a daily/hourly basis to keep it
topped up with keys. The Cryptech that Randy Bush and co are working
on for instance.

The single biggest hole in the WebPKI right now is in the code signing
area. The malware that is causing the most problems is the malware
that has been signed with legitimate keys that have been stolen.

I see a compelling use case for remote private keys. Its just a
slightly different one.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 14:15:21 +0000

> I think the precise point is not "without giving my private key" but rather
> "without giving my long-term credentials" or "without allowing the CDN to
> impersonate me forever". So something that can be revoked immediately is
> ideal, and something that expires within a day is IMHO a good compromise.

That's not how I understand the words "limited use of remote keys"

---

From: Yoav Nir <[email-masked]>
Date: Mon, 21 Mar 2016 16:32:24 +0200

> On 21 Mar 2016, at 3:11 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> I think the precise point is not "without giving my private key" but rather "without giving my long-term credentials" or "without allowing the CDN to impersonate me forever". So something that can be revoked immediately is ideal, and something that expires within a day is IMHO a good compromise.

My favorite way to solve this problem is some kind of secure delegation. I would like Cloudflare (just as an example) to not have any keys for www.ietf.org. Instead, “something" would tell me that I can get the content of www.ietf.org in www.ietf.org.cdn.cloudflare-dnssec.net. Then I would resolve this address, get 104.20.0.85, connect there and find a certificate for www.ietf.org.cdn.cloudflare-dnssec.net.

The obvious candidate for “something” is the CNAME record in the DNS. If only DNSSEC was sufficiently universally deployed, but we can think of other mechanisms in the interim.

But this has a very severe drawback. None of today’s browsers know anything about any new secure delegation mechanism. So we’d have to wait until all of them are replaced.

Your short-term certificates are just such a secure delegation mechanism, but they don’t require replacing all the browsers. However, I agree with Rich that this is not limited use, and one day is a long, long time.

Regarding clock skew, I know most modern PCs and phones are sort-of adjusting their clock. But HTTP is not just browsers. There’s lots of stuff getting data off the web, and some time that data is served from a CDN.

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Mon, 21 Mar 2016 07:44:01 -0700

On Mon, Mar 21, 2016 at 7:32 AM, Yoav Nir <[email-masked]> wrote:
<chop>
> Regarding clock skew, I know most modern PCs and phones are sort-of adjusting their clock. But HTTP is not just browsers. There’s lots of stuff getting data off the web, and some time that data is…

Actually a huge number of PCs have inaccurate clocks. There was a
presentation at RWC 16 on what causes certificate errors, and
misadjusted clocks were the leading cause. Sadly that presentation
doesn't appear on the program. So short-term certificates are right
out.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 21 Mar 2016 15:05:04 +0000

> But HTTP is not just browsers. There’s lots of stuff
> getting data off the web, and some time that data is served from a CDN.

For example: game console, webTV's, and printers to name a few.

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 21 Mar 2016 19:32:58 +0200

> Your short-term certificates are just such a secure delegation
> mechanism, but they don’t require replacing all the browsers.
> However, I agree with Rich that this is not limited use, and one day
> is a long, long time.
>

They are "limited use" in the sense that the CDN doesn't get access to 
the same private key I'm using for www.example.com, which just might 
happen to be the same private key I'm using to sign code.

One day is not such a long time when we discuss cross-organization 
breach reaction. The CDN needs to detect that a breach occurred, react 
to it, and share this information with the customer. As far as I know in 
the real world, such disclosure is measured in days, if not more.

Thanks,
	Yaron

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 21 Mar 2016 15:29:58 -0400

On Mon, Mar 21, 2016 at 1:32 PM, Yaron Sheffer <[email-masked]> wrote:
> They are "limited use" in the sense that the CDN doesn't get access to the
> same private key I'm using for www.example.com, which just might happen to
> be the same private key I'm using to sign code.
>
> One day is not such a long time when we discuss cross-organization breach
> reaction. The CDN needs to detect that a breach occurred, react to it, and
> share this information with the customer. As far as I know in the real
> world, such disclosure is measured in days, if not more.

I think we have quite a bit of confusion in that while the initial
proposal for the group was couched in terms of a use case, what was
proposed was actually a solution.

I don't see any problem in working back from a solution to
requirements and use cases. I do it all the time. Whenever I start on
a design, I start off with one motivating use, then think about a
solution and then think about the set of use cases a protocol like
that could support. And then I derive requirements from the larger set
of use cases.

The only point where I throw out use cases is when I consider the cost
of meeting requirements. Even if I only wanted to support the one TLS
use case Rich is considering, my protocol would look identical. I
would still use JSON over HTTP. I would still consider the TLS key
exchange as one particular key restriction.