[pastage]

My bank used client TLS certificates early on, while it is nifty it was a really bad idea without hardware security. (Paper OTP in their case)

IMHO, client side certificates are a big failure even on server to server. The UX of doing it is error prone and insecure because of foot guns. It fails because there are so many different incompatible ways to use them. Mostly this idea of mine is based on never having had a good experience with browser based client certificates (even highly automated and hardware secured ones). Things does not get much better on server.

Sure automation helps but the certificate is a such a small part of the system, and when you try to integrate two automated systems that use client side TLS certificates it is easy to trust too much or too little. (Both are troublesome)

[u801e]

> The UX of doing it is error prone and insecure because of foot guns.

Many people over the years have mentioned UX issues as a reason why client side TLS certificates aren't more widely used. The question is why hasn't there been an effort to improve the UX rather than re-inventing the wheel (either poorly with SMS/email 2FA or OTP, or in a way that's limited to a specific application level protocol like HTTP for webauthn).

What I would like to see is a standard workflow where as part of an account creation process, an associated CSR is sent and a client side TLS cert is returned and stored on the device along with a standard way to add additional devices using an existing device and the new device that doesn't depend on a specific application level protocol (so, for example, I can use my email client via SMTP and IMAP to securely authenticate without having to rely on a HTTP intermediary).

Or, for more secure settings, actually having to verify your identity out of band (e.g., going to the bank and showing multiple forms of ID along with your CSR to get the certificate.

[acdha]

The problem is basically that it wasn’t a priority for application developers but you need to upgrade things everywhere before you can switch to a new protocol. Those clunky MFA options give CIOs the appealing promise that a bit of duct tape means they get some protection without needing to e.g. replace that old RADIUS server most people depend on to do their jobs.

It might be interesting to look at WebAuthn passkeys, as they do most of what you want. That took several important developments: the web ate desktop apps, Microsoft lost control of the web, and Google has some strong security people in their management. That does the public key exchange, has robust cross-device support which doesn’t require an internet connection, etc. and it has some features to improve the identity situation (e.g. it includes a device key & authentication info so my bank can say it only accepts transfer requests which came from a known device doing a biometric check, which is a nice edge over x509/SSH-style trust based solely on access to the private key).

This unfortunately does not work using other protocols but a not-uncommon flow would be using a browser session to issue your IMAP client a token. That’s not great (a compromise gives the attacker your email) but it can be less disastrous if the most important actions can’t be initiated purely from email.

[pabs3]

Apple/etc Passkeys (WebAuthn in software instead of hardware tokens) seems similar to TLS client certs, so I'm sure the UX stuff with certs is solvable if anyone cared.

[u801e]

They are, but they require one to use the HTTP application level protocol. I would like to be able to do the same with SMTP and IMAP in my email client without having to make HTTP requests.