Re: [Ohai] Regarding PFS

[Orie Steele <[e-mail]>]

Unless I am missing something, you won't be able to switch to any kem that
does not output a public key as it's encapsulated key value.

So you won't be able to migrate to ML-KEM, without changing the protocol.

Doesn't look like HPKE auth encap / decap are currently supported, would
they help?

OS



On Tue, Jan 30, 2024, 7:20 PM David Schinazi <[e-mail]>
wrote:

> 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.
>>
> --
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai
>