There's nothing wrong with client certs (other than insane complexity). However ultimately s2n is likely to need to support operation as a client too at which point things like certificate validation etc. will be needed and the amount of code will increase.

Insane complexity is exactly why supporting client certs is a bad idea.

Certainly true if you don't need them. However since code using the library as a TLS client is already partially present, support for certificate verification is definitely going to need to be added.

At the moment, I'm not that impressed with the testing since even making it build actually requires patching it! This is just due to one of the examples, but from the git history it's been broken since January.

No, sorry. The insane complexity is on the requirements. If you need client certs, anything you do to satisfy the need will be at least as complex.

Yes, but 99.999% of web servers don't need client certs.

Of course. But they'll end up implementing it anyway, because of the 00.001%.

Source?

Other than the government, nobody trying to do client certs actually runs the CA that issues them that I've seen. Instead, they trust some random set of commercial CAs, ignorant of the fact that openssl s_client -connect will dump out that list to any passer-by. I've even seen them trusting the "domain control validated only" certs, without any indication of "maybe this is a bad idea, because anyone who can buy a cert can auth to us because we don't even check."

So for every case I've seen, they'd have been ahead to issue credentials themselves and just skip client certs.

99.999% of web servers.

Thank you for the vote of confidence, but you're wrong. The question of "real world usage of TLS" is one where I would immediately defer to tptacek without question... and you've been around long enough to know that's something I don't do very often.

Eh, just dumping X509 for something easier-to-parse would cut out a huge chunk of code. Being compatible is hard, but we stick with what we have because of switching cost, not because it's the best we can do.

Practical use of client certs usually implies support for renegotiation too.

Just because you haven't come across client cert validation requirement, it doesn't mean it's wrong.

If you have a bunch of micro services that need to communicate with each other securely, client cert validation solves a big problem.

If you have a bunch of small services which need to communicate securely, you should be using something like spiped, not TLS.

TLS is the right solution iff you need to communicate with third parties whom you can't securely share code or keys with in advance.

don't throw solutions with confidence like they are silver bullets. spiped is unmaintained, doesn't support revocation, not easy to debug in a big infrastructure, and will require a lot more work compared to https + client cert authentication, and doesn't provide multi platform support.

PKI is used to build a chain of trust. Whether it involves third parties or not is not the point.

you're replying to the author, and maintainer, of spiped.