Re: Request for Authenticated but not Encrypted Traffic

Christian Huitema <huitema@huitema.net> Fri, 30 September 2022 23:44 UTC

Return-Path: <huitema@huitema.net>
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 3CA5DC14CF0E for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 16:44:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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=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 CT4GsRfsVQUa for <quic@ietfa.amsl.com>; Fri, 30 Sep 2022 16:44:24 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 571AFC14CF0B for <quic@ietf.org>; Fri, 30 Sep 2022 16:44:24 -0700 (PDT)
Received: from xse30.mail2web.com ([66.113.196.30] helo=xse.mail2web.com) by mx259.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1oePfw-000Gpb-GP for quic@ietf.org; Sat, 01 Oct 2022 01:44:16 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4MfRdk4q07z763 for <quic@ietf.org>; Fri, 30 Sep 2022 16:44:10 -0700 (PDT)
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1oePfu-0003Bo-Hj for quic@ietf.org; Fri, 30 Sep 2022 16:44:10 -0700
Received: (qmail 32339 invoked from network); 30 Sep 2022 23:44:10 -0000
Received: from unknown (HELO [10.0.0.80]) (Authenticated-user:_huitema@huitema.net@[98.60.134.179]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <randy.armstrong@opcfoundation.org>; 30 Sep 2022 23:44:10 -0000
Message-ID: <7a099cee-59db-5c6d-2026-3216c60b37ea@huitema.net>
Date: Fri, 30 Sep 2022 16:44:11 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
To: "Randy Armstrong (OPC)" <randy.armstrong@opcfoundation.org>
Cc: "quic@ietf.org" <quic@ietf.org>
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> <SJ0PR08MB82888AF87EE732F97717AFF4FA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
From: Christian Huitema <huitema@huitema.net>
Subject: Re: Request for Authenticated but not Encrypted Traffic
In-Reply-To: <SJ0PR08MB82888AF87EE732F97717AFF4FA569@SJ0PR08MB8288.namprd08.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: 66.113.196.30
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCHJ7 Ekx9zy829eh4Dm6vI7jmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imcau6YoLc4G0fBJNv57OLjy6BQ6V51u76v35b1wNe/MvdLK0iWX QXXTLFLETKH72XTe2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEEIgtEXyXj6S3SDvReMcV 8TXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7hMIABpqqRGKyDs8xujM3cqBeOl1vvorVlRuGVSovFiMZ50v9KIeAjWFOi/IKXn0wfp mlMLNVfpGcJB6/edmHqNEnFzsC48bTEFY06/YbB87aZA2T1TDpm1DkXX6Es5zXntCB3G1CwpaI3Z 4ESkMWDVEmlGVTLa11kLY1eVj2D9MKlkBnwnvNscG7UwwGQLBmHZcpPgEJKLbDyaC/LdLvvYWmYC t1jcf//hF9iD2YUAsPpVB9v9zY0h8asEYmbGGsLRRrpb2yB+9SGl7QVSZMRQw+hY8baJGsyNJ9eN D7WQAB0sl4OFxBT1d23OUWLVuGpBtL9ewJnoHKUNLZpf7DfZK/JdWvgd2/FibEdMM0Jnxu/VcARR JJg0CPVGXFYA7xCx7SWZBpdAUArn/St00aGa08t44IPL25P8DLNzMDIRDLdvK/cKOEqlCIPGIfYQ DNLcNVwigJ23suxKKQl6t4RW
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/b6EcjtbqGu5QBsvsvVVEojKrzyI>
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 23:44:26 -0000

On 9/30/2022 4:30 PM, Randy Armstrong (OPC) wrote:
>    *   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.
>
> Not quite sure why you make a big deal about this. OPC UA supports the kinds of operations you described but the complex operations are broken into multiple request-response pairs for transport. All OPC UA needs is a full duplex channel that allows responses to be returned in any order. I would imagine that any other protocol built on QUIC would do the same.
That's exactly the way DNS over QUIC is designed. Full duplex channel 
(QUIC connection) allowing for series of transactions. Each transaction 
request (from the client) is mapped to a new duplex stream stream; 
response come back on the reverse part of that stream; responses to 
transactions arrive in any order.
> The important question is: does QUIC have any inherent limitations that would make it difficult to implement complex operations over top of QUIC?

No.

You have to pay attention to the management of connections, how to 
resume connections after they break, etc. But that's pretty standard 
when designing a distributed application.

-- Christian Huitema