Re: Request for Authenticated but not Encrypted Traffic

Eliot Lear <lear@lear.ch> Wed, 05 October 2022 19:12 UTC

Return-Path: <lear@lear.ch>
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 DD838C14CF10 for <quic@ietfa.amsl.com>; Wed, 5 Oct 2022 12:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.898
X-Spam-Level:
X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 XIjyk6oS_hig for <quic@ietfa.amsl.com>; Wed, 5 Oct 2022 12:12:27 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 46199C14CF0A for <quic@ietf.org>; Wed, 5 Oct 2022 12:12:25 -0700 (PDT)
Received: from [IPV6:2001:420:c0f8:1004::86] ([IPv6:2001:420:c0f8:1004:0:0:0:86]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 295JCCPD1484412 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 5 Oct 2022 21:12:13 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1664997135; bh=UjFvm9wihd8XpUHK2oTWXfYxBxCdBVdN/2tpD3VZgoI=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=mmv8Ti/dB6EAuDTHsXMxqEi2Ya+e/wiT6TkRhYOQ41TDFkbaZUGdMlnB5lVa33rtU TzsvfJf514ORFUdkvHR+jwTbw3roU0cQ4/QHjRTZ5BOKiDsp3bPSqdjCiV9+N08+je B79Le5hBUWizOhF+LgmJUDBHKqE6H9K+pyF25+UE=
Message-ID: <07aa4256-6224-0512-7273-f8de3fdcab41@lear.ch>
Date: Wed, 05 Oct 2022 21:12:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.1
Content-Language: en-US
To: Lucas Pardue <lucaspardue.24.7@gmail.com>, sarikaya@ieee.org
Cc: Martin Duke <martin.h.duke@gmail.com>, Phillip Hallam-Baker <phill@hallambaker.com>, QUIC WG <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> <dbf9c81b-38f5-2767-1a1b-3309077764aa@huitema.net> <CAC8QAcdfiHvir=jbzegVAi1vqYHiucX4w4J=+vOaiDm14sjDOA@mail.gmail.com> <CALGR9oa_gGx=kdgFcoG+7MXW4km8vs60_sUW=6on82AfPsnAqw@mail.gmail.com> <CAMm+LwhbLZ44+9ZwDRuOFfkR=i5e1QG01FQe-TZdo_KQKdwkdA@mail.gmail.com> <CALGR9oZxmfZJSi16ima7a=bufV_HC2kEsf=YDBOuBFTRA+YPWA@mail.gmail.com> <CAM4esxTDwW_1ggzeHV0WG_g+34_WcP4SvqRMzOn3T-Y6va1wyw@mail.gmail.com> <CAC8QAceouoQxHvVOojcAMm3eKJA9Zn-mtZ9vS5y7A=fMXpPemg@mail.gmail.com> <CALGR9obrAzFiJu_ufnFx_Kf+CU9rSgo24PWwJvfWK9FP+phaxw@mail.gmail.com>
From: Eliot Lear <lear@lear.ch>
Subject: Re: Request for Authenticated but not Encrypted Traffic
In-Reply-To: <CALGR9obrAzFiJu_ufnFx_Kf+CU9rSgo24PWwJvfWK9FP+phaxw@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------KprulLRb2mHXaHEBeoNPyPf2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/zPEv2_SJ3roOd5henlgbP1CPGfI>
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: Wed, 05 Oct 2022 19:12:32 -0000

Hi,

Just on this:

On 05.10.22 19:32, Lucas Pardue wrote:
> RFC 7258 / BCP 188 [1] was published in 2014. It describes how " 
> Pervasive monitoring is a technical attack that should be mitigated in 
> the design of IETF protocols, where possible."

Yes, we said that.  However, we also said the following in the same 
document:

>     Those developing IETF specifications need to be able to describe how
>     they have considered PM, and, if the attack is relevant to the work
>     to be published, be able to justify related design decisions.

Application developers need to consider their particular circumstances 
and make decisions for themselves.  The OPC world makes heavy use of 
ISA99 model / IEC 62443, which has a very formal segmentation scheme 
that may mitigate the need for encryption.  However, some caution is 
advised: services that have in the past been considered local often 
transition to use the Internet.  I'm not close enough to OPC to have a 
fine-tuned crystal ball in that regard.

This doesn't answer the question of whether QUIC should be changed for 
OPC's use case.  That's not an easy call, but I still don't think we 
fully understand the requirements.  The existing QUIC may be perfectly 
fine for certain industrial uses where live key distribution from one 
party either is easy or unnecessary.

Eliot