There's a few problems with it.

1. client auth in TLS1.2 and earlier is done at the wrong time in the handshake. As a result the client's identity (which unlike the server identity usually identifies a user; see sibling comment which confirms this) is sent in the clear. That's a big privacy failure.

2. to work around (1), some implementations do an initial server-auth handshake, then immediately renegotiate up to mutual-auth (renegotiations are encrypted). Renegotiation has quite a dismal history, and I definitely want to avoid it.

3. as a follow on from (2), the standard never described what implementations are expected to do if client/server identities change during renegotiation. This (partially) resulted in https://mitls.org/pages/attacks/3SHAKE

All of these are fixed in TLS1.3: client identities are encrypted and renegotiation is dropped.

Yeah, trying to make TLS client identity private is a recipe for sadness (well, before 1.3).

At least in the environments I use TLS, which is interservice datacenter communications, there are no privacy issues (especially since you can just look at what container a connection comes from for the same amount of identity leaking).

Thank you, this is a very good explanation and now I'm convinced that this is the right thing to do.

But I do need mutual authentication, and want to avoid rolling my own crypto for it--so does Rustls expect to support client auth in TLS 1.3 when that spec is finalized and implemented?

Super nitpicky, but would it make sense in the README then to specify "client authentication per TLS 1.2 or earlier", as the non-feature, or something like that?

> I'd love to see an explanation for not supporting client authentication.

My guess? They don't use it in their applications, so they don't think anyone else uses it, either.

TLS client authentication is widely used in 802.1X (WiFi and wired) authentication. I've seen it used in a lot of other situations, e.g. web client access (client cert + user password), LDAP client access, etc.

Maybe there are security issues in client authentication which they're aware of. If so, they should share them. But simply labeling client authentication as "obsolete" shows a close-minded attitude.

Where I work client auth is used for a good (and growing) number of internal services.

Client auth is simple to use - our internal services are given the username from the CN, which they use to perform authorization checks. For a lot of simple internal services that don't require two-factor auth it works great.

Am I missing something better?

(We already have the infrastructure in place to deal with client keys)

I've never even heard of client authentication until recently. That's probably why.

If you've ever used OpenVPN, you've used TLS client authentication. That seems like a pretty huge hole to purposely put in your feature set. I understand not implementing it yet because it's more work, but I don't get drawing a line in the sand.

Obscure is not on the list in GP's quote, and afaik client authentication is none of the things in that list. It's actually used a fair bit in uses of TLS that are not the open web.

Coming from a US DoD background, TLS client authentication is mandated for nearly everything. Everyone carries keypairs around their neck on their ID card (PIV smartcard with x.509 certificates)

Yes. I've implemented client-auth with a private CA, specifically to authenticate services to each other.

It's a very handy tool when you have disparate networks.

It seems especially wrongheaded as client certificates are used in certain academic environments.