[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