Re: Request for Authenticated but not Encrypted Traffic

Behcet Sarikaya <sarikaya2012@gmail.com> Mon, 03 October 2022 16:55 UTC

Return-Path: <sarikaya2012@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B307C14F75F for <quic@ietfa.amsl.com>; Mon, 3 Oct 2022 09:55:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.857
X-Spam-Level:
X-Spam-Status: No, score=-6.857 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5gwwVH1yOwn for <quic@ietfa.amsl.com>; Mon, 3 Oct 2022 09:55:30 -0700 (PDT)
Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB64C1524C6 for <quic@ietf.org>; Mon, 3 Oct 2022 09:55:00 -0700 (PDT)
Received: by mail-vs1-xe2d.google.com with SMTP id m65so11970779vsc.1 for <quic@ietf.org>; Mon, 03 Oct 2022 09:55:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=37roxeV9AloCalZpr68ET6S8nUBegMngkT9tCuwTvuI=; b=fSE5ucb8/tPaSrsxquUXV2Rxl/0kpYVdNgiM7mvQnisK2yc9H4WJf0GSXPyMXtBQaK +H7q+nE+ZKG/E0EtxcZxPPGp4udr6uh6G23Wy7bEUV2VnFNtPX2e5JZ0VuQmtHf1PCpN rm3XyLmNlT+fXiVoXIeUq0B7u8yvOih/ZxghcweQo+sw9smce7apvDFceVX1vH2D0Tsa G6QgSdzCj30YGHpQM0TxbpwNoQdTGsNV514zgttLmFMzd3tfN8C4tgTOaBdCIMXtl7/9 FB1PU61e5XSE4TQKoVu1bmbfkRmgREMcCKjYnbtU54k0q6ifHUBmpmhuXPNCGGsLX50D N6MQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=37roxeV9AloCalZpr68ET6S8nUBegMngkT9tCuwTvuI=; b=CsCA6se8T2wiDBWBGQPjcy5L0do+skSCWqW/DmCL240mAULag6VCUb/YqCoLgHipqr HOzhnJd5DW6Q0nhMN1zXhkqTEI+j9Janqct1og1UXcXUdIoKl9Eqyji8xKdrK4MTh/M9 4LQoQTpuXCDE+dSQiAkN2ZcLRQRd8HDVxm6G7v0MNPGg4nk8F4fW5rGCnmoI224cYj0J 025hgWjaoFOR1gTUuBb7Hpzx0Hd07kf8ijnSIwn6HVo8Al767yAGa+J4PXp7oNn5d26L Q5yPHpUblaghXtGkpZ7YDElvvAt7oRNr/6Wa6x+AKrU0pN9GslNfb9ctw2PLmnjxJmvo TvQQ==
X-Gm-Message-State: ACrzQf3uiaPFgunKZAthoJJ63ioDtUnwd1Gm0QCSH7QxTWzyLk7e5HRB Gz0mPtkNvlBvxNNVwOtD9wHl4KMavx34/unrNAHo4db+uF4=
X-Google-Smtp-Source: AMsMyM4CPKVVjqd/Qh8KdU37Zn5Q4rwF3TI8zz5Okn9LMbqvX+MCLD1rulhCDafm7dqIY+a52w11zZrC0jxEwzfoZ4M=
X-Received: by 2002:a67:c891:0:b0:3a6:3a2e:6a52 with SMTP id v17-20020a67c891000000b003a63a2e6a52mr4360177vsk.49.1664816099266; Mon, 03 Oct 2022 09:54:59 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+Lwgo5i=FD9sMcp+o_N-e5MprDDCDobzjh-FpwGKhiH99iQ@mail.gmail.com> <3C9CC208-E4E1-4F9F-B10A-6ACF485A0CEF@huitema.net> <CAMm+LwhVM+7Db6ZPLuE5A5VLYqocvZWr=hfKcN=HgYhrdLrgTQ@mail.gmail.com> <dbf9c81b-38f5-2767-1a1b-3309077764aa@huitema.net>
In-Reply-To: <dbf9c81b-38f5-2767-1a1b-3309077764aa@huitema.net>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Mon, 03 Oct 2022 11:54:47 -0500
Message-ID: <CAC8QAcdfiHvir=jbzegVAi1vqYHiucX4w4J=+vOaiDm14sjDOA@mail.gmail.com>
Subject: Re: Request for Authenticated but not Encrypted Traffic
To: Christian Huitema <huitema@huitema.net>
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, Matt Joras <matt.joras@gmail.com>, "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, quic@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003692d605ea2434c1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/bkDCh9PV1m85E13ZvN-iW2oFMOA>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Oct 2022 16:55:32 -0000

Hi Christian,

I quickly glanced through RFC 9250 which defines DoQ and references ALPN in
RFC 7301.
Agree with Philip that DoQ does not define something that is independent of
HTTP.

Will it come one day, we don't know?
Behcet


On Fri, Sep 30, 2022 at 6:34 PM Christian Huitema <huitema@huitema.net>
wrote:

>
> On 9/30/2022 12:38 PM, Phillip Hallam-Baker wrote:
>
> On Fri, Sep 30, 2022 at 3:04 PM Christian Huitema <huitema@huitema.net> <huitema@huitema.net>
> 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
>
>
>