Key exchange between client and follower trust domains

[willscott]

There's some care here around the encryption process for messages between the the client and the follower trust-domains that go beyond link-layer security.

We've talked about a symmetric random overlay xor'ed on responses that the client can then xor out on its side. figuring out what that is on the way out, and figuring out the process for passing requests onwards to those follower trust domains is something we should write a formal description for.

[willscott]

It sounds like the basic structure to follow will be:

• [ ] Trust domains have an associated Public Key that is distributed as part of the trustdomain_config
• [ ] ReadArgs is not actually just an array of PirArgs, but rather those PirArgs encrypted with associated public keys
• [ ] The PadSeed, passed encrypted to the server, is used to generate the overlay, which the client subtracts off.

One worry is that if requests are directly encrypted to the server's public key, subsequent loss of that key will lose forward secrecy. At a minimum, once initial functionality is achieved, we should then work towards time-based derived server keys announced and rotated on a regular basis.

[ryscheng]

Seems reasonable.

Maybe we can reuse some pre-existing library for ratcheting keys.

[willscott]

This is addressed now. Ratcheting keys remains an issue, but is a different one from this.