[Ohai] Regarding PFS

[Martin Thomson <[e-mail]>]

On Tue, Jan 30, 2024, at 13:58, Jana Iyengar wrote:
> (Adding PFS to OHTTP is a great idea that we should pursue, 
> but it increases this overlap.)

I'm picking on Jana here as a starting point of a conversation, but this is really about David's idea.

David's suggestion was to have both request and response use HPKE.  The client would send a request toward a static server key; the server would send a response toward an ephemeral client key.

The advantage of this is that responses depend on purely ephemeral keys.  Only the client and server have the ability to decrypt them and only for as long as they retain those keys.  This would be an improvement in some situations and I'd be supportive of exploring those situations.

There are, however, costs that need to be considered.

1. Additional request size.  To do this properly, the client would need to generate a fresh ephemeral key and send a public key with its request.  For something like X25519, that's 32 extra bytes; ML-KEM or hybrid KEMs are quite a lot larger.

David originally suggested using the client's `enc` value for this, which would save this cost.  That would be possible with the X25519-based KEM that is in common usage and with other DH-based KEMs.  However, that would remove some generality as other KEMs don't work like that (ML-KEM is one).

2. Additional response size.  The 16 byte nonce could go and be replaced with a freshly encapsulated secret.  This would be anywhere from 32 bytes (X25519) to well over a kilobyte (ML-KEM).

3. Additional compute cost.  The cost of generating separate key pairs and then using them is modest, but significant relative to the existing costs as it essentially doubles the largest CPU cost component of the scheme.

4. Negotiating use.  This is the one that might be the hardest.  An in-place upgrade is not easy.  It comes down to all of the same questions that Tommy went through at the last meeting around format negotiation.  You can make it optional through in-band negotiation or having it be part of a selected key configuration, but that could divide anonymity sets in two.  You can make it non-optional, but that risks excluding some peers who don't support the format.  Had this been part of the original design, it might have been easier to justify, but it gets a bit harder when there are deployment considerations in play.

Then there is the benefits.  A lot of the uses for OHTTP I have seen depend on request privacy more than response privacy.  Often, this is because the client is the one with something to say that might have privacy implications.  The response might carry information that ties back to the request, but the request contains the really dangerous stuff that we're trying to protect.  Better protection for responses is not nothing, but nor does it necessarily improve the situation much.

OHTTP clients are often anonymous.  A server will generally send the same response to a different client that makes the same request.  A compromise of the static server key will let an attacker decrypt requests.  In that case, an attacker can decrypt the request and make that same request to get the same answer. For those arrangements, response protection has negligible added value.

This changes with the inclusion of anonymous tokens, provided that you use anti-replay.  So it is not nothing, but it is still worth keeping in mind the limited applicability (and this is the limited applicability working group, after all).

The other fact to consider is that encrypted messages are only available to three entities: client, relay, and server, with only the relay not being able to read the content.  You might not trust a relay with the content, but you do trust it to protect privacy and to help shield the server from abusive clients.  That leaves a gap where you might want to strengthen confidentiality protections against the relay, but it is a small one.  I don't know how to balance that gain against the drawbacks.