IETF Logo Mail Archive

Re: Request for Authenticated but not Encrypted Traffic

Phillip Hallam-Baker <phill@hallambaker.com> Sat, 01 October 2022 14:21 UTC

Return-Path: <hallam@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 C7BF6C14CF12 for <quic@ietfa.amsl.com>; Sat, 1 Oct 2022 07:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.408
X-Spam-Level:
X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
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 SnA-YpqLJESv for <quic@ietfa.amsl.com>; Sat, 1 Oct 2022 07:21:19 -0700 (PDT)
Received: from mail-oo1-f47.google.com (mail-oo1-f47.google.com [209.85.161.47]) (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 B561EC14CF10 for <quic@ietf.org>; Sat, 1 Oct 2022 07:21:19 -0700 (PDT)
Received: by mail-oo1-f47.google.com with SMTP id u19-20020a4a9e93000000b004757198549cso4088632ook.0 for <quic@ietf.org>; Sat, 01 Oct 2022 07:21:19 -0700 (PDT)
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:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=N+tg/C5GnkiukQC6CHjIpjbppJkfvaAE6fHwa8tLij4=; b=3Sis7eL3KgXGjCTGbBDNiPtIo0bstyzdjHRB1i6JYKE7EL/FADJJLSu9jMq191gfZT 3sCLg4tPQXYQ+PxXjKcX4kIIOO7C3UhFFXZqy5lDogyiJO2+Wr4ERJ9gT3cb03iAHo7W BNVBH1ifa6jVVZGsjIdUhMg/uNEdblfilRzczGPP0nzR8KlkLqp1RgVOcx7PC5Tk/1RJ MqHsQT8gcCDOd5OAuy8c82TCXsv1x8cr/5SF2IOlEMTeVbCyP7My+jt3vkCNDX+VG8f6 gVZBa71e6xk0CcpXXBt9RS9hgftU+fGNKxBrFZIpH3UddYZxJA2S4k+5a9lBliJ+KlD3 P6ng==
X-Gm-Message-State: ACrzQf0ktgdfXOtIDx+dQOQDKW35wtmk7Vc91kD6i2sDnbGMjzWcrdzC pFRhr1PLbN+A2PoA93Whgh5MciKKBLizO4E4ZuI=
X-Google-Smtp-Source: AMsMyM6InJlLZE+KJxuVUoC+sTrhnGc1bV8b+S0KalOU+oiE3KrDcTVy+P32M85LX4mLZ5BiN4pR1lsTKR7icymo3fM=
X-Received: by 2002:a9d:17a3:0:b0:655:e46e:3c07 with SMTP id j32-20020a9d17a3000000b00655e46e3c07mr5203326otj.194.1664634078917; Sat, 01 Oct 2022 07:21:18 -0700 (PDT)
MIME-Version: 1.0
References: <SJ0PR08MB82889F488CCA7D8FC4997ACEFA579@SJ0PR08MB8288.namprd08.prod.outlook.com> <e0c93db9-785b-fbfc-604a-5aa047d3c25b@redbarn.org> <SJ0PR08MB8288E1364214A9BCA4DBC6A5FA579@SJ0PR08MB8288.namprd08.prod.outlook.com> <MW5PR15MB51459BB0DCAD6E47A5A89C49D4579@MW5PR15MB5145.namprd15.prod.outlook.com> <SJ0PR08MB8288533C964762C760477D46FA579@SJ0PR08MB8288.namprd08.prod.outlook.com> <CAC8QAcfuVnr0UMii8kR-RZ_n3i8hOSDZTD=fHbkXVy5-3JJKNw@mail.gmail.com> <CAMm+LwhgCQcEMFCi7gc=UhDAGXug1=0Db90K=GnHTw9DOu8fog@mail.gmail.com> <SJ0PR08MB8288BAFDD51D99A8D9D42772FA569@SJ0PR08MB8288.namprd08.prod.outlook.com> <CADdTf+hP_HmwN+QHX=t8Vi=GLVQ=nduAh3xL6rRL_HG2fQdP3g@mail.gmail.com> <CAMm+Lwgo5i=FD9sMcp+o_N-e5MprDDCDobzjh-FpwGKhiH99iQ@mail.gmail.com> <20221001065323.GB11874@1wt.eu>
In-Reply-To: <20221001065323.GB11874@1wt.eu>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sat, 01 Oct 2022 10:21:07 -0400
Message-ID: <CAMm+Lwjm3zL4X=aBeaz+DfW1gtvWHfOCgpkKd377ASHoUm0YiQ@mail.gmail.com>
Subject: Re: Request for Authenticated but not Encrypted Traffic
To: Willy Tarreau <w@1wt.eu>
Cc: Matt Joras <matt.joras@gmail.com>, "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, "quic@ietf.org" <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f47b5205e9f9d259"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Z6J7Z8A5NL0BomYivVvpM2nzKWs>
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: Sat, 01 Oct 2022 14:21:21 -0000

On Sat, Oct 1, 2022 at 2:53 AM Willy Tarreau <w@1wt.eu> wrote:

> On Fri, Sep 30, 2022 at 02:34:11PM -0400, Phillip Hallam-Baker wrote:
> > The crux of the matter is that the high level model of QUIC is that it
> > provides a collection of streams between two points. While that is what
> > people are used to using in WebServices, this model is really only suited
> > to Web Services that are inherently data retrieval.
>
> Why ? I mean, there was a considerable effort so split gQUIC into QUIC+H3,
> and QUIC does provide independent, full-duplex streams that have nothing
> to do with H3.


Streams of octets. Not structured streams directed at identified well-known
services.

I don't think the changes I am going to need are very extensive and there
is a good chance they can be back ported into QUIC when I understand what
they are. But it will be QUIC+X and the X will need to have visibility into
the QUIC part.

Going back to the original point, dropping confidentiality for Web Browsing
in QUIC+H3 is going to be unacceptable to many, myself included.

Dropping confidentiality in QUIC+X might be possible but I would not count
on it and it is not clear that QUIC+X is possible because of the 'why would
you want to do that' tendency.

We charter WGs with a narrow scope because that is the only way to get the
work done. That sometimes means the end product is more constrained than it
need be.

v2.23.0 | Report a Bug | By Email