Hi, On Fri, Sep 30, 2022 at 5:51 PM Paul Vixie <paul= [email protected]> wrote:
> see inline. > > Carsten Bormann wrote on 2022-09-30 00:37: > > On 2022-09-30, at 09:25, Paul Vixie <[email protected]> wrote: > >> > >> what did you have in mind as an example of this, that i might not > dislike? > > > > ... > > > > The part I do not understand is why this is always framed in terms of > > uncontrolled (unrestricted) visibility, i.e., everybody who manages to > > get hold of a packet has full visibility. > > i could live with uncontrolled visibility on my own VM server's internal > networks, or on my datacenter or home LAN. i am open to other ways to > achieve the nec'y visibility -- i don't require that it be uncontrolled. > > > ... > > > > Instead, I'd prefer to pursue something that I'd call Authorized > > Visibility (AV). Here, the communication actors explicitly provide > > visibility to additional justified parties, not simply to any > > eavesdropper that comes along. ... > > i'd be fine with this, as long as it was possible for my gateway to > determine at line rate whether each packet trying to get through was > participating in the Authorized Visibility regime you're describing. > The action seems pretty trivial for QUIC. Endpoints share with trusted parties (e.g. a gateway) the TLS session keys and how they are associated with one or more QUIC connection IDs. Then it's a simple lookup when a packet arrives. If there's no match then, log, alert, drop etc. We might debate about packet decryption performance, i'm not sure how much margin you have on line rate or how much processing time you are willing to throw at it. On my local machine, Wireshark can do these kinds of lookups via SSLKEYLOGFILE files. It would require effort to build a distributed system to achieve the same but the technical barriers seem low and solvable. Cheers Lucas > > Grüße, Carsten > and you. > > -- > P Vixie > >
