[Cryptography] Preventing correlation on rebinding connection identifiers.

[John-Mark Gurney]

Phillip Hallam-Baker wrote this message on Thu, Feb 11, 2021 at 16:04 -0500:
> So, a little curlicue just popped up.
> 
> One of the problems I am going to need to solve at some point is to rebind
> a connection after the source IP address/port change. This can be caused by
> a NAT reconfiguration, a DHCP event or the user simply changes from one
> network to another.
> 
> The idea here is that Alice is going to establish a connection between her
> device and her Mesh Service Provider Hosts that is persistent and survives
> changes to the configuration on either end. We can assume the Host end will
> be on a static IP address and port[1]. But the client end is going to vary
> a great deal.
> 
> So in the ordinary state of affairs, the host recognizes packets from Alice
> by their source address+port and this is used to obtain the shared secret
> used to decrypt the remainder of the message.
> 
> If the client source address+port change, the host is going to respond with
> a packet saying 'unrecognized connection' and bounce the source address and
> port back to the client. The client then realizes that its outbound
> connection config has changed and we need to rebind.
> 
> One option would be a packet 'claiming' the prior source address+ip but
> that seems ugly. I would like to have as little connecting one packet to
> another as possible enclair.

I have thought about this, and the solution that I came up with was that
each "connection" would be established using normal PFS methods.  When a
connection to a server needs to migrate, the client setups a "new"
connection, but then sends a message saying, hey, server, I'm
reconnecting on behalf of the previous session, here's the session id,
and here's cryptographic proof using the old key.  That proof could just
be an AES-GCM block of the new session id encrypted under the old session
key.  Then the server reassociates to the new connection and things move
on..

The advantage of this is from the outside, it's not clear that the new
session is resuming the old one, or entirely a new session.

This also means that a session can rotate keys (not that it's
recommended much anymore) using the same protocol.  This may be needed
if it's a long lived VPN tunnel...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."