[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
Deirdre Connolly <durumcrustulum@gmail.com> Sun, 25 August 2024 21:25 UTC
Return-Path: <neried7@gmail.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 E406CC14CF18 for <tls@ietfa.amsl.com>; Sun, 25 Aug 2024 14:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level:
X-Spam-Status: No, score=-1.854 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 51KDKHNsV7hs for <tls@ietfa.amsl.com>; Sun, 25 Aug 2024 14:25:43 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E702C14F736 for <tls@ietf.org>; Sun, 25 Aug 2024 14:25:43 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2f3ffc7841dso32673211fa.0 for <tls@ietf.org>; Sun, 25 Aug 2024 14:25:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724621141; x=1725225941; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ck11mYC/3C3aFXlMRRnaJc8VyuCifte1L1JBkTl8Bg0=; b=HeOSPdNV9NWW2BGVNdU7+Uy+b8amzrIr5umm3KXoaStYBoXo33DblILdy9j+YyiqtJ bQYPd3jX0TgdV7HeVc1y4yabwW1yGuGSS1d2IN1X5m0n5hnpJxCcrtmMZX5E4snbYUUH LqkKH7gWWUQqIdIwsBrGjwXcWawcKUBlmSFxPxt5nzzYvwvvXpjKsUd1m4POzQUw5ft0 YmqvBDutKdVEcvNJnz64d9hbMmG0bjRD/aKNP8neolmoOfqu3g9UDIMpOPw8dAvjY9Cw X3zWizInqCsft/SvxZ6dZhmXaRomytO1vXfkmEL95cjjCX9q1jsFeZYl5XNp5gSsw41X cGAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724621141; x=1725225941; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ck11mYC/3C3aFXlMRRnaJc8VyuCifte1L1JBkTl8Bg0=; b=fwXxakRIwt4kPDHa/eWI5SRB6C/cmcb3/ELH/khNxg78/3gRALnDOqdmgx9lcrRNzf x+HDzV0ak+QDehIrxeSZ9qsj0dR1JJ300Pj/drXuaXdL8T0qWO76MVXYvk5V7mHvr5EV 0DIAMCHVeacddBeQJQ/VByHuv/GRAueNH+R79DUHXL3WFu60cWzwLfe0T5FfH7J5MHRN nKwaM6AlBnEidbGuHMsxoV2P40sFwa0WZc8B+wJMqgeu6YKkgmij+B4AWP/Xo9w7kRwk O11s1aXneuPW30KMkc6y583u9ChDR9Rp/ikg9oSGA0e3ciZX/voiFfUNK7SKs29eGr5S 9tMw==
X-Forwarded-Encrypted: i=1; AJvYcCVRTOftzljCQ0oQ2PbUnRzeF/V3fvtU9BSoChLK7EzVRIKRsoa/Sv6CKJntgCIuEHQJYPg=@ietf.org
X-Gm-Message-State: AOJu0YwiqzfZRDwlO+irsMLpwXLbirP/GICB2VvGVUg7tDomUH1eaLBW +9awV9Bnb3GBe+aGanax6Nf1q22NOVKCmYRuGdcnl2RcinIRJara1UjzQqRexDGcr+Rs5rTIKIL 6QB3WiV0PdspGTQAIdHPJ59yEkzx18TE4
X-Google-Smtp-Source: AGHT+IF5xQ9s2M7xDKI51zPL7JB7UZcP0unEHaBe90JBHi6XdXMGYFTLPjJggqU77YxFRbDMQBh/CLqTZK3KbdbLzGA=
X-Received: by 2002:a05:651c:220d:b0:2f5:806:5d00 with SMTP id 38308e7fff4ca-2f508065e26mr22811901fa.32.1724621140773; Sun, 25 Aug 2024 14:25:40 -0700 (PDT)
MIME-Version: 1.0
References: <1E84DBF8-CA48-4CA9-A435-9E61E981D8DF@akamai.com> <6284E288-4F8E-4E2A-8335-5054D9D7A6DF@obtuse.com>
In-Reply-To: <6284E288-4F8E-4E2A-8335-5054D9D7A6DF@obtuse.com>
From: Deirdre Connolly <durumcrustulum@gmail.com>
Date: Sun, 25 Aug 2024 17:25:04 -0400
Message-ID: <CAFR824y2LD2-q590rihQifcZBgatg64AHTAC1s6Yg3ziHqtO1w@mail.gmail.com>
To: Bob Beck <beck@obtuse.com>
Content-Type: multipart/alternative; boundary="00000000000077d776062088a60e"
Message-ID-Hash: 62C5ZKRWR6KIXHYCJLSD5JJJ3QN7C5E5
X-Message-ID-Hash: 62C5ZKRWR6KIXHYCJLSD5JJJ3QN7C5E5
X-MailFrom: neried7@gmail.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: "Salz, Rich" <rsalz=40akamai.com@dmarc.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/6fSH91jn_Dphu4rk7pwLk8NphfA>
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>
> 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. I agree that it is a problem and should be addressed across the IETF. Unfortunately we keep making changes to TLS 1.3 in the meantime, so. 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 On Sun, Aug 25, 2024 at 4:51 PM Bob Beck <beck@obtuse.com> wrote: > > > 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 > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-leave@ietf.org >
- [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
- [TLS] Re: Consensus call for RFC8773bis Formal An… John Mattsson
- [TLS] Re: Consensus call for RFC8773bis Formal An… John Mattsson
- [TLS] Re: [TLS]Consensus call for RFC8773bis Form… Muhammad Usama Sardar