4 ms·

It's not intended to be sleight of hand. Confidentiality is the gateway drug. The argument is that, once you're using TLS for that, the incremental cost of addi

It's not intended to be sleight of hand. Confidentiality is the gateway drug. The argument is that, once you're using TLS for that, the incremental cost of adding client certificates and doing mTLS to reduce blast radius is lower. It's not zero. It is lower. I'm also not arguing that some active mechanism to immediately remove attacker access is unimportant. Of course it is. I'm arguing that active certificate revocation is not the only way to achieve that. I gave two examples: remove access at the perimeter or push new policy to revoke access for the compromised entity. Most microservice systems already have tools here: they're typically adding mTLS on top of a perimeter model with decent privileged access management. This is a bit of an asymmetric argument, in any case. I have all of my cards on the table. The opposition isn't really proposing any concrete alternative, so it's hard to make a meaningful comparison. If you want active revocation, implement active revocation. It's not easy, but OCSP and CRL exist and they do work. I even suggested a way to do it well: push a CRL to a cloud bucket, which is scalable and highly available. You can call that "cargo culting all of the idiosyncracies of the WebPKI", but I still haven't heard a concrete alternative. So where does that leave us? The only concrete thing that's been proposed... that I had to propose myself, since no one else would even answer this very simple question, is macaroons. Which I've said repeatedly I think are a good idea. However, it's abundantly clear to me why people, in practice, are choosing client certs over macaroons. Macaroons can't layer into an existing system the way that mTLS can, and if all you want is "blast containment" you can get that with a fairly simple client certificate setup and a bit of coarse authorization. Regarding CA availability: if you can't remediate an availability issue with a shared-nothing web service in 8 hours (the downtime you'd need for a cert to expire in a default step-ca setup) then you've got bigger problems than certificate management. The 24 hour default is long enough for people to remediate an outage and short enough to get people operationally comfortable with the idea of short-lived certificates. If I were to use shared secrets instead of asymmetric keys, and I created a system that rotated all of my service-to-service shared secrets automatically every 24 hours would you say that's a bad idea?

tptacek 6y ago
First, if you are in a place where the only two alternatives are (1) pervasive identity-bound mTLS or (2) Macaroons, you are wildly out of step with how security is managed in this industry. Most orgs, including some with very well-resourced security teams, don't do pervasive mTLS of any sort. And nobody uses Macaroons. Secondly: I'm also not arguing that some active mechanism to immediately remove attacker access is unimportant. Of course it is. I'm arguing that active certificate revocation is not the only way to achieve that. An "active mechanism to remove attacker access" is revocation. That's literally what the word means.
- mmalone 6y ago
  You’re putting words in my mouth again. I didn’t say those were the only two options. I asked what your silver-bullet alternative to mTLS is that has no issues of its own. The position seems to be that mTLS has problems, so don’t use it. But everything has problems. Re: revocation... the point is that you can revoke attacker access without revoking a certificate. Or, if you want, you can revoke certificates. I’m not totally opposed to that. CRL is finicky, but architecturally it works well with short-lived certs and it’s not very different than secret rotation. If you can push new secrets, you can push a CRL. In fact, if you can push new secrets, you can also push new roots. There are many people who use mTLS. Along with consistent service logging, it’s one of the main reasons people use service meshes. It’s also very common in IoT.
  - tptacek 6y ago
    If you can revoke attacker access without revoking the certificate, the certificate isn't doing all the authentication stuff you say it is. If you have to inform all the services in your network that a certificate (or an identity bound exclusively to a certificate) is invalid, you've implemented revocation. You can see how this looks like jazz-hands, right?
    - mmalone 6y ago
      The certificate is still containing blast radius when the attacker is in your network and limiting the insider threat from people who have access to some subset of production. Without a cert, they’d be able to access everything. With a cert, they can only access stuff that the identity bound to the certificate can access. It’s doing precisely what I want it to do. If you find someone malicious in your network, you lock them out of your network. You don’t need to revoke a certificate to do this. OR, you can do CRL. This isn’t jazz hands, it’s a choice. As you push mTLS harder, and need things like active revocation to satisfy your threat model, it’s worth reconsidering whether mTLS is the right choice. Sometimes it is, sometimes it’s not. Sometimes you don’t have a feasible alternative.
      - 6y ago

tptacek 6y ago

First, if you are in a place where the only two alternatives are (1) pervasive identity-bound mTLS or (2) Macaroons, you are wildly out of step with how security is managed in this industry. Most orgs, including some with very well-resourced security teams, don't do pervasive mTLS of any sort. And nobody uses Macaroons. Secondly: I'm also not arguing that some active mechanism to immediately remove attacker access is unimportant. Of course it is. I'm arguing that active certificate revocation is not the only way to achieve that. An "active mechanism to remove attacker access" is revocation. That's literally what the word means.

mmalone 6y ago
You’re putting words in my mouth again. I didn’t say those were the only two options. I asked what your silver-bullet alternative to mTLS is that has no issues of its own. The position seems to be that mTLS has problems, so don’t use it. But everything has problems. Re: revocation... the point is that you can revoke attacker access without revoking a certificate. Or, if you want, you can revoke certificates. I’m not totally opposed to that. CRL is finicky, but architecturally it works well with short-lived certs and it’s not very different than secret rotation. If you can push new secrets, you can push a CRL. In fact, if you can push new secrets, you can also push new roots. There are many people who use mTLS. Along with consistent service logging, it’s one of the main reasons people use service meshes. It’s also very common in IoT.
- tptacek 6y ago
  If you can revoke attacker access without revoking the certificate, the certificate isn't doing all the authentication stuff you say it is. If you have to inform all the services in your network that a certificate (or an identity bound exclusively to a certificate) is invalid, you've implemented revocation. You can see how this looks like jazz-hands, right?
  - mmalone 6y ago
    The certificate is still containing blast radius when the attacker is in your network and limiting the insider threat from people who have access to some subset of production. Without a cert, they’d be able to access everything. With a cert, they can only access stuff that the identity bound to the certificate can access. It’s doing precisely what I want it to do. If you find someone malicious in your network, you lock them out of your network. You don’t need to revoke a certificate to do this. OR, you can do CRL. This isn’t jazz hands, it’s a choice. As you push mTLS harder, and need things like active revocation to satisfy your threat model, it’s worth reconsidering whether mTLS is the right choice. Sometimes it is, sometimes it’s not. Sometimes you don’t have a feasible alternative.
    - 6y ago