[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)

Eric Rescorla <ekr@rtfm.com> Thu, 27 November 2025 22:38 UTC

Return-Path: <ekr@rtfm.com>
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 D3F4891D89D4 for <tls@mail2.ietf.org>; Thu, 27 Nov 2025 14:38:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 RP54KePE2sxG for <tls@mail2.ietf.org>; Thu, 27 Nov 2025 14:38:00 -0800 (PST)
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (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 39EDD91D89CD for <tls@ietf.org>; Thu, 27 Nov 2025 14:38:00 -0800 (PST)
Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-787da30c50fso12416597b3.3 for <tls@ietf.org>; Thu, 27 Nov 2025 14:38:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20230601.gappssmtp.com; s=20230601; t=1764283074; x=1764887874; 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=g9o2Kk05vWZiGVcKT7dSr84eW15dFkSmVUC29aIaeAQ=; b=WndwK/FppKP4fARy/V+LOiLxbFAjOMsTZYreD7nAZ4Mzitpy6iRp0yRkqC4ji9Izfu LqpNAukodZVul0cgOix+ESzlsnJOicQCxIEcJsWLrciatqM21b00ACaOOb88Er4hIZdn SSWM5qOX7j1ho6Eh2ngeUKTV2NdABy9/Q0HllmUMqbsVr3io2UoyqC8Owq7p1zXJzPog 3TabeB6TKG0rOcPueNgXV7EMsoekOcuYsaI3Ddeg+uTVym+dPQPMIsxbZhWWoqKApj4V dgjoOWbOHdgaS5UV5tU5L6FNr6yc2R4Kp2BPuZsCvTuhPzVtOsN1WWRxszftGtLv3MpA ESWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764283074; x=1764887874; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=g9o2Kk05vWZiGVcKT7dSr84eW15dFkSmVUC29aIaeAQ=; b=tDKixt4co8g2WVpmiig1fkc8NV5GAHyAvZqVKQ9FRqFucA/qipjavJiDPdLJ6JP+zN WgJvliSlAnYogFiJDapfIODxOH459tHdHgDEDU33YIKVI02AKwHZE+9EbJ59yox95U3w A/KKgNOuXOB2T6+gWtIe9koZoKm/HKH/NsoYIlzN4RazXsWjZXWZFs99wmUhgOkUQQiU pMW3RiYXVEDX8nMupwd2CPS/besht8wgPrndKa8aHl/PpQDVVBZyeRpqqaLpaNuLrvpD dwE9PqgBRSiR/hXVJsVxVXUOdhBaQJ5d5xA2qkOqlGbix1l82oJO+7HUky63xzIWJRyJ 9HVw==
X-Gm-Message-State: AOJu0Yw9+65L2d3betHjJw/7xF3kqAYaZsQNZR/Gddwl8b4uw3Y9/pvu LxG2A0hJaeQJpHFGxudDzrfjSp/5gn2NuIlksE3Rhj4QWYs86OAf51a3KSnCDitATPsiHtWicDu TMvDB47wwUVF6pF7Nx926/ME7V5ZlCqfbt7BACEuDmfZcXarzi0cu
X-Gm-Gg: ASbGncujzdgG+c9VN5FpZhqMYymlBIbZtiNRoPdosHw00kCq7oyZdtGkK1Si2aaa2Wr DAtUpvMfFjSF/0ERpD+uqQ4c6maiGhyVVzjRHuwzm87kLp5VhuxQfnM6lJYnZq8+mAUv3HWhHZ/ hZdjFCg5g8736xl1FZK2QwLuLtLXj1xtU2qLGxQLXPyBOkrQKiEuAdU/qugwp65Q1vPHqUrlvh0 3XEi5dO/HvilCHMyEmjK3ItVLnAsRqTr0eVZyfMcbHXxIPZASZVuc7gMvHmfH6QeHYV+LLIMAAk bfpYPFh0GWU/q1SmUblkSCRuHbr3kmJNZtzp59uQORISeIKVsTk9M8UpOf/Gh261Dd+1KWORyfX aiLVfpZhwwA==
X-Google-Smtp-Source: AGHT+IGfyHbBMIGyIkUO2DCZudngWGDh31OfcVIvwQXo1gwq98S0fe8ZnPuLIcPv+3vUc/AJS0Q6ndTtVkzNqvhDB/8=
X-Received: by 2002:a05:690c:6d8b:b0:786:5926:ed9e with SMTP id 00721157ae682-78ab6df9982mr207683967b3.25.1764283073736; Thu, 27 Nov 2025 14:37:53 -0800 (PST)
MIME-Version: 1.0
References: <9c237f425c0b1ebccf099c47a8badfcf41eb2ef0.camel@aisec.fraunhofer.de> <20251127194517.439400.qmail@cr.yp.to> <CABcZeBNNsGEKSMcAyfnTyxCZLXxsBZT-u0adtn+5KyPMKm8wNw@mail.gmail.com> <4e3283a6-b4c1-43d1-b956-7905783db82b@tu-dresden.de>
In-Reply-To: <4e3283a6-b4c1-43d1-b956-7905783db82b@tu-dresden.de>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Nov 2025 14:37:17 -0800
X-Gm-Features: AWmQ_bk05Kt3epjnE721w9Fa84oKZRPyAQAFMCEiBCiMe2m3tDytRX45KR7Lvl8
Message-ID: <CABcZeBO_HkFkN2UNOYV=WcAo9W3Co__Oyx3_vsFe=rh_qz6FQg@mail.gmail.com>
To: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
Content-Type: multipart/alternative; boundary="000000000000e4bcfd06449b295a"
Message-ID-Hash: 7JPS5ZIZONICTQ53FMDBRNIAM3ZNAIQZ
X-Message-ID-Hash: 7JPS5ZIZONICTQ53FMDBRNIAM3ZNAIQZ
X-MailFrom: ekr@rtfm.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: tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2025-11-26)
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/AF0PB_om3sYiTCJpofFDxw5l7NE>
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>

On Thu, Nov 27, 2025 at 2:14 PM Muhammad Usama Sardar <
muhammad_usama.sardar@tu-dresden.de> wrote:

>
> Two concrete questions:
>
>    1. (trying to phrase my *authority* question more precisely) Is IETF
>    the *only* body to define "application profile standard"? or do other
>    SDOs count as "application profile standard" as well?
>
> TBH, I think this is an undecided question. I think it's reasonably clear
that IETF Standards Track documents are in scope here, but IMO there
is at least a reasonable argument that standards from other SDO
would also apply. I don't recall this ever coming up, so I think people
are kind of left to interpret the text for themselves. If there was a need
for an authoritative statement from the IETF, I think we'd need to do
some kind of IETF consensus process, to, for instance, issue a liaison
statement (though see below).


>
>    1. Does it necessarily have to be standard track document?
>
> I think the term "standard" here strongly suggests that the document
has to be Standards Track.

It's not clear to me what the practical impact of any of this really is.
The IETF doesn't have protocol police and won't do anything to you
if you violate some IETF standard. Sometimes those standards are
part of purchasing decisions and the like, but presumably if you
are buying an implementation of protocol X and X uses TLS but
overrides the TLS MTI, then you expect the behavior specified in
X, whether the resulting implementation violates the TLS spec or not.

-Ekr