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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
