Make Session Initialization implicit from the Directory's Perspective

[DanGould]

On Oct 8, 2024 @nothingmuch suggested a payjoin-directory simplification on the BIP-77 draft:

The sender could first register an additional session subdirectory for the response, and include the associated public key along with the original PSBT when posting to the receiver's subdirectory. The sender would then respond in the sender's subdirectory.

Eliminating the request/response distinction would avoid a metadata leak, namely whether or not the payjoin flow was completed, since requests and responses would be indistinguishable.

A followup suggestion would be removing explicit session initialization. Incidentally in the reference directory it appears that since post_session is stateless, calling it before other operations is indeed not enforced. GET & POST handlers do appear to validate the id path component, but if they did then the first successful request would indicate to either party that the subdirectory ID is valid (or perhaps arbitrary IDs were allowed by design?)

Timing analysis of subdirectory polling could still leak information about which payjoin requests were responded to, but aggressive clients could mitigate this by maintaining a pool of pre-allocated and randomly polled subdirectories ahead of time, and by responding to themselves in some of them with dummy payloads to generate random cover traffic.

I responded shortly thereafter that I agree it's a good idea

@nothingmuch I'll write up your suggestions to simplify the protocol. It makes the directory implementation simpler, requires fewer protocol message types, and even reduces bandwidth. wowza

The sender could first register an additional session subdirectory ... and include the associated public key along with the original PSBT

HPKE E2EE deployed in this application in Authenticated mode (akin to Noise Framework's IK model) already requires the sender to include their session public key as associated data, so this is an pretty darn easy change to make. The change not only simplifies the protocol messaging, but as you say eliminates a metadata leak. I'm a big fan.

A followup suggestion would be removing explicit session initialization

This makes sense too. Creating separate subdirectory resources for either sender or receiver on POST then GETting updates to replace the repeated sender POST polling reduces bandwidth too, since the GET request doesn't contain that repeat POST body.

Even without aggressive client mitigation of the remaining client leaks subject to timing analysis assuming this suggestion is put in place, your new design deletes complexity and improves efficiency.

I'll update the BIP to the best of my understanding based on your comment and link it to a rust-payjoin issue to implement. This spec has already made some breaking changes since the last directory release, so it's a good time for another one since we won't break production implementations other than our own.

Edit: Is there a potential authorization issue now that the sender POSTs first? In the first instance of the directory, only the receiver might need authorization from the directory in order to start a session, and having knowledge of a session public key was sufficient for the sender to use a subdirectory. Now, the sender would also need to obtain authorization somehow, since the directory doesn't yet know about the session the receiver has initiated directly with the sender, out of band with the directory.

We should implement this as part of our v2 breaking changes unless we run into any snag, like what I mention in my edit could be a minor authorization problem