My main concern would be side-channel attacks. What kind of information can be gleaned by the size/timing of the trace as it is sent from one side to another? What hypotheses does it allow an attacker to verify? -=R
From: QUIC <[email protected]> on behalf of Ryan Sleevi <[email protected]> Date: Sunday, August 15, 2021 at 1:13 AM To: Kazuho Oku <[email protected]> Cc: Jana Iyengar <[email protected]>, Robin MARX <[email protected]>, IETF QUIC WG <[email protected]>, HTTP Working Group <[email protected]> Subject: Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt On Sat, Aug 14, 2021 at 8:24 PM Kazuho Oku <[email protected]<mailto:[email protected]>> wrote: 3) Relatedly, your POC seems to assume the browser will have just a single connection and a trace request in a second tab will auto map to that connection. That works fine for the POC, but for a real deployment that lets end-users fetch traces, you'd need built-in browser/client support to select a specific connection / fetch traces for all connections to a given origin. Not a big problem ofc, and things like Chrome's netlog export already do this, but still a practical hurdle. Right. I would hope that it would be possible to implement this as a browser extension at least (with the assumption being that requests from a browser extension would be coalesced with other requests going to the same authority). Unfortunately, browsers do not guarantee this property, and past efforts in the IETF to standardize features that assume this property (e.g. Token Binding) or in other SDOs (e.g. ETSI’s unfortunate design with regards to QWACs) end up not working in practice. This is especially true as browsers look to segment connections even further, in relation to privacy properties unique to browser environments (e.g. CORS credentialless, as further expanded by COEP, or the fetch() specifications Network Partition Keys, or security isolation primitives to restrict extension access). I don’t have much stake in this, other than flagging that any design that makes assumptions about connection properties to bits on screen are, generally, flawed assumptions. That’s not to preclude the possibility of direct browser integrations, should it prove useful and of demonstrable value to merit such implementation, although past efforts have failed to achieve that value relative to the complexities of such coupling.
