[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement
Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Sun, 25 August 2024 21:53 UTC
Return-Path: <muhammad_usama.sardar@tu-dresden.de>
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 8291AC14CF09 for <tls@ietfa.amsl.com>; Sun, 25 Aug 2024 14:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.407
X-Spam-Level:
X-Spam-Status: No, score=-4.407 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=tu-dresden.de
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 YtIc5xK3hQNn for <tls@ietfa.amsl.com>; Sun, 25 Aug 2024 14:53:52 -0700 (PDT)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AC04C14F5EC for <tls@ietf.org>; Sun, 25 Aug 2024 14:53:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zWgkkPF+0fET9xHjXzFy6ZK4KYrTH4FZyA3fxkJCK8E=; b=W8NGbKPoq5pdc1qwBrWnXN8grf kpERn9BHAll4h38lg0OddUzNKaIsLokLd+v4J16J5mnSQdjuQdREsmpVPp5aJd40nhIdE4zswY015 PW474C0Cv/mX2B3EBpnbmJcAv+8SnIS6+0ouWwy6ffiMmvsupWmIE0keMTT1p3Wmyc6fiOQoCervl 20YoDv/IPKZgl0ENm79BAXxSUldVCoyMt/skKLfA4Rs5pepn/vcDiIqKbIr7Lo7qX/VFN2wvTM8aG aWts0J7b0o3mpH7rfNFvS6LF07c7jzOMPGqhLU9GMZlvNezcQbfCThuPbx9vjGQgJWTXgdOy2W9lk e9Yhax2Q==;
Received: from [172.26.35.113] (helo=msx.tu-dresden.de) by mailout3.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1siLBG-00Fenj-Vb for tls@ietf.org; Sun, 25 Aug 2024 23:53:51 +0200
Received: from msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) by MSX-T313.msx.ad.zih.tu-dresden.de (172.26.35.113) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Sun, 25 Aug 2024 23:53:47 +0200
Received: from [192.168.68.185] (94.174.54.252) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Sun, 25 Aug 2024 23:53:46 +0200
Message-ID: <659f17f5-83f6-4dd5-a401-496f0aa22615@tu-dresden.de>
Date: Sun, 25 Aug 2024 22:53:46 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: tls@ietf.org
References: <CAOgPGoBxoEhVkzb=WYFvNEhN0sKLDLir0qPVSqx_a=Co7dkXgA@mail.gmail.com> <1E84DBF8-CA48-4CA9-A435-9E61E981D8DF@akamai.com> <CABcZeBN6PDuVeNcq+jWOXq2WzMjTp6xqkpMTPYa0B1J95ZBsWg@mail.gmail.com>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <CABcZeBN6PDuVeNcq+jWOXq2WzMjTp6xqkpMTPYa0B1J95ZBsWg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ClientProxiedBy: MSX-L315.msx.ad.zih.tu-dresden.de (172.26.34.115) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: XJTCX2IAWMX76VOGHSSMUED7V4QBUL7J
X-Message-ID-Hash: XJTCX2IAWMX76VOGHSSMUED7V4QBUL7J
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
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
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/ZwGlPa3h4zA1StwAz1Ji2bYPRRI>
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 agree with Ekr that the two things should be kept separate. In addition, may I also suggest to keep this thread only for discussion about #1, please? In this thread, the chairs are asking a simple question, namely: On 23.08.24 19:30, Joseph Salowey wrote: > Please respond to the list with a brief reason why you think the > document requires formal analysis or not. For issues/recommendations about #2, please use the thread where the process was actually proposed. Thanks, Usama On 25.08.24 22:54, Eric Rescorla wrote: > Let's try to disentangle two questions: > > 1. Whether we should require this document to have some sort of formal > analysis prior to advancing > 2. Whether the feedback from the triage panel should be handled in > some other way > > I don't have a strong opinion on (2), but I don't see that the answer > to (1) turns on that. Rather, it turns on whether you think that this > is a significant enough change with unclear enough properties that we > should develop higher confidence before advancing it at PS. Is your > position that that's not the case? > > -Ekr >
- [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