Re: Request for Authenticated but not Encrypted Traffic

[Lucas Pardue <[e-mail]>]

Hi,

On Fri, Sep 30, 2022 at 5:51 PM Paul Vixie <paul=
[e-mail]> wrote:

> see inline.
>
> Carsten Bormann wrote on 2022-09-30 00:37:
> > On 2022-09-30, at 09:25, Paul Vixie <[e-mail]> 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
>
>