> 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 protected]> 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" key, but this still seems like > a footgun. @Richard Salz<mailto:[email protected]> 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. > 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. @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 protected]> on behalf of Simon Friedberger <[email protected]> Sent: Wednesday, April 5, 2017 5:39:17 AM To: [email protected] Subject: Re: [TLS] security considerations for draft-rescorla-tls-subcerts I agree, that's why I only see a security gain if the theft of the certificate remains undetected. On 05/04/17 14:35, Salz, Rich wrote: >> Server operators >> often want to create short-lived certificates for servers in low- >> 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. > _______________________________________________ TLS mailing list [email protected] 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=
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
