Return-Path: X-Original-To: cfrg@mail2.ietf.org Delivered-To: cfrg@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C92467E3AD9E for ; Wed, 29 Oct 2025 11:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 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_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vUTUpbsn1vXG for ; Wed, 29 Oct 2025 11:10:09 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 697E77E3AD93 for ; Wed, 29 Oct 2025 11:10:09 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id ca18e2360f4ac-945a51050b2so6492539f.0 for ; Wed, 29 Oct 2025 11:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761761409; x=1762366209; darn=irtf.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=rwetimDO9wAJRTz/2QTpipM0eQ/9ZbL7y6gGKIwkNho=; b=joD768AxvIdYfMtaVLCdfTFt0Dy1V0NfnH/nWjInqIyx8JIYKAKtepAVfrVhik05PP Inp82ceSpHralN1mKdwhPqu8d1nbOu6AtZWQukeduoHlpxh3Zp3dO8h95gJV2l/tRHD4 ycaws2LiViRbPemvX0+BPxZ6snJQg1sisLpBKcC4Kn0uP8HxhPiPFahbQK2vu2F205pn obPXu30jD6Izcl9yn5/uwqWF/uffXfNk/n9IROiddU89/6Q36aoe6mIjlVabDOKieBPQ PVKEROn1zZdUkaDxxXb+4XbeUdXvg5+NglZl/GjaitguFgNM7gAgDZzdfzTCYhMdyN9S dzAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761761409; x=1762366209; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rwetimDO9wAJRTz/2QTpipM0eQ/9ZbL7y6gGKIwkNho=; b=q0hJsmfGsocfidlyri77YtQqzhAbjIDeiYki9TYTcmtB9aQ2uVaKelbsQ1ZdK8xhjf tep8Zs4HfPKNT/S5E0RGImajrlmMEXTDkjhQ8cXjdWk2n/DRNG3A+qqYl1NwTMTNU0i1 Bg43nm0b3DTNyKAHqdLPR84xVGWXcY3/sd3sIKBgSv0fbVTymrz/HUU4tnOGBrXZ/xc3 6NZx8YimaxhHUFn5FUHDVijGdg/8TIEVo6Z1qVJHC8dUqYExq9M3CFHiLyGZJpBh98Du dFaA1syVKLmTapHZ5/9hkf2xWtJFtf1FRRy2r84EedZXlV0X7CyKHodhD82X4FpkI85R Zv+Q== X-Forwarded-Encrypted: i=1; AJvYcCXVN7SdEv/gBrb++WIPdruxb0SUYgTwQZPJrJG2YYRgI1IOngwqaNoa+Zl9bEpCRr8FcY9Q@irtf.org X-Gm-Message-State: AOJu0YxwjnvLioALVEVUm+SMHiq/fjySK8gVbFAxKyqI5vnj+8C3XyfP SAa8iJXtN08f9tBApwjiHKdA3/UCj0uJIRaMF7TQb6C/IsNAiaOuz1D7b84b30Y7tkgDTj5n89Z gQioaE8QJXvofLspb26bmM/8nRvHf4/o= X-Gm-Gg: ASbGncsx7XfrE4MztD+C5psWQj/ggFKaMdT40x4wJuFAAgS8UIFhzFInW5rITflrYAO pHvHqSdEIaotul6zv3mKYuWM4bU4ZHVQNWNGSHs93nHfa56gC9F/YanYJj5cfXASq7BRXTEKDy8 tuewiSwLyQ+ft4789+T7AiZyc6s3i2R9NGPsQSzzeEVwhTUvjuowb4yhFllKOhe78XAMLqO4xl5 iaWyxxAvPjm+/P9uHsHJtre2CPfX5u0gLzPgIDfW/xTVesS8fKvnZKV/Jw7ik4RiFh8vGwthA== X-Google-Smtp-Source: AGHT+IEjAY5PmVqdCb3agFuqOcmQlCrBl/nU6PuCasGko5Meyb1fT428iMovQ7niPKHMlJgIDiaDsRUUYhNYQv/+Akg= X-Received: by 2002:a05:6e02:180e:b0:430:c857:734e with SMTP id e9e14a558f8ab-43301219ac2mr8454455ab.10.1761761408575; Wed, 29 Oct 2025 11:10:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mike Ounsworth Date: Wed, 29 Oct 2025 13:09:56 -0500 X-Gm-Features: AWmQ_bmg-xkfAZcAPorkS2a447hZRaJ-2tKuHvbYxO30qi-HUZrHm_99VXTI6hk Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary="000000000000efecc00642500a94" Message-ID-Hash: 5HQHPZJMX4JFKEJ42XRSI25PAQ5AXIWW X-Message-ID-Hash: 5HQHPZJMX4JFKEJ42XRSI25PAQ5AXIWW X-MailFrom: ounsworth@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; header-match-cfrg.irtf.org-1; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: LAMPS WG , CFRG , hpke@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_New_labels_in_draft-irtf-cfrg-concrete-hybrid-kem?= =?utf-8?q?s-01?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000efecc00642500a94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As as pointed out by Daniel Van Geest in another thread, the label for MLKEM1024-P384 is supposed to be " | /-\", but in the published version of the cfrg draft (both HTML and TXT), it displays as ` | /-` (note the missing backslash). So that means that the kramdown2rfc tooling is not handling this properly. So when I said "This is GOING to lead to at least incompatibilities if not CVEs" I didn't realize that we already had one in the draft. The point is this: The LAMPS doc is already in WGLC (months later than we wanted), using the labels from YOUR -00 (minus the SHAKE256 component). I made that change in consultation with you guys as part of the CRFC Interim in Sept. Your doc is not in WGLC yet, so can you please change your labels to match? On Wed, 29 Oct 2025 at 12:47, Eric Rescorla wrote: > I can't speak for what has or has not happened in terms of interop, but o= n > the > substance of the labels I agree with Mike. I strongly prefer simple > human-readable > labels to ASCII art Star Wars references, no matter how clever those > references > might be. > > -Ekr > > On Wed, Oct 29, 2025 at 10:36=E2=80=AFAM Mike Ounsworth > wrote: > >> draft-irtf-cfrg-concrete-hybrid-kems-01 publish on Oct 20 and made the >> following label changes: >> >> >> "QSF-P256-MLKEM768-SHAKE256-SHA3256" --> "|-()-|" >> "QSF-P384-MLKEM1024-SHAKE256-SHA3256" --> " | /-" >> >> >> Please tell me this is a joke. Then please remove this from the draft an= d >> put the labels back to sane alphanumeric. I'm sorry for strong language >> below, but this makes me mad. >> >> I have been bending over backwards to make the LAMPS thing match the HPK= E >> thing, including multiple rounds of interop-testing against your test >> vectors and changing the LAMPS draft, reference impl, and test vectors t= o >> match yours. This has resulted in delayed publication of the LAMPS draft= by >> several months to accommodate interop with the HPKE draft. The LAMPS >> Composite-KEM doc went into WGLC on Oct 17 now using HPKE-style labels o= f >> the form "QSF-MLKEM768-P256-SHA3256" that we pulled FROM YOUR DRAFT inst= ead >> of the OID-based labels we had before. Then on Oct 20 you publish a new >> version that goes and changes the labels to this nonsense. Can you guys >> please at least pretend like you care about interop between these two do= cs? >> >> My specific objections to more ASCII art labels: >> >> 1. We're already having interop problems at the PQC hackathon group >> because of the backslash in the xwing label -- for example, in python yo= u >> have to put the constant in your source code as "\\.//^\\" to prevent it >> from interpreting that as an escaped dot and double-quote. We've also ha= d >> similar problems representing this label properly in HTML and markdown >> docs. Now you want more labels that have both backslashes and now spaces= . >> This is GOING to lead to at least incompatibilities if not CVEs. >> >> 2. The label is not human-readable; it doesn't tell my anything useful >> about the content, nor will it be easy to debug mistakes in source code = or >> config files. At this point, assigning a numeric codepoint would be >> preferable. >> >> 3. This does not establish a naming convention that is easily extensible >> to other hybrid combinations. >> >> I have been doing everything in my power to work behind the scenes to ge= t >> interop between these two documents, and it feels like you guys are doin= g >> everything in your power to obstruct it. >> >> Can you please put your labels back so that they match the LAMPS draft >> using the pattern "QSF-MLKEM768-P256-SHA3256". >> >> (PS this is a re-send from the correct email address) >> >> -Mike >> _______________________________________________ >> CFRG mailing list -- cfrg@irtf.org >> To unsubscribe send an email to cfrg-leave@irtf.org >> > --000000000000efecc00642500a94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As as pointed out by Daniel Van Geest in another thre= ad, the label for=C2=A0MLKEM1024-P384 is supposed to be " | /-\",= but in the published version of the cfrg draft (both HTML and TXT), it dis= plays as=C2=A0` | /-` (note the missing backslash). So that means that the = kramdown2rfc tooling is not handling this properly.

