[{"author": "Eric Orth", "text": "

Oh! Hi, OHAI.

", "time": "2023-07-28T19:02:14Z"}, {"author": "Nick Doty", "text": "

nice 4sq blast from the past

", "time": "2023-07-28T19:02:37Z"}, {"author": "Martin Thomson", "text": "

Maybe we should stop calling them \"blue sheets\"

", "time": "2023-07-28T19:05:10Z"}, {"author": "Martin Thomson", "text": "

\"attendance\"

", "time": "2023-07-28T19:05:15Z"}, {"author": "Eric Orth", "text": "

They're still blue, are they not?

", "time": "2023-07-28T19:05:26Z"}, {"author": "Martin Thomson", "text": "

They printed the QR codes on blue paper, but you don't need to use those

", "time": "2023-07-28T19:05:44Z"}, {"author": "Alejandro Sede\u00f1o", "text": "

And yet they float around the room awkwardly.

", "time": "2023-07-28T19:07:16Z"}, {"author": "Richard Barnes", "text": "

fair point Eric

", "time": "2023-07-28T19:07:47Z"}, {"author": "Alex Chernyakhovsky", "text": "

Clearly we need DEFCON style eink badges that show QR codes

", "time": "2023-07-28T19:07:59Z"}, {"author": "Richard Barnes", "text": "

there were bluetooth badges at one IETF meeting. in japan iirc

", "time": "2023-07-28T19:08:18Z"}, {"author": "Richard Barnes", "text": "

privacy concerns

", "time": "2023-07-28T19:08:34Z"}, {"author": "Jim Reid", "text": "

When the IETF adopts retinal scans and DNA sequencing for WG sessions, we'll still be calling that bluesheets.:grinning:

", "time": "2023-07-28T19:08:51Z"}, {"author": "Nick Doty", "text": "

blue NFC tokens?

", "time": "2023-07-28T19:09:13Z"}, {"author": "Richard Barnes", "text": "

BEEP over OHTTP

", "time": "2023-07-28T19:09:41Z"}, {"author": "David Oliver", "text": "

I was under the impression OHTTP was avoiding the browsing (interactive) scenario (\"that's what MASQUE is for\"). Did I miss something?

", "time": "2023-07-28T19:10:05Z"}, {"author": "Kyle Hogan", "text": "

is this going to be interactive?

", "time": "2023-07-28T19:10:24Z"}, {"author": "Shivan Sahib", "text": "

@David Oliver this is still one request/response each way, just large messages

", "time": "2023-07-28T19:10:26Z"}, {"author": "Martin Thomson", "text": "

@David Oliver this won't be interactive

", "time": "2023-07-28T19:10:35Z"}, {"author": "Richard Barnes", "text": "

David: I believe this is still at a single request/response pair level

", "time": "2023-07-28T19:10:43Z"}, {"author": "Martin Thomson", "text": "

However, streaming does create some very interesting stuff.

", "time": "2023-07-28T19:11:00Z"}, {"author": "Martin Thomson", "text": "

Traffic analysis, integration into existing systems.

", "time": "2023-07-28T19:11:31Z"}, {"author": "Kyle Hogan", "text": "

Martin Thomson said:

\n
\n

However, streaming does create some very interesting stuff.

\n
\n

like tagging the stream? what kind of interesting stuff is the concern here?

", "time": "2023-07-28T19:11:33Z"}, {"author": "Nick Doty", "text": "

it would seem like requests would be less likely to be separable, non-identifiable and oblivious if they are large, chunked or interactive

", "time": "2023-07-28T19:11:40Z"}, {"author": "Martin Thomson", "text": "

@Kyle Hogan what do you mean by tagging the stream?

", "time": "2023-07-28T19:12:01Z"}, {"author": "Shivan Sahib", "text": "

I think we all had that moment of panic :D

", "time": "2023-07-28T19:13:19Z"}, {"author": "Kyle Hogan", "text": "

Martin Thomson said:

\n
\n

Kyle Hogan what do you mean by tagging the stream?

\n
\n

one of the Tor attacks is to \"tag\" the stream where an on-path adversary can delay messages in a stream to create a traffic pattern where there was none. This pattern can persist across relays/proxies if not careful

", "time": "2023-07-28T19:13:29Z"}, {"author": "Richard Barnes", "text": "

\"Chunked OHTTP\"

", "time": "2023-07-28T19:14:04Z"}, {"author": "Martin Thomson", "text": "

Oh, that's a property we're good on.

", "time": "2023-07-28T19:14:06Z"}, {"author": "Shivan Sahib", "text": "

Chonky OHTTP

", "time": "2023-07-28T19:14:07Z"}, {"author": "Eric Orth", "text": "

+1 to this statement.

", "time": "2023-07-28T19:14:10Z"}, {"author": "Martin Thomson", "text": "

\"incremental processing\" or IOHTTP

", "time": "2023-07-28T19:14:16Z"}, {"author": "Alex Chernyakhovsky", "text": "

And now we're working with haskell

", "time": "2023-07-28T19:14:32Z"}, {"author": "Jonathan Hoyland", "text": "

Martin Thomson said:

\n
\n

Oh, that's a property we're good on.

\n
\n

So that seems non-obvious to me.

", "time": "2023-07-28T19:15:38Z"}, {"author": "Ted Hardie", "text": "

Long, Oblivious Chunked HTTP (LOCH)

", "time": "2023-07-28T19:15:40Z"}, {"author": "Kyle Hogan", "text": "

is there a concern about total size of the stream here? I'm assuming that the individual messages were fixed size. Is the stream fixed size?

", "time": "2023-07-28T19:15:40Z"}, {"author": "Eric Orth", "text": "

Yes! I guessed correctly.

", "time": "2023-07-28T19:15:59Z"}, {"author": "Jonathan Hoyland", "text": "

David has favourite --children-- i-ds.

", "time": "2023-07-28T19:17:23Z"}, {"author": "Eric Orth", "text": "

Per-message, for a slightly broadening definition of \"message\".

", "time": "2023-07-28T19:17:41Z"}, {"author": "Nick Doty", "text": "

per message ... except that the message could have multiple chunks

", "time": "2023-07-28T19:17:44Z"}, {"author": "Martin Thomson", "text": "

@Jonathan Hoyland my understanding is that tagging only works if you can modify something on one leg that is observable on another leg. We encapsulate on one leg.

", "time": "2023-07-28T19:18:06Z"}, {"author": "Richard Barnes", "text": "

@Nick - yes that

", "time": "2023-07-28T19:18:11Z"}, {"author": "Kyle Hogan", "text": "

Martin Thomson said:

\n
\n

Jonathan Hoyland my understanding is that tagging only works if you can modify something on one leg that is observable on another leg. We encapsulate on one leg.

\n
\n

okay now I have concerns again. what do you mean by encapsulate?

", "time": "2023-07-28T19:18:45Z"}, {"author": "Richard Barnes", "text": "

i remain disgruntled that we are doing HPKE in one direction and raw AEAD in the other

", "time": "2023-07-28T19:18:55Z"}, {"author": "Martin Thomson", "text": "

The encapsulated request is the payload to an HTTPS request.

", "time": "2023-07-28T19:19:15Z"}, {"author": "Eric Orth", "text": "

\"Could do this with MASQUE except with more TLS handshakes\" is true of any OHTTP.

", "time": "2023-07-28T19:19:22Z"}, {"author": "Martin Thomson", "text": "

That is, there are two layers of encapsulation.

", "time": "2023-07-28T19:19:29Z"}, {"author": "Jonathan Hoyland", "text": "

Martin Thomson said:

\n
\n

Jonathan Hoyland my understanding is that tagging only works if you can modify something on one leg that is observable on another leg. We encapsulate on one leg.

\n
\n

So say the server sends 10 packets, I delay the first by one second the second by two seconds, etc. That pattern would continue in the encapsulated stream

", "time": "2023-07-28T19:19:50Z"}, {"author": "Kyle Hogan", "text": "

Martin Thomson said:

\n
\n

That is, there are two layers of encapsulation.

\n
\n

the tagging is at the packet level here. I said \"message, but that wasn't the right term.

", "time": "2023-07-28T19:20:03Z"}, {"author": "Martin Thomson", "text": "

Ah, I see. Timing as tagging.

", "time": "2023-07-28T19:20:11Z"}, {"author": "Kyle Hogan", "text": "

what @Jonathan Hoyland said

", "time": "2023-07-28T19:20:13Z"}, {"author": "Luca Niccolini", "text": "

my 2c. streaming (errr Chunking) will help in building proxies or OHAI support in existing proxies :) you don't really want a proxy that has to buffer a whole message in either direction. This has prevented us from building OHAI support into the edge proxy and instead delegate to a separate service. Also you don't have to enforce arbitrary limits on the size of the request/response to protect from running out of memory

", "time": "2023-07-28T19:21:29Z"}, {"author": "Martin Thomson", "text": "

we should also protect against chunks being inserted ...

", "time": "2023-07-28T19:21:40Z"}, {"author": "Shivan Sahib", "text": "

@Luca Niccolini we'll ask for folks interested in implementing this at the end, that's valuable feedback

", "time": "2023-07-28T19:23:22Z"}, {"author": "Eric Orth", "text": "

Re insertion: Yes, should be a requirement, but we essentially get that for free from HPKE, right? Should be impossible for anybody without the keys to insert a valid message.

", "time": "2023-07-28T19:24:00Z"}, {"author": "Martin Thomson", "text": "

@Luca Niccolini are you talking about a relay or a gateway?

", "time": "2023-07-28T19:24:07Z"}, {"author": "Martin Thomson", "text": "

(I'm assuming gateway)

", "time": "2023-07-28T19:24:21Z"}, {"author": "Kyle Hogan", "text": "

Eric Orth said:

\n
\n

Re insertion: Yes, should be a requirement, but we essentially get that for free from HPKE, right? Should be impossible for anybody without the keys to insert a valid message.

\n
\n

it really depends on which parties can tell whether a message is \"valid\"

", "time": "2023-07-28T19:24:30Z"}, {"author": "Martin Thomson", "text": "

I have to duck out, but I'm very much in support of this being done here.

", "time": "2023-07-28T19:25:00Z"}, {"author": "Kyle Hogan", "text": "

I'm much more familiar with Tor, but \"invalid\" messages can make it pretty far through the network in many cases

", "time": "2023-07-28T19:25:11Z"}, {"author": "Luca Niccolini", "text": "

Martin Thomson said:

\n
\n

Luca Niccolini are you talking about a relay or a gateway?

\n
\n

yes a gateway

", "time": "2023-07-28T19:25:31Z"}, {"author": "Ted Hardie", "text": "

I was intending to reference the case where the client sent query 1 via OHAI service 1 and query 2 via OHAI service two

", "time": "2023-07-28T19:25:45Z"}, {"author": "Nick Doty", "text": "

what's going to stop this from being used for 2 request-response pairs?

", "time": "2023-07-28T19:26:07Z"}, {"author": "Kyle Hogan", "text": "

Nick Doty said:

\n
\n

what's going to stop this from being used for 2 request-response pairs?

\n
\n

it would break the security analysis?

", "time": "2023-07-28T19:26:42Z"}, {"author": "Ted Hardie", "text": "

Here, one long message would chunk them it but send all chunks along the same path, because they are all the same message at the end of the day.

", "time": "2023-07-28T19:27:48Z"}, {"author": "Nick Doty", "text": "

if you need to download a giant file, then how much are you saving by the optimization of not setting up a MASQUE session

", "time": "2023-07-28T19:27:48Z"}, {"author": "David Benjamin", "text": "

Re the chunk boundary issue, is that not the same as TLS records and everything else? I think it's a general requirement that a streaming readers of byte streams must not be sensitive to read boundaries. No objections to saying as much in this draft, but ISTM this is pretty fundamental to streaming.

", "time": "2023-07-28T19:27:48Z"}, {"author": "David Schinazi", "text": "

EKR doesn't want us to have job security

", "time": "2023-07-28T19:28:17Z"}, {"author": "Nick Doty", "text": "

performance improvements for a huge file that will take a long long time to download doesn't seem as helpful?

", "time": "2023-07-28T19:29:01Z"}, {"author": "Mirja K\u00fchlewind", "text": "

For Ekr everything looks like TLS :wink:

", "time": "2023-07-28T19:30:18Z"}, {"author": "David Benjamin", "text": "

It's reinventing TLS, but saving a round trip, in exchange for sacrificing forward secrecy and replay protection. And replacing the auth story with \"I knew the server's key ahead of time\".

", "time": "2023-07-28T19:30:22Z"}, {"author": "Alex Chernyakhovsky", "text": "

I do feel like this proposal, while interesting, is definitely edging into marginal-returns territory where this sort of question is very justified.

", "time": "2023-07-28T19:30:40Z"}, {"author": "Jim Reid", "text": "

The autotranscriber is coping very well with ekr-speed speech.

", "time": "2023-07-28T19:31:16Z"}, {"author": "Mirja K\u00fchlewind", "text": "

It\u2019s a human

", "time": "2023-07-28T19:31:28Z"}, {"author": "Mirja K\u00fchlewind", "text": "

in this room

", "time": "2023-07-28T19:31:34Z"}, {"author": "Andrew Campling", "text": "

Much respect to the human in question!

", "time": "2023-07-28T19:32:43Z"}, {"author": "Jim Reid", "text": "

Even more impressive...

", "time": "2023-07-28T19:32:45Z"}, {"author": "Nick Doty", "text": "

(feeling very validated when my question gets asked in the mic q)

", "time": "2023-07-28T19:36:17Z"}, {"author": "Andrew Campling", "text": "

It\u2019s hard to support something without clarity on the use cases to justify the trade offs

", "time": "2023-07-28T19:36:39Z"}, {"author": "David Schinazi", "text": "

You can make backpressure work properly but it's easy to mess up

", "time": "2023-07-28T19:37:24Z"}, {"author": "David Benjamin", "text": "

I'm not quite following why the backpressure story would be any different if you had tunneled TLS over the proxy instead. They're both ultimately just piping encrypted records. The differences are more in the \"handshake\" half.

", "time": "2023-07-28T19:41:59Z"}, {"author": "Alex Chernyakhovsky", "text": "

Did I miss discussion of a specific use case where the response may be particularly large?

", "time": "2023-07-28T19:43:28Z"}, {"author": "Alex Chernyakhovsky", "text": "

I understood Tommy's discussion there of why that may be desirable, but I don't recall hearing an example such use

", "time": "2023-07-28T19:43:47Z"}, {"author": "Nick Doty", "text": "

maybe Safe Browsing or something, where you want to download an updated segment of a database, but maybe you don't want to reveal to the endpoint which segment of the database you are interested in

", "time": "2023-07-28T19:45:15Z"}, {"author": "Andrew Campling", "text": "

@Alex I believe the very limited info on use cases is the text on slide 3

", "time": "2023-07-28T19:45:43Z"}, {"author": "Alex Chernyakhovsky", "text": "

Yeah, I saw that, I find that a bit too generic to find this sufficiently motivating :(

", "time": "2023-07-28T19:49:21Z"}, {"author": "Mark Nottingham", "text": "

EVERYTHING OVER HTTP

", "time": "2023-07-28T19:50:34Z"}, {"author": "Eric Orth", "text": "

If you create a new key for every DNS request, those are user-specific keys and thus can be used to correlate together all the messages from the same DNS-querying user.

", "time": "2023-07-28T19:51:18Z"}, {"author": "Mark Nottingham", "text": "

For replay, see Idempotency-key header in HTTPAPI

", "time": "2023-07-28T19:51:34Z"}, {"author": "Mark Nottingham", "text": "

:)

", "time": "2023-07-28T19:51:40Z"}, {"author": "Ted Hardie", "text": "

After the formal end of the wg, can we play \"guess the use case\"?

", "time": "2023-07-28T19:53:14Z"}, {"author": "David Benjamin", "text": "

Mark Nottingham said:

\n
\n

For replay, see Idempotency-key header in HTTPAPI

\n
\n

Yup, that's the \"solve replay with recipient state\" solution space. TLS 1.3 has some discussion of that too. :-) You don't need idempotency-key, just any bit of unique randomness in there.

", "time": "2023-07-28T19:53:24Z"}, {"author": "Mark Nottingham", "text": "

Why do we need TLS when we have HTTP? /me ducks

", "time": "2023-07-28T19:53:52Z"}]