On 3/4/21 1:56 PM, Michael Thomas wrote:
It's silly to dismiss those as if they didn't exist or weren't important. They're quite often parts of critical infrastructure.
Online != Internet connected. If you're using TLS you are online definitionally. You may be on a stub air-gapped network but you're still using internet protocols to communicate. That stub network can have all it needs to support its infrastructure. It's just as online as anything else.Usually, "all it needs to support its infrastructure" is an Ethernet switch or WiFi access point. DNS is often considered an operational hazard in such environments, sometimes DHCP is also, as is firmware update.
X.509 comes from a time where you couldn't even make that assumption. Applications that require that assumption are pretty far and few between these days.
I don't think it makes sense to waste otherwise good protocol engineering just because it doesn't fit someone's idea of "how the network works". TLS can be profiled to work well in such environments (without change to the TLS stack), and so can X.509. Why re-invent the wheels?
My point here isn't to defend how TLS works, it's to say that almost nothing requires the truly offline verification aspect that x.509 brings to the table. I can (and have) built a asymmetric key login mechanism that just puts naked public keys into a user table of a database, for example. The x.509-first view of the asymmetric keys world has confused a lot of thinking and had I introduced it to that mechanism it would have worlds more complex and much harder to understand. Designers should, dare I say it, be looking at the actual requirements of the system before settling on a particular solution.
Mike
