[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

Bob Beck <beck@obtuse.com> Sun, 25 August 2024 20:50 UTC

Return-Path: <beck@obtuse.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 5F034C14F736 for <tls@ietfa.amsl.com>; Sun, 25 Aug 2024 13:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.72
X-Spam-Level: *
X-Spam-Status: No, score=1.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HELO_DYNAMIC_IPADDR=1.951, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_DYNAMIC=0.982, 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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=obtuse.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 Kk9WB3XTOSjp for <tls@ietfa.amsl.com>; Sun, 25 Aug 2024 13:50:31 -0700 (PDT)
Received: from h198-166-139-10.ptr.cidc.telus.com (h198-166-139-10.ptr.cidc.telus.com [198.166.139.10]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C00C14F726 for <tls@ietf.org>; Sun, 25 Aug 2024 13:50:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=obtuse.com; s=20200401; t=1724619022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=3EVe5sm0oYXxqyyOjofxsDa9XiEHGCTTeQfaDGobcgE=; b=aRmNeUaRsk7F9ujpQRFHvnMGP+rVqbkA+ElPfI/0TXl5wTtGDT4vzSBQEICiDKj9PbdNcg 6+3UITSy+2VwatjxbBL9nmDMVinBqxLScqI4NPv38106se/G6Y6hsKhP92EAOw6RPIlv9M X7x6gNIQRJs1JxHr3/XvJOEFVBX6buU=
Received: from smtpclient.apple (<unknown> [192.168.21.33]) by mail.obtuse.com (OpenSMTPD) with ESMTPSA id fe166454 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sun, 25 Aug 2024 14:50:22 -0600 (MDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-0ED96EF1-8BB4-40FF-A419-8A381B726938"
Content-Transfer-Encoding: 7bit
From: Bob Beck <beck@obtuse.com>
Mime-Version: 1.0 (1.0)
Date: Sun, 25 Aug 2024 14:50:12 -0600
Message-Id: <6284E288-4F8E-4E2A-8335-5054D9D7A6DF@obtuse.com>
References: <1E84DBF8-CA48-4CA9-A435-9E61E981D8DF@akamai.com>
In-Reply-To: <1E84DBF8-CA48-4CA9-A435-9E61E981D8DF@akamai.com>
To: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: NVCWENH4YYNLQNHZFH4YOPPUZQPA24JF
X-Message-ID-Hash: NVCWENH4YYNLQNHZFH4YOPPUZQPA24JF
X-MailFrom: beck@obtuse.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
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/qziYeu14eNZ--HCvL006KjyA2pM>
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>



On Aug 25, 2024, at 13:56, Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org> wrote:



I am opposed. Anonymous email recommendations are not how the IETF operates.


I would also count myself as opposed. While I understand and am sympathetic to a reviewer possibly not wanting to get deluged in email or opinions unrelated to the task at hand, I think if this is truly a problem it is symptomatic to participation in a working group as a whole and should be addressed across the board for everyone. Anonymous reviewers have a number of problems as Rich has pointed out. 

 

Attached below is a note I wrote a month ago to the Chairs.  None of the points written there – and MOST of them were a summary of WG discussion – were addressed.

 

 


From: 
Rich Salz <rsalz@akamai.com>
Date: Tuesday, July 30, 2024 at 1:49 PM
To: "tls-chairs@ietf.org" <tls-chairs@ietf.org>
Subject: Rethinking the formal analysis triage

 

TLS Chairs,

 

I wasn’t sure whether to send this to you or the entire WG. I let another person read this and they suggested the Chairs.  So here you go.

 

I re-read all the messages in the archive [1] and re-watched the 119 and 120 segments on the triage panel.  I believe that, as currently set up, it is so flawed that it should be taken down and rebuilt from scratch.

 

After the idea was proposed in March, the two most common feedback suggestions were

    • Collaborate with UFMRG

    • Make all communications open and on the mailing list

Neither of these were done. In fact, there was no response from the Chairs on either point.

 

From the beginning, the stated intent was the that one thing the panel would provide is an estimate of how much work any suggested analysis would take. The one review that was done so far did not include that, other than “feasible.”

 

Many people have already commented that collating all responses is a bad idea. I want to add one point that I have not seen before: if a subset of the triage reviewers recommends analysis, the WG has no information about the qualifications of those making the recommendation and no way to evaluate how to accept it.

 

This brings up a related point. Anonymous evaluations are against the very nature of the IETF. How can we assess the value of someone’s contributions when we don’t know who they are? Will “Reviewer 1” always be the same person? If the entire panel did not do a review, are WG members expected to treat all members as equally competent and qualified?

 

The WG is strongly in favor of more formal analysis. The Chairs tried to do too much and failed. Start over, respond to the feedback you got from the WG, and pick something easier.

 

[1]  https:/mailarchive.ietf.org/arch/browse/tls/?q=triage

 

 

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-leave@ietf.org