Re: [Ohai] Regarding PFS

[David Schinazi <[e-mail]>]

Thanks Martin, I agree with all the facts you wrote, but differ in the
conclusions.

If we focus on X25519, the request size is the same, the response size is
increased by 16 bytes, and the added CPU cost is not huge. While PFS
applies to both chunked and regular OHTTP, the fact that chunked enables
large responses significantly changes the tradeoffs, because in that
scenario the additional 16 bytes in the response and HPKE CPU costs are not
going to be noticeable compared to the cost of AEAD'ing the entire response.

If tomorrow a quantum computer breaks X25519 and we need to switch to
ML-KEM, the overheads will be more noticeable but I honestly don't think
they're going to be high on our list of things to fix compared to
everything else.

I'm also not too worried about negotiation: if we reuse the client's `enc`
value, the client's flight is exactly the same with and without PFS.
Additionally, the client can indicate support via an HTTP header inside the
encryption.

So, from my perspective, the costs are low, and the benefits are medium.
But that's because my intuition is that we might see more use-cases that
use OHTTP with blinded tokens in the future, but that's not a guarantee.

If the WG prefers to avoid this complexity, we'll instead have to add some
text stating that chunked OHTTP really shouldn't be used in cases where the
response is more privacy-sensitive than the request. That's not my favorite
path forward, but it's a reasonable one.

David

On Mon, Jan 29, 2024 at 7:28 PM Martin Thomson <[e-mail]> wrote:

> 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.
>