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

From: Subodh Iyengar <[email-masked]>
Date: Sun, 2 Apr 2017 00:13:58 +0000

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 <[email-masked]> on behalf of Brian Sniffen <[email-masked]>
Sent: Thursday, March 30, 2017 2:54:29 PM
To: [email-masked]
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
[email-masked]
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=

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 4 Apr 2017 18:02:35 -0500

On 04/01/2017 07:13 PM, Subodh Iyengar wrote:
> The motivation behind delegated credentials is to create a more
> reasonable deployment model for short lived credentials.

My apologies for being blunt, but that text reads like a solution in
search of a problem.  That is, what is expected to be achieved by having
shorter-lived credentials?  Is there a threat model for which having
them brings security advantages, or are there operational concerns, or ... ?

> [....]

> 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.
>

These are also some useful analysis, but still leaves me wondering what
the actual goal to be achieved is.  Put another way, I assume that there
is some attacker with some capabilities that will be stymied in some way
by the deployment of delegated credentials, as compared to having real
certificates/keys deployed to the machines that are going to get
delegated credentials on them.  But what benefit, and what are the
attacker's capabilities?

There is also an alternate world in which the TLS terminators should not
have certificates/keys on them but it is okay to give them delegated
credentials.  Here, one benefit is clear: performance.  But the attacker
capabilities against which this is supposed to be useful/acceptable
remain unclear.

Can you share some more thoughts about which of these two pictures you
have in mind, and what the attacker capabilities are in that scenario?

Thanks,

Ben

---

From: Simon Friedberger <[email-masked]>
Date: Wed, 5 Apr 2017 14:32:37 +0200

It seems the intention behind short lived certificates is pretty clear:

   Server operators
   often want to create short-lived certificates for servers in low-
   trust zones such as CDNs or remote data centers.

But even if this is true it needs to be analyzed why server operators want
to do this and if their reasons are good ones.

The only example of a security gain I can think of is the following:
If a breach remains undetected but is accidentally fixed for example
through automatic updates. In this case a revocation will not be issued
but short-lived certificates would still invalidate the certificates an
attacker may have stolen.

I suppose, this is similar to the common notion of rotating secrets.

To me the increase in security weighted with the difficulty of obtaining
such short-lived certificates from a CA probably does not justify the extra
complexity of adding subcerts.

Best,
Simon

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 5 Apr 2017 12:35:59 +0000

>    trust zones such as CDNs or remote data centers.

But as currently specified, that low-trust short-lived certificate, if captured, can be used to spoof the operator anywhere else in the world.  Yes, for a shorter time than the long-lived "true" key, but this still seems like a footgun.

---

From: Simon Friedberger <[email-masked]>
Date: Wed, 5 Apr 2017 14:39:17 +0200

I agree, that's why I only see a security gain if the theft of the
certificate remains undetected.

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 5 Apr 2017 16:07:16 +0000

> There is also an alternate world in which the TLS terminators should not have certificates/keys on them but it is okay to give them delegated credentials.  Here, one benefit is clear: performance.  But the attacker capabilities against which this is supposed to be useful/acceptable remain unclear.

@Kaduk, Ben<mailto:[email-masked]> I thought I expressed this in the use cases, but I might not have been concise enough, so I'll try again.

In our original use case when I say less-trusted I mean a CDN running in a different country or a ISPs data center which has a different physical security constraints. The less-trusted and trusted hosts do trust each other, i.e. they could trust each other with the keys however physical security constraints would prevent this.

The threat model here is that since if a less-trusted host having a key is compromised for a certain period of time without detection, and an attacker can steal private keys during that period. In many situations we are fine with giving the TLS terminator a certificate / key, i.e. they actually have a trust relationship, however we want a compromise to only give the attacker a limited power to use the credential. Revocation is arguably effective, so we would not be okay with giving a less trusted host a long term private key. However we'd be okay with giving a less-trusted host a short term key.

