| > An example would be if you don't have a certificate. Given that letsencrypt exists, I don't see why you wouldn't have a cert. > Maybe you just have a pre-shared secret or a kerberos ticket. The pre-shared secret could be a cert which would work with TLS. > Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session. I can't think of a realistic example of such a protocol. What protocol uses PAKE, but doesn't support encryption, but will verify a session id? It seems like using TLS would be simpler. > Or maybe you are using an RPC protocol, like NFS, that doesn't let you add TLS in a backwards-compatible way, but where the client and server do share some secret file handle. Such a scenario still requires modifications to the NFS server and client software, which, if done, isn't clear why it would be better than just layering TLS onto the protocol. |
That makes an enormous number of assumptions-- that you have a domain name, that you accept inbound connections, and that "gee some server connected to my name and got me once" is a remotely acceptable criteria for identity in your application.