If I understand it correctly, there would be zero change for the user. Right now, a server has a single host key. This is generated once and will remain static

If I understand it correctly, there would be zero change for the user. Right now, a server has a single host key. This is generated once and will remain static for the server's entire lifetime. The client has the public part of that in their authorized_keys. When a session is created, the server uses the private part to sign some stuff, and the client validates it using the already-known public key. In other words, we have the host key K, client stores K_public in known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature) to client. Client does `K_public.validate(session_signature, data)` and continues if it all matches. This usually works just fine, but you can only have a single key for a server - which is a bit of an issue if that "server" is actually an entire cluster consisting of thousands of machines. Every singly machine needs to have a copy of the single private key. as delegating this to a secure enclave is unfeasible if you get hundreds of thousands of connections per second. Not to mention that key rotation is a bit of a nightmare. With this proposal, we add a parent key, let's call it L. L_private is stored in some kind of very secure hardware enclave. Every hour/day/whatever, the server generates a new host key K, and asks the enclave to sign the new public key. The server now has K_private, and `host_signature = L_private.sign(K_public)` as generated by the enclave. The client stores L_public in their known_hosts. On session creation, server does `session_signature = K_private.sign(data)` and sends (data, session_signature, K_public, host_signature) to the client. The client finally does `L_public.validate(host_signature, K_public) && K_public.validate(session_signature, data)`. All of this happens on the server side, and the only thing needed is a relatively minor protocol upgrade. The interesting part is that a very similar mechanism already exists for the client's key, making it way easier to manage hundreds of keys across thousands of servers without going crazy by having to update authorized_keys among the entire server fleet multiple times per week.