I'd love to see an explanation for not supporting client authentication. Also, completely ruling out discrete-log DH and requiring PFS is not feasible unless you want to rule out a lot of clients and servers, on top of not supporting TLS 1.1.
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.
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).
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?
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.
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)
It's a very handy tool when you have disparate networks.