[mazieres]

> I'd love for you to expand more on this. What I can't think of is a realistic scenario where it's possible to validate the session id in a secure way, but there is also some reason that we couldn't just use TLS with client certificates.

An example would be if you don't have a certificate. Maybe you just have a pre-shared secret or a kerberos ticket. Or worse, maybe you just have a password, and so need to use a PAKE protocol or something to authenticate the session. 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.

[dagenix]

> 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.

[nullc]

> Given that letsencrypt exists, I don't see why you wouldn't have a cert.

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.