Re: Request for Authenticated but not Encrypted Traffic
Phillip Hallam-Baker <phill@hallambaker.com> Fri, 30 September 2022 19:38 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 E7D1BC14CF04 for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 12:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.411
X-Spam-Level:
X-Spam-Status: No, score=-1.411 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_H2=-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 TkPkGXLKBRvz for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 12:38:26 -0700 (PDT)
Received: from mail-oa1-f48.google.com (mail-oa1-f48.google.com [209.85.160.48]) (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 C6EE9C14CF15 for <quic@ietf.org>; Fri, 30 Sep 2022 12:38:26 -0700 (PDT)
Received: by mail-oa1-f48.google.com with SMTP id 586e51a60fabf-11e9a7135easo6616302fac.6 for <quic@ietf.org>; Fri, 30 Sep 2022 12:38:26 -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=4Kzi8fqH5r3En8GNBYZArq2fBYR3ALTHMlr/PaoaBGY=; b=WMNxh6SdDrUKYqbzLyA2J1ngBpftThwSyi6p7yVFpD7pe0f1qcKVb+g80R3xRC6DJs BjjAaZWhdB+R9zR20hZFc8m8LkjESb4EoYO7n3O09C9ZHKvm4ubTUDld7wZePC6WsAOu E6Z/r7+1oRLUFPTNY4LtGJbxWRgAOgcYTSnIeWmhCacbcKX/DKPC6kwHgiefoGCXmPz+ 5E7HGLhOVt6K4pZnPf7kBT3esXLUAmCJx0Q1WrWJPmhH/gUz2GeDIQr+h75cZosN5ch/ q2WICcsU3tqPgFKk8v0EWG4oF8cYJynn0igedWgMfDODE966qqOuwCVN4Df9CecvePcY Lzug==
X-Gm-Message-State: ACrzQf04+tp6ZkIeDu7pxOJQGiTXeWXtMT0kWBrCuIbjjjNmeaKdvkW4 y2p9r9yizxo/wF/rgNnbAe/l8FZLQQjzwyNLFJc=
X-Google-Smtp-Source: AMsMyM5S6F7awaNXCLzgSxbsHCAmSvQCfUWCjKgruSeqKMqRLYIb8Nxz0uyJCYfwcMKvMax3TGlSYxDXmt+bz5YL9m4=
X-Received: by 2002:a05:6870:c210:b0:131:e1ab:2cfb with SMTP id z16-20020a056870c21000b00131e1ab2cfbmr4123679oae.244.1664566705913; Fri, 30 Sep 2022 12:38:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAMm+Lwgo5i=FD9sMcp+o_N-e5MprDDCDobzjh-FpwGKhiH99iQ@mail.gmail.com> <3C9CC208-E4E1-4F9F-B10A-6ACF485A0CEF@huitema.net>
In-Reply-To: <3C9CC208-E4E1-4F9F-B10A-6ACF485A0CEF@huitema.net>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Fri, 30 Sep 2022 15:38:15 -0400
Message-ID: <CAMm+LwhVM+7Db6ZPLuE5A5VLYqocvZWr=hfKcN=HgYhrdLrgTQ@mail.gmail.com>
Subject: Re: Request for Authenticated but not Encrypted Traffic
To: Christian Huitema <huitema@huitema.net>
Cc: Matt Joras <matt.joras@gmail.com>, "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>, quic@ietf.org
Content-Type: multipart/alternative; boundary="00000000000036053305e9ea23ca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/mWOGGTO6vHtShS6s8JS8Ha0ChKY>
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: Fri, 30 Sep 2022 19:38:29 -0000
On Fri, Sep 30, 2022 at 3:04 PM Christian Huitema <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. In the second case the service has to receive the data and start working on it before the difficulty is known. And then we get into issues of seeing the progress of the work. So the communication pattern is actually more like the third where a transaction consists of a single request followed by a series of updates Sure, we could design a presentation layer on top of QUIC. I think it is better to design a transport/presentation layer for the problem space and then see how we might make use of QUIC. Otherwise we are not doing research, we are looking how to use the hammer we already built to drive in every screw we see. > On Sep 30, 2022, at 12:33 PM, Phillip Hallam-Baker <phill@hallambaker.com> > wrote: > > > > > On Fri, Sep 30, 2022 at 12:25 PM Matt Joras <matt.joras@gmail.com> wrote: > >> Hi, >> >> On Fri, Sep 30, 2022 at 9:02 AM Randy Armstrong (OPC) < >> randy.armstrong@opcfoundation.org> wrote: >> >>> >>> - Process control is absolutely not a good match for QUIC, nor are >>> Web services in general. HTTP is a lousy transport for Web Services and I >>> write as one of the people who designed HTTP/1.0, >>> >>> >>> >>> Can you explain what aspects of QUIC make it not suitable? >>> >>> I thought a QUIC stream was a full duplex TCP-like pipe between two >>> processes. >>> >>> But your description makes it sound like it is as limited as a HTTP >>> connection. >>> >> >> While Phil's individual participation may have left him with such an >> impression, this is not manifest in the protocol that was standardized nor >> the implementations that have materialized. QUIC is certainly not limited >> to the semantics of HTTP, and has many desirable properties that make it a >> very flexible "generic" transport protocol. While HTTP traffic on the >> Internet was a driving usecase for implementers and was the first usecase >> standardized, it is certainly not the only appropriate usecase. Indeed, >> there are already non-HTTP and non-Internet users of QUIC at scale. >> >> The QUIC WG is a venue to discuss how QUIC can be extended to meet >> emerging needs application usecases, though of course it is not the case >> that QUIC is the only (or best) potential solution to applications' needs >> for transporting bits of data over networks. >> > > 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. > > What Web Services really need is a mechanism that is purpose designed to > support transactional interactions and expose certain information to the > service provider and service consumer that really doesn't fit the HTTP > model at all well. > > [Yes, I know the holy writ of Thompson and Richie proved that > everything is a stream... No they didn't and I discussed this with Richie > personally. As with much of what is attributed to David Clarke, do not > extrapolate conclusions beyond the context in which they were developed > without thought.] > > What we are doing today is using HTTP POST as a presentation layer on top > of TCP, TLS or QUIC. And that approach has limitations that really can't be > addressed within the HTTP framework which is RPC Request/Response. For a > robust transactional system, I want to be able to do more than simple > subordination. I want to allow a service to receive a series of transaction > requests and then report back results on each part as they are completed. I > want to be able to report back partial results. I want a service to be able > to decide whether it wants to accept a transaction request requiring a > large amount of data to be operated on before the data is sent. > > Yes, for people who have only seen Web Services built on HTTP, this is > going to raise the question, 'why do we need to do this'. > > The way forward in this case is to build something that is purpose > designed to support Web Services (and not Web Browsing) and then see if it > makes sense to backport the same capabilities into QUIC. Which it might or > might not. The problem from my end being that QUIC is already a very large > and very complex specification and we might only end up using a small part > of that. > >
- Request for Authenticated but not Encrypted Traff… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Roberto Peon
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Salz, Rich
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Martin Thomson
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Carsten Bormann
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Carsten Bormann
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Lars Eggert
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Behcet Sarikaya
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Matt Joras
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Dave Taht
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Christian Huitema
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Christian Huitema
- Re: Request for Authenticated but not Encrypted T… Christian Huitema
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Randy Armstrong (OPC)
- Re: Request for Authenticated but not Encrypted T… Willy Tarreau
- Re: Request for Authenticated but not Encrypted T… Paul Vixie
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- RE: Request for Authenticated but not Encrypted T… Antoine FRESSANCOURT
- Re: Request for Authenticated but not Encrypted T… Dirkjan Ochtman
- Re: Request for Authenticated but not Encrypted T… Behcet Sarikaya
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Martin Duke
- Re: Request for Authenticated but not Encrypted T… Michael Tuexen
- Re: Request for Authenticated but not Encrypted T… Roberto Peon
- Re: Request for Authenticated but not Encrypted T… Behcet Sarikaya
- Re: Request for Authenticated but not Encrypted T… Lucas Pardue
- Re: Request for Authenticated but not Encrypted T… Eliot Lear
- Re: Request for Authenticated but not Encrypted T… Phillip Hallam-Baker