[TLS] Proposal: a TLS formal analysis triage panel
Deirdre Connolly <durumcrustulum@gmail.com> Wed, 06 March 2024 01:38 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 13299C15107A for <tls@ietfa.amsl.com>; Tue, 5 Mar 2024 17:38:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level:
X-Spam-Status: No, score=-1.857 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_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 Uh3E9VhMiqim for <tls@ietfa.amsl.com>; Tue, 5 Mar 2024 17:38:29 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 5CB0FC14CF0D for <tls@ietf.org>; Tue, 5 Mar 2024 17:38:29 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id 38308e7fff4ca-2d269b2ff48so19173521fa.3 for <tls@ietf.org>; Tue, 05 Mar 2024 17:38:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709689107; x=1710293907; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=G110MjnKl0AFO4hmWoA08GjLjrf5M4v6KkSaO0Emwwk=; b=NloX4/sJ5dFWQK1KffQaNC3jEXKdezRpmWqpe/XMW10L4dlQENAw8AbotY6+DEefrf vILf2wCpa7Q0qSOSZ44w3+Owy2QQDej2NoMcpBC8RBuosMZJJ5xFZ9FH8RHF0FdKHqp2 FIQI8ViJE4RCqPnzvLY02C/we4aCPrJW3AwL70iB46XgbOYrP+2EOoVu+lzHFaH3edPe zGLYjr0fkOKofy16YN8X7YQz8VfC9aGF5SiRd++2ElQMlDwtADVMnInSARrDaFeYVFZI Jd8JkLJ4vn6fAYnekFxNHMkwmNkOnaDSTKfEf12nskpE9EHvOd6gLu+M4fB10cmkaGaG 9EqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709689107; x=1710293907; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=G110MjnKl0AFO4hmWoA08GjLjrf5M4v6KkSaO0Emwwk=; b=oMOG4wEH1ILmdNtPg+0H/hzcn7cHxNeoUniQsH5i2j78oL6OenId/Z5bl+l6Uh53ib 9r4WsRqSD+RQEXDVXoPqHoGauInaIuBG5NvznhPDPR/CwUFGGiYMGnRIpQek15jvqyoZ NVFlj/KyG8+QO8y76eAkKzuP+hxVXN5ZW/VrlhcI6NJb6ogzfQ042aV/lqlnhX86hVK6 gVz63skZP74T+SL3O02hUyyS9iNnemYXHjeibTTJkU1erc0JP1AIQdt9q5cBrlBw0Z6F 6BiQC1HzGB2kxm5CFzQE7Fh3f8Y4ZwtU1sBVDQO4FQhUluMq7AeeE887UrIFEMr2tDp+ vHBg==
X-Gm-Message-State: AOJu0YzZl1mwbWtPW9sUl0GXHcQVjnIBs22gJFCpZ5jT4d0tDcbKBwAy TRLT44Ve15zjhp4jxx3JsJhGjW0jgrDatr4Cnvee/qaWelcRGJpr3250ViML7JUqegvm5eH+J2+ GKFem3rTh6OvVYIsxTr798gPWNl7uj6/7YiY=
X-Google-Smtp-Source: AGHT+IGPkatZX/3/01iezZ+pr8qprGrklXithf5BbFPQS1VJT9vWIA8/kzYfD6XCqHS3qHHiKtwh/zxeJqZjcIYOAhs=
X-Received: by 2002:a2e:b753:0:b0:2d3:56df:ea46 with SMTP id k19-20020a2eb753000000b002d356dfea46mr1812983ljo.31.1709689106590; Tue, 05 Mar 2024 17:38:26 -0800 (PST)
MIME-Version: 1.0
From: Deirdre Connolly <durumcrustulum@gmail.com>
Date: Tue, 05 Mar 2024 20:37:50 -0500
Message-ID: <CAFR824ywNTnWPstZsrW7S9PYH+thW9-9f2yP0j_SC_eenS3k7A@mail.gmail.com>
To: "TLS@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dff59f0612f40314"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RupKEHeJdAzxpNEZnRgerk4en1c>
Subject: [TLS] Proposal: a TLS formal analysis triage panel
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2024 01:38:30 -0000
A few weeks ago, we ran a WGLC on 8773bis, but it basically came up blocked because of a lack of formal analysis of the proposed changes. The working group seems to be in general agreement that any changes to TLS 1.3 should not degrade or violate the existing formal analyses and proven security properties of the protocol whenever possible. Since we are no longer in active development of a new version of TLS, we don't necessarily have the same eyes of researchers and experts in formal analysis looking at new changes, so we have to adapt. I have mentioned these issues to several experts who have analyzed TLS (in total or part) in the past and have gotten tentative buy-in from more than one for something like a 'formal analysis triage panel': a rotating group of researchers, formal analysis experts, etc, who have volunteered to give 1) a preliminary triage of proposed changes to TLS 1.3¹ and _whether_ they could do with an updated or new formal analysis, and 2) an estimate of the scope of work such an analysis would entail. Such details would be brought back to the working group for discussion about whether the proposed changes merit the recommended analysis or not (e.g., a small, nice-to-have change may actually entail a fundamentally new security model change, whereas a large change may not deviate significantly from prior analysis and be 'cheap' to do). If the working group agrees to proceed, the formal analysis triage panel consults on farming out the meat of the analysis work (either to their teams or to students they supervise, etc.).\ Group membership can be refreshed on a regular schedule or on an as-needed basis. Hopefully the lure of 'free' research questions will be enticing. The goal is to maintain the high degree of cryptographic assurance in TLS 1.3 as it evolves as one of the world's most-used cryptographic protocols. I would like to hear thoughts on this idea from the group and if we would like to put it on the agenda for 119. Cheers, Deirdre ¹ 1.3 has the most robust analysis; we'll see about other versions ---------- Forwarded message --------- From: Joseph Salowey <joe@salowey.net> Date: Tue, Jan 23, 2024 at 10:51 AM Subject: [TLS] Completion of Update Call for RFC 8773bis To: <tls@ietf.org> <tls@ietf.org> The working group last call for RFC8773bis has completed (draft-ietf-tls-8773bis). There was general support for moving the document forward and upgrading its status. However, several working group participants raised the concern that formal analysis has not been conducted on this modification to the TLS protocol. We should at least have consensus on whether this document has the required analysis before upgrading it, but we also need a more general statement on this requirement since the TLS working group currently does not have a policy for what does and does not need formal analysis or what constitutes proper formal analysis. The chairs are working on a proposal for handling situations like this that we plan to post to the list in a week or so. Thanks, Joe, Deirdre, and Sean
- [TLS] Proposal: a TLS formal analysis triage panel Deirdre Connolly
- Re: [TLS] Proposal: a TLS formal analysis triage … David Schinazi
- Re: [TLS] Proposal: a TLS formal analysis triage … Deirdre Connolly
- Re: [TLS] Proposal: a TLS formal analysis triage … Jonathan Hoyland
- Re: [TLS] Proposal: a TLS formal analysis triage … Muhammad Usama Sardar
- Re: [TLS] Proposal: a TLS formal analysis triage … Deirdre Connolly
- Re: [TLS] Proposal: a TLS formal analysis triage … Muhammad Usama Sardar
- Re: [TLS] Proposal: a TLS formal analysis triage … Marc Petit-Huguenin
- Re: [TLS] [Ufmrg] Proposal: a TLS formal analysis… Bas Spitters