Re: [Ohai] The OHAI WG has placed draft-ohai-chunked-ohttp in state "Call For Adoption By WG Issued"

[David Schinazi <[e-mail]>]

Thank all, that was definitely the bit of context that I was missing. I do
find the "99% short responses, 1% long responses" use case to be quite
compelling. Based on that, and on the linkability of TLS 0-RTT, it makes
sense to build a solution at the OHTTP layer. I'd suggest getting rid of
the ability to chunk requests but I now see the value of chunked responses.

The sticking point for me remains the lack of perfect forward secrecy for
large responses though. If we want the request to be unlinkable, sent in
the first flight, and processed immediately, then there's no way around
losing replay-protection and PFS for the request. That's fine. The
response, however, doesn't have to be this way. You could toss in an extra
HPKE operation to make that happen:
// same as regular OHTTP
* server starts with skR, pkR static keys - client knows pkR
* client starts by generating skE, pkE ephemeral keys
* clients does sender part of HPKE with (skE, pkR), sends enc_request
* server does receiver part of HPKE with (skR, pkE), generates a fresh
response_nonce, computes aead_key, aead_nonce
// new - instead of sending the response encrypted using aead_key,
aead_nonce, the server does its own HPKE in the other direction with fresh
ephemeral keys
* server generates skE2, pkE2 ephemeral keys
* server sends pkE2 but AEAD-sealed with aead_key, aead_nonce
* server does sender part of HPKE with (skE2, pkE), can now send encrypted
chunked response with new set of keys
* client does receiver part of HPKE with (skE, pkE2), can decrypt response

This has the same latency properties of the draft as currently written
(i.e., no additional round trips needed) but provides PFS for the response.
It involves a bit more CPU for crypto operations, but those are negligible
if this is only used for chunked (i.e., large) responses.

I'm sure this idea has flaws that'd need to be ironed out, and I'm sure the
adoption call is not the right place to do that, but I do think that we
should discuss whether this new protocol needs PFS or not during adoption.
If we were to say that this document is being adopted contingent on
addition of PFS to the response, then I would support adoption.

David

On Thu, Jan 25, 2024 at 3:50 PM Tommy Pauly <[e-mail]> wrote:

> Hi David,
>
> A few salient points I want to highlight from the meeting that will help
> with context (sorry they’re not in the document yet, that’s what needs to
> be done):
>
> - As Eric Rosenberg brought up, one of the main benefits here is when a
> client is making requests and 90% of them will be short/fast responses, but
> there’s another 10% that may be slower to generate, it makes far more sense
> for clients to request with OHTTP as opposed to making unique TLS
> connections for each request that *might* be slow.
>
> - As Jana brought up, the role of a relay to do OHTTP (essentially a
> specific kind of reverse proxy) compared to a TLS forwarding / MASQUE
> proxying is quite different. A MASQUE-style proxy with per-request
> decoupling needs establish new connections to the next hop for every
> request, dealing with port allocation, IPs, etc. For OHTTP, it’s just a
> normal reverse proxy model. This is one reason the proposal of doing short
> TLS connections for every single request doesn’t really scale in practice.
>
> - While it’s totally true that OHTTP doesn’t come with PFS, it also has
> many privacy advantages: not exposing the latency to the client, and being
> able to support 0-RTT data without incurring correlation. The sketch you
> include below would currently involve having likability between these 0-RTT
> requests and also would end up exposing latency to the client as the client
> finished the full handshake.
>
> As I said in the meeting, I think we do need to make sure we are not
> reinventing TLS at a different layer, but there are solutions that fit
> squarely in the OHTTP privacy model that are best solved by letting an
> OHTTP message come in multiple pieces. I’m certainly not advocating that
> “everything should be built on chunked OHTTP”, but rather that there is a
> (limited) place for it in the overall solution ecosystem.
>
> Thanks,
> Tommy
>
> On Jan 24, 2024, at 6:00 PM, David Schinazi <[e-mail]>
> wrote:
>
> I'm opposed to adoption.
>
> This mechanism appears to be geared at use cases that would be better
> served by single-HTTP-request-over-TLS-over-CONNECT (which I'll
> conveniently abbreviate to SHROTOC for the rest of this email). The reason
> that OHTTP itself exists is that it provides better performance than
> SHROTOC for small requests and responses, because the TLS handshake
> overhead is quite noticeable when the application data is small. This
> performance win justified the weaker security that OHTTP provides compared
> to SHROTOC. In particular, OHTTP lacks perfect forward secrecy and is
> vulnerable to replay attacks. Extending OHTTP to large messages creates
> something that has performance similar to SHROTOC but with much weaker
> security. If early data is considered useful, SHROTOC can leverage TLS
> 0-RTT with much better security properties: only the early data lacks PFS
> and replay-protection, any data exchanged after the client first's flights
> gets those protections. I'm opposed to creating a new mechanism when there
> is already an available solution with better security.
>
> Apologies if this was covered in yesterday's meeting, I was unable to
> attend and did not find minutes or recordings for it.
>
> Thanks,
> David
>
> On Wed, Jan 24, 2024 at 2:10 PM Mark Nottingham <mnot=
> [e-mail]> wrote:
>
>> I support adoption.
>>
>> > On 24 Jan 2024, at 10:27 am, Shivan Kaul Sahib <
>> [e-mail]> wrote:
>> >
>> > ohai all,
>> >
>> > Thanks to folks who attended the interim today to discuss
>> https://www.ietf.org/archive/id/draft-ohai-chunked-ohttp-01.html.
>> Overall, there was interest in adopting and working on the document.
>> >
>> > This email starts a 2 week call for adoption for
>> https://datatracker.ietf.org/doc/draft-ohai-chunked-ohttp/. Please let
>> us know what you think about OHAI adopting this document by February 6.
>> >
>> > Thanks,
>> > Shivan & Richard
>> >
>> > On Tue, 23 Jan 2024 at 15:24, IETF Secretariat <
>> [e-mail]> wrote:
>> >
>> > The OHAI WG has placed draft-ohai-chunked-ohttp in state
>> > Call For Adoption By WG Issued (entered by Shivan Sahib)
>> >
>> > The document is available at
>> > https://datatracker.ietf.org/doc/draft-ohai-chunked-ohttp/
>> >
>> >
>> > --
>> > Ohai mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/ohai
>>
>> --
>> Mark Nottingham   https://www.mnot.net/
>>
>> --
>> Ohai mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ohai
>>
> --
> Ohai mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ohai
>
>
>