So when I said "This is GOING to lead to at least incompatibilities = if not CVEs" I didn't realize that we already had one in the draft= .

The point is this:
The LAMPS doc is al= ready in WGLC (months later than we wanted), using the labels from YOUR -00= (minus the SHAKE256 component). I made that change in consultation with yo= u guys as part of the CRFC Interim in Sept. Your doc is not in WGLC yet, so= can you please change your labels to match?

On Wed, 29 Oct 2025 at 12= :47, Eric Rescorla <ek= r@rtfm.com> wrote:
I can't speak=C2=A0for what has or has= not happened in terms of interop, but on the
substance of the la= bels I agree with Mike. I strongly prefer simple human-readable
l= abels to ASCII art Star Wars references, no matter how clever those referen= ces
might be.

-Ekr

On Wed, Oct 29, = 2025 at 10:36=E2=80=AFAM Mike Ounsworth <ounsworth+ietf@gmail.com> wrote:
<= div>draft-irtf-cfrg-concrete-hybrid-kems-01 publish on Oct 20 and made the = following label changes:


"QSF-= P256-MLKEM768-SHAKE256-SHA3256" -->=C2=A0 "|-()-|"
<= div>"QSF-P384-MLKEM1024-SHAKE256-SHA3256" --> " | /-"= ;


