IETF Logo Mail Archive

[TLS] Clarification on the FATT Process

Joseph Salowey <joe@salowey.net> Sat, 28 February 2026 01:04 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id A38C6C016D0E for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 17:04:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20230601.gappssmtp.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V68UtreISpEE for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 17:04:10 -0800 (PST)
Received: from mail-dy1-x132e.google.com (mail-dy1-x132e.google.com [IPv6:2607:f8b0:4864:20::132e]) (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 mail2.ietf.org (Postfix) with ESMTPS id EDD34C016CE3 for <tls@ietf.org>; Fri, 27 Feb 2026 17:04:10 -0800 (PST)
Received: by mail-dy1-x132e.google.com with SMTP id 5a478bee46e88-2bdbe434b47so5813226eec.1 for <tls@ietf.org>; Fri, 27 Feb 2026 17:04:10 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1772240644; cv=none; d=google.com; s=arc-20240605; b=avZgI7COrqlcl6noXrXtT/aqf+ddztpwqOBpv7U8KVw5/FxYnHdLsVVb4YRb+AhdND HUCp+pN5bnw2IhDk3MwHB+0GcNcE4w/YdddUCvZ7Dus5ILgv2oI0O7zfP3YC216zL0P0 /3ls0r+x/DbeC/xYpxlU+bg6o69sr3wUmZ5LlI/NjX6VsoiylwVoK0wIGzTV7oXBdnoD pdqzBBoE+a/JzQxpOpf78G7rW+ejxdF8dZAQBiLFfYZ/Sse1BzLQVqKzE5iCd2jp1Mw/ YQswGQUgsXJicoyOkvrMyWQKI4PtVmBu+JeTlpvHbIfAx5iQD3qssGYsySbabbhb2fDe PRcA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=tVlmth0r7DwhH20C3FIH8wKyUCyn55+B9rR7OCxkjzE=; fh=6dNaabedNczh5TXKCP3vnXRLFdmtidwzU4uB2XwvFYI=; b=aRCksrRDQ5nV7pnVMivslrFdL0VmIVot09rP/r3Ry1a8ts/T/yVqCA2SoBUbC3NxSd jTTUC9KdGZaIiCf7RgeCZF/WQyxmF/bCzp0qnyJOzp9Sn1qsIlcjP8ip6jOutcPm53st 4ZLTc4mlVSFJTiOGkAs6MEkDl6x5xpF61ih/Txa3Dsn+ouxIiZSu/EHHZdZdCfZkDD2k K8xEPpwrz4Us1lzJ55HAVaqfXfnFpSIFE1XIO8Z06+o/bpLPd/2GZEQTOznfpWRudtBC eE52gdovK76Xhr4pYc+zgOqUZVTK3OE2ea9Bse1Lest5XVDB/NN9L0y02Jm4r58E5i/w wFKQ==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20230601.gappssmtp.com; s=20230601; t=1772240644; x=1772845444; darn=ietf.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=tVlmth0r7DwhH20C3FIH8wKyUCyn55+B9rR7OCxkjzE=; b=eelaKaeaHhAgkEi29b8lCVjzhM31DjEdeBoicS7mQqpQTjEWQc7ddZNxJVca/eY4Zw n5h/F18hXrEtk6VcPab452NYuh948dLuoEIj/SPZIzVnKqrbFejpWB3jynazNvzNnz24 enUnNg3ZzgCcwIFn4tBEgAu280xiyPzAZUaEKX8D06J491v7dL8e2NsPLNBivWF/qOLJ 2+NNGVviT3cBe/b6bSZfy9F5a4576sZM3dicDKehNAILqyPDvknD3gu8Ny8+iyhmbjpw juXoZj5w4wI3MrI5Z8YdZ3ZtWObeemxNHgGYUXyN5h/b9+dts3Gsrk1gIAWH3x71KgWc 5gKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772240644; x=1772845444; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tVlmth0r7DwhH20C3FIH8wKyUCyn55+B9rR7OCxkjzE=; b=oKNiQ4Fjiqz/aQL4boFIzQooQrfLNN+DictV3EOVXU0XedGavbc4mWJNW40zMxKMks W9KO+JYsIziP9Lh139ujfqzEyG7JL2XH55bRX3kzmud0BpfE8P2eAXyLUtaXApFT8e/R cLOQ2Ih8rEwtb5MTE4HCCfcekPc0APb27gOPUZmq/xnnjCSc+3TX6y/oiBxgJ7M1DEd5 qJwGQtN50TIlClyZJHovCCRfuv7qWEF6q4QNeKU+zu8YZ7/H9OMpgcq8uo/jNtWAc3Th aQGlGko/s+747+FJXY/YJhj65hHU/bmhsdcb8am4srS58ejIAmPt5wC+yjwBzIaKL6fS Kx4Q==
X-Gm-Message-State: AOJu0YyoEuyctdvEMLKXEtrCXHaJDjX8d4WGbA9dmWtBskC1uGm0aG3E 6buL3sw1U6fZ/M2x9VXBMzlJs4ivb/azgmMPlyxc3PwRtk6ElUO6j+AnT2osGmymF8rQ/N1k6qK q8Vx+24sr9cwRuPhrCxoBiq/QKjfSuGJt95b2YMTwEGn5k6SpABFC/sI=
X-Gm-Gg: ATEYQzzCbvE4jaec/SB4ZoOYB6So5maVJ8m4GZYSoSJsw0+zMusEG5Mdy6ESZt5Dlg8 T02hFBjDwUobjNK3THxQAuwaE7NoWQIXfiqSv109xSul/OOId8DlienDdllH8Kye8rBKl+oPfhE B1IKYJoUeAlo6s6j2QKx7kEeb8MJ+A9Y95wyZVlE5Pp/HOn3N0xk65MqpoasD4wFFJPpML/Luug V2cyynAF4BVaHMd6OE4QVnWN0GZSKKQy+VxuddMAjxfmO9Y6Pr2QiOmTiF71GWsmspZFYUzcYsR 0p9NbCU=
X-Received: by 2002:a05:7300:3b24:b0:2ba:8543:c91a with SMTP id 5a478bee46e88-2bde1b36a62mr2052032eec.2.1772240643847; Fri, 27 Feb 2026 17:04:03 -0800 (PST)
MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Fri, 27 Feb 2026 17:03:52 -0800
X-Gm-Features: AaiRm53qH-yteuQWJYurHfP1zU-MOgLdIcnp7uhpOpmRxShRrMa-nzQFwBZj9pQ
Message-ID: <CAOgPGoC_J5js5DNfQNm0yNr=D+U8BJiL+CO4wdD3btYgZJUgXw@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000008861c064bd7ee62"
Message-ID-Hash: JZKWAB5U5WWMCI7YYWRC3JNH6TOIVPEM
X-Message-ID-Hash: JZKWAB5U5WWMCI7YYWRC3JNH6TOIVPEM
X-MailFrom: joe@salowey.net
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.9rc6
Precedence: list
Subject: [TLS] Clarification on the FATT Process
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/L2bWqpT3q8HVmACwD1Ta3NFimw0>
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>

In the FATT process, working group chairs decide at the time of adoption
whether a document needs FATT review.

>From https://github.com/tlswg/tls-fatt:

"When a document is adopted by the working group the chairs will make a
determination whether the change proposed by the document requires review
by the FATT to determine if formal protocol analysis is necessary for the
change. For example a proposal that modifies the TLS key schedule or the
authentication process or any other part of the cryptographic protocol that
has been formally modeled and analyzed in the past would likely result in
asking the FATT, whereas a change such as modifying the SSLKEYLOG format
would not. The working group chairs will inform the working group of this
decision."

The chairs made this decision because the mechanism in this draft fits into
a well defined place in the TLS protocol and does not change the protocol
itself. The purpose of the FATT is to evaluate the potential security
impact of a change in the protocol, not to evaluate the merits of a
specific cryptographic algorithm such as ML-KEM. Unfortunately, the chairs
did not announce this decision on the list (this is something that should
be corrected in the process)

This decision is supported by references from Thom Wiggers and others on
the list that identify the security properties required by TLS 1.3 key
exchange.

The ML-KEM draft does not modify the TLS key schedule or protocol messages
in any way other than what is anticipated by RFC 8446/8446bis. RFC8446bis
explicitly defines key reuse as a SHOULD NOT.

The considerations applied also for ecdhe-mlkem, which has already gone
through the WG process and also did not undergo FATT review.

Joe

v2.39.1 | Report a Bug | By Email | System Status