Re: Request for Authenticated but not Encrypted Traffic

[Christian Huitema <[e-mail]>]

On 9/30/2022 12:38 PM, Phillip Hallam-Baker wrote:
> On Fri, Sep 30, 2022 at 3:04 PM Christian Huitema<[e-mail]>
> wrote:
>
>> See RFC 9250 for an example of transaction based application using QUIC.
>>
>> -- Christian Huitema
>>
> DNS is an example of an information retrieval service which is the class of
> services that HTTP works for.
>
> What I am looking at are transactions of the form:
>
> Post <EncyclopediaBritannica>
> Analyze <HardProblem>
> Stream <temperatureProbe>
>
> The problem with HTTP for the first is that the receiver doesn't get to
> know how big the data is until the buffer is filled unless Content-Length
> is specified. And that has to be an exact length which kinda makes
> streaming compression hard.

RFC 9250 does not use HTTP. It uses a simple RPC-style interface, 
mapping each RPC transaction to a QUIC stream.

The content length requirement that you cite is entirely an application 
issue. If an application defines its own application level protocol on 
top of QUIC, it can specify messages any which way, including requiring 
explicit message length up front, or in advance.

Of course, this has nothing to do with the claimed requirement to expose 
messages from individual devices to third parties. On that part, the use 
of a Wireshark-style solution appears the most practical, as Martin and 
Lucas pointed out already.

And yes, solutions in which the device being monitored cooperates with 
the monitor don't work if the device does not cooperate. That's a 
generic problem. A compromised device might claim to cooperate, and then 
use some form of steganography to infiltrate or exfiltrate information. 
It could do that even if the transmissions were in clear text. 
Monitoring, in practice, requires cooperation from the monitored device.

-- Christian Huitema