Please tell me this is a joke. Then please remove this from the draft and put=20 the labels back to sane alphanumeric. I'm sorry for strong language=20 below, but this makes me mad.

I have been bending over backwards=20 to make the LAMPS thing match the HPKE thing, including multiple rounds=20 of interop-testing against your test vectors and changing the LAMPS=20 draft, reference impl, and test vectors to match yours. This has=20 resulted in delayed publication of the LAMPS draft by several months to=20 accommodate interop with the HPKE draft. The LAMPS Composite-KEM doc=20 went into WGLC on Oct 17 now using HPKE-style labels of the form=20 "QSF-MLKEM768-P256-SHA3256" that we pulled FROM YOUR DRAFT instea= d of=20 the OID-based labels we had before. Then on Oct 20 you publish a new=20 version that goes and changes the labels to this nonsense. Can you guys=20 please at least pretend like you care about interop between these two=20 docs?

My specific objections to more ASCII art labels:

1.=20 We're already having interop problems at the PQC hackathon group becaus= e of the backslash in the xwing label -- for example, in python you have=20 to put the constant in your source code as "\\.//^\\" to prevent = it from interpreting that as an escaped dot and double-quote. We've also had= =20 similar problems representing this label properly in HTML and markdown=20 docs. Now you want more labels that have both backslashes and now=20 spaces. This is GOING to lead to at least incompatibilities if not CVEs.
2. The label is not human-readable; it doesn't tell my anything=C2=A0usef= ul=20 about the content, nor will it be easy to debug mistakes in source code=20 or config files. At this point, assigning a numeric codepoint would be=20 preferable.

3. This does not establish a naming convention that is e= asily extensible to other hybrid combinations.

I have been doing everything in my power to work behind the scenes to get interop between these two documents, and it feels like you guys are=20 doing everything in your power to obstruct it.

Can you please= put your labels back so that they match the LAMPS draft using the pattern = "QSF-MLKEM768-P256-SHA3256".

(PS this is a re-send from the correct email address)

-Mike
_______________________________________________
CFRG mailing list -- cfr= g@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
--000000000000efecc00642500a94--