2 ms·

There is some security concerns with exporting the ephemeral private key material over a network connection. Technically there is nothing that makes this impos

There is some security concerns with exporting the ephemeral private key material over a network connection. Technically there is nothing that makes this impossible, but from a policy perspective it may be a nonstarter.

toast0 5y ago
If you're OK with transferring tcp state, I don't see why you wouldn't be ok with transferring TLS state, too. You don't even need to transfer the certificate private key. I've seen some systems where the certificate private key isn't present on most edge nodes; session signing is proxied to centralized nodes and the edge nodes just do the bulk ciphered with the session keys, which necessitates sharing the session keys over a network.
remram 5y ago
That's why I was thinking more about a key renegotiation, which I know exists in SSH and existed in TLS at one point (at least I know there's a shortcut for it in openssl's s_client).
- touisteur 5y ago
  One of the ideas of tcp checkpoint restore, at least for me, is to avoid a round-trip delay when restoring the connection. Wouldn't a key renegotiation cause at least one round-trip? I'm probably being dense here...
  - remram 5y ago
    It probably would yes, though that might still be fewer round-trips than establishing a new TLS connection.
    - touisteur 5y ago
      Youre right. I'd actually be really interested in a write-up on such ideas. SSH, TLS or wireguard (voluntary) 'takeover' or Checkpoint&Restore. I don't remember whether QUIC had multihoming (might help with checkpoint restore) but since most APIs are in userland and it's udp it might be faaar easier.