[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
"Salz, Rich" <rsalz@akamai.com> Mon, 26 August 2024 14:12 UTC
Return-Path: <rsalz@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D37C14F749 for <tls@ietfa.amsl.com>; Mon, 26 Aug 2024 07:12:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.252
X-Spam-Level:
X-Spam-Status: No, score=-7.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.148, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 RQF8uolz0V4a for <tls@ietfa.amsl.com>; Mon, 26 Aug 2024 07:12:39 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) by ietfa.amsl.com (Postfix) with ESMTP id 5C225C14F738 for <tls@ietf.org>; Mon, 26 Aug 2024 07:12:39 -0700 (PDT)
Received: from pps.filterd (m0409411.ppops.net [127.0.0.1]) by m0409411.ppops.net-00190b01. (8.18.1.2/8.18.1.2) with ESMTP id 47QDt1RC010361; Mon, 26 Aug 2024 15:12:38 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=cc :content-id:content-transfer-encoding:content-type:date:from :in-reply-to:message-id:mime-version:references:subject:to; s= jan2016.eng; bh=YIxLTuhS1WvHvGNs+PnJKEgkRRbe9NuxFVsMigDRTtc=; b= Kx3EHhGPv8zLtagYRDyYVGRjS70gR3t6lIiSn1dIVvRBJ1XEqCqDyQb7opF1m0yZ /9XJlg1jFbsmRRNTVajErsMplDTPwhmqqxIwOm4k/RK2Id8+QJ3XvdcD/2Cm22oP fo/97jd3LgAqS75VRHsiV/u3Wc8hNe/srxUhCpc+H1UK+fuTQbOEBCg/FxmXdvDb YAqG6Pov8zfncZcDFFYepfeNJP5k61EdjXZmohyb1MpjltPww+JJed/eQaC4BOP5 EyslwToweMVq7iFJ3N3KntYu14RjKrtrNxJIp6RkWYB+31XpbE+txF15shPlMiWf JgylcFWt1quyP5IzcGJrbQ==
Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0409411.ppops.net-00190b01. (PPS) with ESMTPS id 418qqj2kwe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2024 15:12:37 +0100 (BST)
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.18.1.2/8.18.1.2) with ESMTP id 47QBReSm015858; Mon, 26 Aug 2024 10:12:37 -0400
Received: from email.msg.corp.akamai.com ([172.27.91.21]) by prod-mail-ppoint3.akamai.com (PPS) with ESMTPS id 417vdyu4qn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Aug 2024 10:12:36 -0400
Received: from usma1ex-dag4mb4.msg.corp.akamai.com (172.27.91.23) by usma1ex-dag4mb2.msg.corp.akamai.com (172.27.91.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 26 Aug 2024 10:12:36 -0400
Received: from usma1ex-dag4mb4.msg.corp.akamai.com ([172.27.91.23]) by usma1ex-dag4mb4.msg.corp.akamai.com ([172.27.91.23]) with mapi id 15.02.1544.011; Mon, 26 Aug 2024 10:12:36 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Deirdre Connolly <durumcrustulum@gmail.com>
Thread-Topic: [TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
Thread-Index: AQHa9zB3NDvILjXxckOj6Vb+ZrlT6bI4vhyAgADJdQCAAERoAP//yaWA
Date: Mon, 26 Aug 2024 14:12:35 +0000
Message-ID: <B7872890-71F2-41BC-9ED9-F085CB18FA95@akamai.com>
References: <1E84DBF8-CA48-4CA9-A435-9E61E981D8DF@akamai.com> <6284E288-4F8E-4E2A-8335-5054D9D7A6DF@obtuse.com> <CAFR824xAxfUFrXyo5PZckJPqoM3fU8ESNrDHUfOKNzDF_jJZQA@mail.gmail.com> <A5E3474B-E3D5-4DA2-BCAD-D443B2A02B5A@akamai.com> <CAFR824y=stSf28Lt=bDoM2yCOHMAEt2OsaFPAY7dxGjx+-DHug@mail.gmail.com>
In-Reply-To: <CAFR824y=stSf28Lt=bDoM2yCOHMAEt2OsaFPAY7dxGjx+-DHug@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.88.24081116
x-originating-ip: [172.27.164.43]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A151BB6CF801E84190DA439386C35520@akamai.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-08-26_11,2024-08-26_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 spamscore=0 adultscore=0 malwarescore=0 phishscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2407110000 definitions=main-2408260108
X-Proofpoint-GUID: xjhBTu7BUdN0wOkYFtMfxk3WypFCsCRY
X-Proofpoint-ORIG-GUID: xjhBTu7BUdN0wOkYFtMfxk3WypFCsCRY
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16 definitions=2024-08-26_11,2024-08-26_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 phishscore=0 adultscore=0 spamscore=0 mlxscore=0 clxscore=1015 bulkscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2407110000 definitions=main-2408260109
Message-ID-Hash: Q3D73M7MWMNZ2ILWK36QDLV23N525SK7
X-Message-ID-Hash: Q3D73M7MWMNZ2ILWK36QDLV23N525SK7
X-MailFrom: rsalz@akamai.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "TLS@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RsmOaPgcKKgJfPCd5wM_pOKaUao>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>
➢ All of it was posted to the list in May: ➢ https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/ Quoting that message: “Here is a summary across all participants:” It is not the messages and discussion. Further, that summary is inconsistent and hard to follow: *Does the change merit an updated analysis?* I think so.... The main question to ask, other than whether this extension breaks prior analyses, is what are the new guarantees it provides: that will indeed require new analysis. I see much more need for analysis when it comes to the authentication properties of the PSK (psk/cert combination), whereas the secrecy (assuming authentication is a non-goal) is much more straightforward. I agree with the above. Let's number those responses one through four. Were they four different people? Are two and three from the same person? What is the "above" that number four agrees with? Further, as I recently noted, a stated goal of the panel was to provide a level of estimate of the amount of work required. The only response in the summary was "seems feasible." By convention within the IETF, WGChairs are not supposed to weigh in *as Chairs* on technical matters. (Recall EKR stepped down as Chair to work on TLS 1.3.) Looking at the description in the not-really-current, but-still-mostly-correct, RFC about this, https://www.rfc-editor.org/rfc/rfc2418.html#page-16 there is *no mention* of Chairs providing technical expertise. We consider an "anononymity set" a useful thing for TLS ECH, privacy-preserving measurement, and so on. It is *not* appropriate here. That's what this panel is, despite (almost?) everyone in the WG who commented saying that they don't like it. A point to which the chairs neve directly responded. "I was talking to more than one cryptographer at CRYPTO this week who have sworn off all participation in the IETF after the curve flamewares in the past, etc". And how many of them are on the triage panel? And what curve wars, the ones that happened in CFRG? And what is etc? And really, academia is better? I agree that IETF behavior has driven away people who could make useful contributions. That is sad. Maybe we'll continue to improve our behavior enough that they will come back. The trade-off, having feedback filtered through the WG chairs, mixed in with other feedback, is not worth the perversion of the IETF open policies and procedures. Perhaps teach them how to contribute with a not-obvious email, "pskbreaker@protonmail.com" or some such.
- [TLS]Consensus call for RFC8773bis Formal Analysi… Joseph Salowey
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Ben Smyth
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Salz, Rich
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Eric Rescorla
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Bob Beck
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Deirdre Connolly
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Deirdre Connolly
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Salz, Rich
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Deirdre Connolly
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Salz, Rich
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Muhammad Usama Sardar
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Stephen Farrell
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Christopher Patton
- [TLS] FATT Process Joseph Salowey
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Eric Rescorla
- [TLS] Re: FATT Process Stephen Farrell
- [TLS] Re: FATT Process Joseph Salowey
- [TLS] Re: FATT Process Salz, Rich
- [TLS] Re: FATT Process Stephen Farrell
- [TLS] Re: FATT Process Watson Ladd
- [TLS] Re: FATT Process Salz, Rich
- [TLS]Re: Consensus call for RFC8773bis Formal Ana… Salz, Rich
- [TLS] Re: Consensus call for RFC8773bis Formal An… Joseph Salowey
- [TLS] Re: Consensus call for RFC8773bis Formal An… Russ Housley
- [TLS] Re: Consensus call for RFC8773bis Formal An… Eric Rescorla