Re: [Ohai] Regarding PFS

[David Schinazi <[e-mail]>]

That's right, the trick of reusing `enc` works for X25519 but not ML-KEM.
I don't think AuthEncap/AuthDecap change this property, but I'm not
knowledgeable enough about HPKE to be sure.
David

On Tue, Jan 30, 2024 at 5:48 PM Orie Steele <[e-mail]>
wrote:

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