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

[Benjamin Kaduk <[e-mail]>]

On 04/01/2017 07:13 PM, Subodh Iyengar wrote:
> Thanks for your question Brian.
>
> 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