Re: [TLS] security considerations for draft-rescorla-tls-subcerts

[Subodh Iyengar <[e-mail]>]

Thanks for your question Brian.

The motivation behind delegated credentials is to create a more reasonable deployment model for short lived credentials.

Even without delegated credentials service owners can request short lived certificates from their certificate authorities and deploy them to their remote servers. Having experience running some reasonably large services and also speaking to others who run big services, this presents several challenges:

* Keeping the site up would now involve contacting the CA more frequently than before (assuming you're not using OCSP stapling). Even though CAs have good infrastructure, the processes for automatic renewal introduces the risk of greater errors. Since these errors are across multiple parties these would be very hard to diagnose, so people would tend to not have a hard dependency on this system. It is much easier to debug and recover from failures if a service owner could control the issuance of short lived material with the CA's permission.
* Short lived certificates would go into CT logs, and there were several concerns raised about the increase in the size of the CT logs.
* A reasonable deployment model would call for private keys to never traverse the network. Not everyone should be allowed to contact the CA directly to renew the certificate automatically, so deploying short lived certificates would mean that you would have to proxy CSRs from the end hosts via some trusted infrastructure. This adds some additional moving parts.

This led us to think of whether we could deploy short lived credentials with another approach. Once you can deploy short lived credentials we found several use cases for these:

* Removing private keys from currently trusted hosts and keeping them in even more secure locations. In this way you could increase security by moving keys from places they currently exist.
* You could make a security / performance by giving delegated credentials to your less trusted locations where you could make the tradeoff that if one of these is stolen it's valid only for a very short period of time.

I'm not too familiar with the cloud provider to service owner trust model, but your idea of giving the cloud provider a delegated credential instead of a longer lived certificate key sounds great.

Delegated credentials bounds time, however if used with other mechanisms you can make security protections even more robust. For example you could give your cloud provider a delegated credential bound to a certificate with a different origin. If you find that something bad has happened you can stop routing traffic to that origin as well.

Hopefully this clears things up.

Subodh
________________________________
From: TLS <[e-mail]> on behalf of Brian Sniffen <[e-mail]>
Sent: Thursday, March 30, 2017 2:54:29 PM
To: [e-mail]
Subject: [TLS] security considerations for draft-rescorla-tls-subcerts

I'm trying to understand the adversary model in which Delegated
Credentials are helpful.  It seems like if you weren't going to sign off
on a cloud service provider getting a certificate before, you *probably*
shouldn't let them have a delegated credential now---but if you were
going to do so, *and* you don't believe revocation works (wise!), now
you can offer a delegated credential and be safer?

That corresponds to an adversary who can compromise a cloud service and
learn the customers' private keys---but can only do so rarely.  Now
instead of having ~ 1 year of use of your certificate, that adversary
has a few days of use of your credential.  But if the cloud service
is regularly breached, you're as bad off as before (but no worse?)

It sounds like the first years of delegated credentials will see them
used in tandem with split systems (Lurk, Akamai and Cloudflare's various patented
approaches)---then the primary benefit of delegated credentials is lower
latency for session establishment.

But maybe the idea is to avoid the first circumstance and emphasize that
these are for the second case.  Authors, can you describe what you have
in mind?

Thanks,
Brian

--
Brian Sniffen
Akamai Technologies

_______________________________________________
TLS mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=q03hxbJ9kVRM2fXxXl_8ByxjamwOvDX09DvM_ASPC_o&s=04enApSPuKlAuxTNPBOwVcenAvEku4aZrZ1LgyPQqRk&e=