> My apologies for being blunt, but that text reads like a solution in search of a problem.  That is, what is expected to be achieved by having shorter-lived credentials?  Is there a threat model for which having them brings security advantages, or are there operational concerns, or ... ?

Hopefully the threat model above should answer this question. I thought I was clear about the use cases. I think just being able to deploy shorter lived credentials to even higher trust areas has an advantage beyond the use cases of less trusted locations in case they are compromised.

>  But as currently specified, that low-trust short-lived certificate, if captured, can be used to spoof the operator anywhere else in the world.  Yes, for a shorter time than the long-lived "true" k…

@Richard Salz<mailto:[email-masked]> There is no footgun that delegated credentials adds beyond what operators can do right now. Operators can go get a short lived CA issued certificate and deploy it, however the latter is much harder to deploy. See the original email for rationale about this.

@Simon Friedberger Do you feel that short lived CA certificates are actually deployable in large server deployments? I do not see that to be the case. I see a security gain here but just being able to deploy short lived credentials to not only less trusted locations, but also to more trusted locations as well which is another use case that I want to use this for.

Subodh

________________________________
From: TLS <[email-masked]> on behalf of Simon Friedberger <[email-masked]>
Sent: Wednesday, April 5, 2017 5:39:17 AM
To: [email-masked]
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=tBKp_cuV26a4AtN1WOEPpqNTgBQUE4Cg9cqS-Fdw5nI&s=2JwQdlzcb8E6z6hDnhnxLFQZOabIRGTGcJmtBCTj46s&e=

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Apr 2017 11:18:51 -0500

On 04/05/2017 11:07 AM, Subodh Iyengar wrote:
>
> > There is also an alternate world in which the TLS terminators should
> not have certificates/keys on them but it is okay to give them
> delegated credentials.  Here, one benefit is clear: performance.  But
> the attacker capabilities against which this is supposed to be
> useful/acceptable remain unclear.
>
> @Kaduk, Ben <mailto:[email-masked]> I thought I expressed this in
> the use cases, but I might not have been concise enough, so I'll try
> again.
>
> In our original use case when I say less-trusted I mean a CDN running
> in a different country or a ISPs data center which has a different
> physical security constraints. The less-trusted and trusted hosts do
> trust each other, i.e. they could trust each other with the keys
> however physical security constraints would prevent this.
>
> The threat model here is that since if a less-trusted host having a
> key is compromised for a certain period of time without detection, and
> an attacker can steal private keys during that period. In many
> situations we are fine with giving the TLS terminator a certificate /
> key, i.e. they actually have a trust relationship, however we want a
> compromise to only give the attacker a limited power to use the
> credential. Revocation is arguably effective, so we would not be okay
> with giving a less trusted host a long term private key. However we'd
> be okay with giving a less-trusted host a short term key. 
>
> search of a problem.  That is, what is expected to be achieved by
> having shorter-lived credentials?  Is there a threat model for which
> having them brings security advantages, or are there operational
> concerns, or ... ?
>
> Hopefully the threat model above should answer this question. I
> thought I was clear about the use cases. I think just being able to
> deploy shorter lived credentials to even higher trust areas has an
> advantage beyond the use cases of less trusted locations in case they
> are compromised.
>

It does, thanks for the clarification -- recovering from undetected
compromise is a worthy goal!

-Ben

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 5 Apr 2017 20:30:31 +0100

I've no strong opinion for or against this. One question below
though.

On 05/04/17 17:07, Subodh Iyengar wrote:
> key is compromised for a certain period of time without detection,
> and an attacker can steal private keys during that period. In many

With that goal in mind, wouldn't it help mitigate the threat if
the holder of the longer term credential (the cert subject) were
to include within the signature e.g. an IP address range within
which the delegated credential is allowed to be used?

Cheers,
S.

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 5 Apr 2017 20:20:03 +0000

