Re: Request for Authenticated but not Encrypted Traffic

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 03 October 2022 18:13 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 082F8C152560 for <quic@ietfa.amsl.com>; Mon, 3 Oct 2022 11:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.409
X-Spam-Level:
X-Spam-Status: No, score=-6.409 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 ryJ0vbq3VrP0 for <quic@ietfa.amsl.com>; Mon, 3 Oct 2022 11:13:21 -0700 (PDT)
Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) (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 389A8C1524DE for <quic@ietf.org>; Mon, 3 Oct 2022 11:13:21 -0700 (PDT)
Received: by mail-oi1-f178.google.com with SMTP id v130so12115280oie.2 for <quic@ietf.org>; Mon, 03 Oct 2022 11:13:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=8qUrJobuU8U4iGUhYUPdiNmYUd+j/2CpwcjSMVGLnMo=; b=KRd6JSAg5UsGI6eQrFkn8WhHu2V6e2R6UT/boMSLRrEGf/bNJbeLIrvUXB41akXGxj zvGYpqxPFen9CoglsSu8rwLBrdkEvEAPKyFzMRrBlddZCbERC1IcAHURHy4E4rNDMZly Y85c6ZJZvjUU3GTCJBV3C3htMcNNYptZ7oH/AsPigKTV3AYVExgijo8MrscSbflX+1r+ FCdK92FlneEsey0MJUQF4jcMi5T3DGi3PRyT3KGXDcPykIZbJCvLsglBagJO8perXccI Uux1IGZe99t+F9M83qUErLVxdLnTkuL0wSXvqlm3BtMwXoLrFHNqYcelWLISKkF57E5b ZEjQ==
X-Gm-Message-State: ACrzQf3fUlqnZZfOAVb+POkcIuuS6BC5Y8y2hXkd2N7SheH6zJMSJUdS JdrVGhgUCy7ks7tGIIeauuKCB3YzRQpI43nYz2s247TS
X-Google-Smtp-Source: AMsMyM6pZRQNemIBun/DN1wHCPDAWCsIC8VaOMUJiLK+/O5sRsFUgyJjKZ4garaGp+3uh6dv1txKpOVaXSWmM5oMB5w=
X-Received: by 2002:a05:6808:1a87:b0:34f:67aa:5089 with SMTP id bm7-20020a0568081a8700b0034f67aa5089mr4615250oib.108.1664820799103; Mon, 03 Oct 2022 11:13:19 -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> <CAC8QAcdfiHvir=jbzegVAi1vqYHiucX4w4J=+vOaiDm14sjDOA@mail.gmail.com> <CALGR9oa_gGx=kdgFcoG+7MXW4km8vs60_sUW=6on82AfPsnAqw@mail.gmail.com>
In-Reply-To: <CALGR9oa_gGx=kdgFcoG+7MXW4km8vs60_sUW=6on82AfPsnAqw@mail.gmail.com>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Mon, 03 Oct 2022 14:13:08 -0400
Message-ID: <CAMm+LwhbLZ44+9ZwDRuOFfkR=i5e1QG01FQe-TZdo_KQKdwkdA@mail.gmail.com>
Subject: Re: Request for Authenticated but not Encrypted Traffic
To: quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000586a0905ea254c89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5ZQ-AybIImW7evz7trnYQUUMXk8>
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 18:13:25 -0000

I think we have to actually build a prototype of a transactional-first
transport, then build some applications over it and only then look to see
whether/how we might re-use QUIC.

That is how I originally worked on HTTP, I build applications using HTTP as
a transport, one of which was the first Webmail service, those allowed me
to discover the need for content length and start working on connection
keepalive and framing.

And we need to build any such system around the capabilities of modern
programming languages which support threads and asynchronous methods.
Otherwise we just end up trapped in subordination type interactions and
don't progress beyond RPC.

What I am saying is, let me build something, then take a look at it and
tell me if/how to build it using QUIC.


On Mon, Oct 3, 2022 at 1:19 PM Lucas Pardue <lucaspardue.24.7@gmail.com>
wrote:

> Hi Behcet,
>
>
> On Mon, Oct 3, 2022 at 5:56 PM Behcet Sarikaya <sarikaya2012@gmail.com>
> wrote:
>
>> 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
>>
>
> DoQ is an application mapping over QUIC. ALPN is an extension to TLS. DoQ
> might use a transactional model that maps to bidirectional streams but that
> is the full extent of similarities to HTTP; there is no normative
> dependency.
>
> RFC 9000 was written carefully to describe the interface that
> application-data-bearing streams can provide to applications. This is not
> related to HTTP, QUIC is independent of HTTP. Indeed, QUIC on its own means
> pretty much nothing. It needs an application mapping protocol. The
> recently-published applicability draft, RFC 9308 [1], is specifically
> written to aid designers or implementers of such mappings. Randy might find
> RFC 9308 informative if wishing to pursue QUIC as a transport substrate for
> the OT application layer traffic.
>
> Cheers
> Lucas
>
> [1] - https://www.rfc-editor.org/rfc/rfc9308.html
>
>
>