Re: Request for Authenticated but not Encrypted Traffic

[Lucas Pardue <[e-mail]>]

Hi,

On Sat, 1 Oct 2022, 08:37 Paul Vixie, <[e-mail]> wrote:

>
>
> Lucas Pardue wrote on 2022-09-30 10:03:
> > Hi,
> >
> > On Fri, Sep 30, 2022 at 5:51 PM Paul Vixie
> > <paul=[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     > ...
> >
> >     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.
>
> i'm pretty sure the chromecast i evicted won't be willing to do that. it
> ignored my DHCP assignment of DNS, and insisted on using 8.8.8.8, so i
> think google now believes "our device, our rules" which is in stark
> opposition to what i believe ("my network, my rules"). just sayin', but,
> this should also help explain why i want to observe the devices on my
> network and be sure i approve of what they are doing.
>

The question was "can you determine at line rate if a packet is from a
participant of authorized visibility". The answer is yes you probably
could. Devices might not opt into that scheme but that seems to be entirely
the point, on your network block things if you can't observe or don't like
them. In Randy's case this seems quite practical because it sounds like
their networks have further requirements, on top of IETF specs, to
participate.


> > 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.
>
> as a rule, observation is harder than reception. decryption performance
> is probably where the issues would be. if we can't decrypt all the flows
> as fast as the endpoints of each flow can collectively do, we lose. it's
> reasonable to do this for all the flows that will fit in 10GBE with
> current hardware, but that's a harsh mistress in several likely futures.
> an intended receiver has the advantage of being able to slow the sender
> down by not answering often enough or soon enough. an observer cannot.
>

The requirements here are being underspecified to the point of ineffectual
response, and seem to shift on each technical solution that is being
provided by folks on the list. Do these observeres want to inspect QUIC
packets, the QUIC control data, or application data inside STREAM or
DATAGRAM information flows? This matters because it determine the amount of
state an observer has to hold. Steganography was mentioned by other in this
thread, how far does the threat model extend?

An observer can totally slow down a QUIC sender. Drop packets and the
congestion controller will drop the rate that packets are sent. If the
price of admission to your network is some QUIC data transfer performance
overhead, that seems like a fair tradeoff.


> > 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.
>
> thanks for sharing your experiences. but so far i think i'm going to
> have to force the use of a proxy, which will be an intended recipient,
> for the reasons given above.
>

Using a proxy sounds like a very appropriate solution if the requirements
are to inspect QUIC control data or application data flows. The QUIC
protocol provides no barriers to the use of proxies. Such an L7-aware proxy
can add a lot of value when it comes to access control or other
per-application flow observation and enforcement.

Whether its via session key share, or an inline proxy, its important for
end users to explicitly know if the network is able to introspect
information that is confidential at layer 8, and to understand where the
boundaries for that information access might reside. If the act of LAN
observing means that data is made visibile to the WAN, that might be deemed
as a poor tradeoff for end users. My data, my rules, so to say.

Cheers
Lucas