We thought about this originally, but we discounted this because it breaks when http and socks proxies are used. Looking at some data I had a non trivial number of requests access our site using proxies. I'm not sure whether there's a good method for a client to enforce ip address ranges when a proxy does the dns resolution.

Subodh

________________________________
From: Stephen Farrell <[email-masked]>
Sent: Wednesday, April 5, 2017 12:30:31 PM
To: Subodh Iyengar; Simon Friedberger; [email-masked]; Richard Salz; Kaduk, Ben
Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts

Cheers,
S.

---

From: Simon Friedberger <[email-masked]>
Date: Wed, 5 Apr 2017 23:52:10 +0200

> be okay with giving a less-trusted host a short term key.
Your argument hinges somewhat on the ineffectiveness of revocation but
I'm not sure how true that it is. Also, if it is shouldn't the fix be
applied there instead?

> @Simon Friedberger Do you feel that short lived CA certificates are
> actually deployable in large server deployments? I do not see that to
> be the case. I see a security gain here but just being able to deploy
> short lived credentials to not only less trusted locations, but also
> to more trusted locations as well which is another use case that I
> want to use this for. 
>
You original mail seemed to imply that is doable but tedious and given
that some CAs seem to offer interfaces that can be automated it should
be possible for many servers but I am in no way an expert on the matter.

Considering however the very specific case that is required for a
security gain (undetected & temporary compromise & revocation
ineffective) it might still not be worth the increased complexity.
Also, take into account that a compromise that leaks certificates will
potentially put an adversary in a position to carry out whatever attack
he wants to perform directly without stealing the certificates.

But I'm not saying there is no security gain, I just wanted to point out
that it seems to me it's not worth any extra complexity.

Best,
Simon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 6 Apr 2017 09:34:35 +0100

On 05/04/17 21:20, Subodh Iyengar wrote:
> the holder of the longer term credential (the cert subject) were to
> include within the signature e.g. an IP address range within which
> the delegated credential is allowed to be used?
> 
> We thought about this originally, but we discounted this because it
> breaks when http and socks proxies are used. Looking at some data I
> had a non trivial number of requests access our site using proxies.
> I'm not sure whether there's a good method for a client to enforce ip
> address ranges when a proxy does the dns resolution.

So if you spec'd this so clients using proxies didn't attempt
to enforce IP checks, but those going direct did, then you'd I
guess better mitigate the stated threat, so long as the set of
clients not using a proxy is non-negligible, which I assume is
the case. Was that considered?

Cheers,
S.

> 
> 
> Subodh
> 
> ________________________________ From: Stephen Farrell
> <[email-masked]> Sent: Wednesday, April 5, 2017 12:30:31
> PM To: Subodh Iyengar; Simon Friedberger; [email-masked]; Richard Salz;
> Kaduk, Ben Subject: Re: [TLS] security considerations for
> draft-rescorla-tls-subcerts
> 
> 
>> The threat model here is that since if a less-trusted host having
>> a key is compromised for a certain period of time without
>> detection, and an attacker can steal private keys during that
>> period. In many situations we are fine with giving the TLS
>> terminator a certificate / key, i.e. they actually have a trust
>> relationship, however we want a compromise to only give the
>> attacker a limited power to use the credential. Revocation is
>> arguably effective, so we would not be okay with giving a less
>> trusted host a long term private key. However we'd be okay with
>> giving a less-trusted host a short term key.
> 
> With that goal in mind, wouldn't it help mitigate the threat if the
> holder of the longer term credential (the cert subject) were to
> include within the signature e.g. an IP address range within which
> the delegated credential is allowed to be used?
> 
> Cheers, S.
> 
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 6 Apr 2017 09:33:43 -0700

> the case. Was that considered?

Too much room for error. Consider all the varieties of network devices
that could cause an IP-address mismatch, many of which the client
wouldn't see.

> https://www.ietf.org/mailman/listinfo/tls
>

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