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 5D7547E6265A for ; Wed, 29 Oct 2025 13:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 XkeMfw7gUeIY for ; Wed, 29 Oct 2025 13:52:27 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 ECBFF7E61C27 for ; Wed, 29 Oct 2025 13:51:44 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-471191ac79dso3068855e9.3 for ; Wed, 29 Oct 2025 13:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1761771098; x=1762375898; 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=YS/6PbKU0tQHUJQJ9j7BO8p9j1e0nSDkr4HgtJv7w5Y=; b=V/C9pu/FjLzNyISNpPebpdz8eNs4lgpmFEDmuFIBUZX29MlQYnnJcb/DRwYR6v+WQ4 dzfAvRWUpkjSShuo29Qzm5CL/AIQMnjVJM9v/qA4ThddJJ8jmUVQTnaAr29WmLyOmbUN exTwf8bYtFfhJeCT4gM5vM0vKmb+4a53wO6sKFFaGot6gjXtRnQA/ffEHXzcprOSxAX9 riUFbx4+rvfSsuP6vpeZ+EIPMkUu+PadEoq+2wWqI4oQWXQKhR9qimfdo/Ku2VaRMoOR +E+1z6+4F+aR534Y6zpPEz/7mrmLEbKrj9PAvcQHiRxf0HV/i9U9Xhxd0GXGnwZEq5/b X4Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1761771098; x=1762375898; 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=YS/6PbKU0tQHUJQJ9j7BO8p9j1e0nSDkr4HgtJv7w5Y=; b=IhOiotPDAXZ6LhV3LP+KR49ozsb2cYPYyeBR2VEA++I5LZVFDW6QhZpK9uTlD7CyRY 5p95mqBQNNJHt0Bx4u1rdUMnWfrK2FBktC0zTUtNyBxZV5nM6+peiY5W5r37GPKN64ea G3hL2LytPwXRTCyyHfLHEnsa2TbgmSSd+Jf0+pxJxYb22ZP5wkZQvB9bH6Q44JJtA+DH 3nvF781U6Bu6GzqyCqA6M6xPDyxjAgkF3LyZC6DQBUZcQS0sAGrowV3vWjepJvmWYdWU lAwgVvpQePsXdUhDSnR1E8NWlrDWAlFJcoNYZk1uHcU5TSuIA+YEUTzTfVSTdBuM3jsM s81A== X-Forwarded-Encrypted: i=1; AJvYcCVK2++J+6B/aDPYV1UofvAJVcZzN3j8I7dJU7s+XKMhRlnWSXwr5/O3HdHLBuuCovhBbl69@irtf.org X-Gm-Message-State: AOJu0YwThwysVLc1eloGL+lUKNfs0YJQdWIdexVF5grY0JqbNop//2iv 9T4XILxPkInQVXl/xu4rgE0jnAjARKGpDpmzs1GRJeWu2P19IoDwVmfzHOfHB1P3pxOCglSs3ln NgVbNDMJtwGbsfDBwtq7uCwR/et2BvBQ= X-Gm-Gg: ASbGncvpiwC0kmVs1EijbO/o6jbB/nnpS9MBpDuoZKsclA4NxAme6FLP8hdKTEmGbsc cyGAZD48o+u1XQeQMSBNLnIkFmRF6FxsnKNg3P4LI98mcatzOMYvNiL81dylRt0jkym+jpcIglb Ldt7SClZwLyOQLviW44vB6Dqkz50w8FQzZwAMF8nQQ2v3ozgWS0DMwl9wgVo4u7v0MUdk0FR4oX e5HiQbrydp8AOj2RD9ErLdBMeVKxbbmMty3+Luh48E1VrHNNGTPTf0rLzNiOUdyAESvy8T9HPj6 cUIkH8EpfJ34YmrJ07g4VV5dbgSzjuEgO8BISUxarhjiOll6OsPDCqLTfpo= X-Google-Smtp-Source: AGHT+IEFCvSsj91yJpJbAHV9vQq2LQrE/FGZdv4IdmiV1+RaIP7/IMgaeUbD9XgyQDDGexQETzrNyDFDL/IKsSjVRUg= X-Received: by 2002:a05:6000:2406:b0:427:45f:ee21 with SMTP id ffacd0b85a97d-429aef950d3mr4109766f8f.27.1761771097603; Wed, 29 Oct 2025 13:51:37 -0700 (PDT) MIME-Version: 1.0 References: <2D85ACB8-26D1-4E42-B4BE-DD5CD9BDE33A@nps.edu> In-Reply-To: From: Watson Ladd Date: Wed, 29 Oct 2025 13:51:28 -0700 X-Gm-Features: AWmQ_bl9IxEuRA7JoiVGz19LZu5GMlpIRvit1qNZE4kUI2Sn65FsynlPgMwhlgQ Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary="00000000000072c2c60642524cd6" Message-ID-Hash: HBPKIXSOUUWAM6AXODOZ4HKYPSPJRWHJ X-Message-ID-Hash: HBPKIXSOUUWAM6AXODOZ4HKYPSPJRWHJ X-MailFrom: watsonbladd@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: "Hale, Britta (CIV)" , LAMPS WG , CFRG , hpke@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_=5Bhpke=5D_Re=3A_Re=3A_New_labels_in_draft-irtf-c?= =?utf-8?q?frg-concrete-hybrid-kems-01?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000072c2c60642524cd6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If LAMPS wants to interop why defining things differently at all vs by reference? This whole thing seems silly to me. On Wed, Oct 29, 2025, 1:44=E2=80=AFPM Eric Rescorla wrote: > Following up to myself.... I'm also fine with the LAMPS strings. > > -Ekr > > > On Wed, Oct 29, 2025 at 1:27=E2=80=AFPM Eric Rescorla wrot= e: > >> I would make a few points here: >> >> I don't have a strong opinion on whether we ought to have structured >> strings or just 6-byte constants but ISTM that having the spec contain >> strings which contain special characters are a clear safety hazard, and = the >> only motivation for them seems to be to make a Star Wars joke, which rea= lly >> doesn't seem like a priority for the RG. That seems more like a bug than= a >> feature to me. With that said, while the X-wing label is unfortunate, I >> don't think anyone is proposing to change it, but no such considerations >> exist for the other value. To that end, I propose the following: >> >> - Render the labels only as hex values. >> - Replace the non-X-wing labels with values which don't happen to >> correspond to escape characters. The obvious thing to do here is just to >> use a simple counter, so we can use (x00...00 and 0x00..02) but I could >> imagine other approaches. >> >> The net effect of these is to slightly reduce the surface area for error= s >> without creating an interop problem or arguments about the semantics of = the >> strings. >> >> Finally, I would observe that arguments of the form "we need to get >> things out now so we need to do things the way I prefer" are less >> persuasive than "we need to get this now so I'm prepared to do things a = way >> I don't really like". >> >> -Ekr >> >> >> >> On Wed, Oct 29, 2025 at 1:11=E2=80=AFPM Sophie Schmieg >> wrote: >> >>> The labels are simple numeric codepoints: >>> 0x7C2D28292D7C for X-Wing >>> 0x5C2E2F2F5E5C for P256-ML-KEM1024 >>> 0x207C202F2D5C for P384-ML-KEM1024 >>> in little endian. >>> And yes, I concur with Filippo, we need to be able to ship without bein= g >>> held up by discussions on naming things, and simple numerical values li= ke >>> the ones above allow us to do just that. >>> >>> On Wed, Oct 29, 2025 at 12:17=E2=80=AFPM Hale, Britta (CIV) >> 40nps.edu@dmarc.ietf.org> wrote: >>> >>>> I concur with keeping clear and human-readable ciphersuites (e.g., >>>> =E2=80=9CQSF-P256-MLKEM768-SHAKE256-SHA3256=E2=80=9D). Post quantum mi= gration is >>>> challenging enough without adding a further mapping that humans can >>>> mis-interpret, which can itself lead to introduction of vulnerabilitie= s >>>> while attempting use of post quantum algorithms. >>>> >>>> >>>> >>>> If there are any cases where shorthand is absolutely needed (e.g., in >>>> specific WGs where counting bytes matters), then reference strings oug= ht to >>>> be simple such as a numeric mapping to specific suites. ASCII art make= s it >>>> difficult to ensure correctness, even among knowledgeable individuals,= as >>>> is evident by the examples already encountered. We should not be makin= g >>>> standards intentionally more difficult to follow for less experienced >>>> individuals. >>>> >>>> >>>> >>>> Britta >>>> >>>> >>>> >>>> >>>> >>>> *From: *Mike Ounsworth >>>> *Date: *Wednesday, October 29, 2025 at 11:11=E2=80=AFAM >>>> *To: *Eric Rescorla >>>> *Cc: *LAMPS WG , CFRG , "hpke@ietf.org" >>>> >>>> *Subject: *[CFRG] Re: New labels in >>>> draft-irtf-cfrg-concrete-hybrid-kems-01 >>>> >>>> >>>> >>>> NPS WARNING: *external sender* verify before acting. >>>> >>>> >>>> >>>> As as pointed out by Daniel Van Geest in another thread, the label >>>> for MLKEM1024-P384 is supposed to be " | /-\", but in the published ve= rsion >>>> of the cfrg draft (both HTML and TXT), it displays as ` | /-` (note th= e >>>> 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 c= hange >>>> in consultation with you guys as part of the CRFC Interim in Sept. You= r 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, bu= t >>>> on 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 < >>>> ounsworth+ietf@gmail.com> 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 >>>> and put the labels back to sane alphanumeric. I'm sorry for strong lan= guage >>>> below, but this makes me mad. >>>> >>>> I have been bending over backwards to make the LAMPS thing match the >>>> HPKE thing, including multiple rounds of interop-testing against your = test >>>> vectors and changing the LAMPS draft, reference impl, and test vectors= to >>>> match yours. This has resulted in delayed publication of the LAMPS dra= ft 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= of >>>> the form "QSF-MLKEM768-P256-SHA3256" that we pulled FROM YOUR DRAFT in= stead >>>> of the OID-based labels we had before. Then on Oct 20 you publish a ne= w >>>> version that goes and changes the labels to this nonsense. Can you guy= s >>>> please at least pretend like you care about interop between these two = docs? >>>> >>>> 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 = you >>>> 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 = had >>>> similar problems representing this label properly in HTML and markdown >>>> docs. Now you want more labels that have both backslashes and now spac= es. >>>> 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 cod= e 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 >>>> get interop between these two documents, and it feels like you guys ar= e >>>> 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 -- cfrg@irtf.org >>>> To unsubscribe send an email to cfrg-leave@irtf.org >>>> >>>> _______________________________________________ >>>> hpke mailing list -- hpke@ietf.org >>>> To unsubscribe send an email to hpke-leave@ietf.org >>>> >>> >>> >>> -- >>> >>> Sophie Schmieg | Information Security Engineer | ISE Crypto | >>> sschmieg@google.com >>> >>> _______________________________________________ > CFRG mailing list -- cfrg@irtf.org > To unsubscribe send an email to cfrg-leave@irtf.org > --00000000000072c2c60642524cd6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If LAMPS wants to interop why defining things differently= at all vs by reference? This whole thing seems silly to me.

On Wed, Oct 29, 2025, 1:44=E2=80=AFPM Eric Rescorla <ekr@rtfm.com> wrote:
Following up to myse= lf.... I'm also fine with the LAMPS strings.

-= Ekr


On Wed, Oct 29, 2025 at 1:27=E2=80=AFPM Eric Rescor= la <ekr@rtfm.com> wrote:
I would make a few points here:

I don't have a strong opinion on whether we ought to h= ave structured strings=C2=A0or just 6-byte constants but ISTM that having t= he spec contain strings which contain special characters are a clear safety= hazard, and the only motivation for them seems to be to make a Star Wars j= oke, which really doesn't seem like a priority for the RG. That seems m= ore like a bug than a feature=C2=A0to me. With that said, while the X-wing = label is unfortunate, I don't think anyone is proposing to change it, b= ut no such considerations exist for the other value. To that end, I propose= the following:

- Render the labels only as hex va= lues.
- Replace the non-X-wing labels with values which don't= happen to correspond to escape characters. The obvious thing to do here is= just to use a simple counter, so we can use (x00...00 and 0x00..02) but I = could imagine other approaches.

The net effect of = these is to slightly reduce the surface area for errors without creating an= interop problem or arguments about the semantics of the strings.=C2=A0

Finally, I would observe that arguments of the form &= quot;we need to get things out now so we need to do things the way I prefer= " are less persuasive than "we need to get this now so I'm pr= epared to do things a way I don't really like".

-Ekr



On Wed, Oct 29, 2025 at 1:11= =E2=80=AFPM Sophie Schmieg <sschmieg@google.com> wrote:
The lab= els are simple numeric codepoints:
0x7C2D28292D7C for X-Wing
= 0x5C2E2F2F5E5C for P256-ML-KEM1024
0x207C202F2D5C for P384-ML-KEM= 1024
in little endian.
And yes, I concur with Filippo, = we need to be able to ship without being held up by discussions on naming t= hings, and simple numerical values like the ones above allow us to do just = that.

On Wed, Oct 29, 2025 at 12:17=E2=80=AFPM Hale, Britta (CIV) <= britta.hale=3D40nps.edu@dmarc.ietf.org> wrote:

I concur with keeping= clear and human-readable ciphersuites (e.g., =E2=80=9CQSF-P256-MLKEM768-SH= AKE256-SHA3256=E2=80=9D). Post quantum migration is challenging enough with= out adding a further mapping that humans can mis-interpret, which can itself lead to introduction of vulnerabilities while attempting = use of post quantum algorithms.

=C2=A0<= /span>

If there are any case= s where shorthand is absolutely needed (e.g., in specific WGs where countin= g bytes matters), then reference strings ought to be simple such as a numer= ic mapping to specific suites. ASCII art makes it difficult to ensure correctness, even among knowledgeable ind= ividuals, as is evident by the examples already encountered. We should not = be making standards intentionally more difficult to follow for less experie= nced individuals.

=C2=A0<= /span>

Britta<= /span>

=C2=A0<= /span>

=C2=A0<= /span>

From: Mike = Ounsworth <ounsworth+ietf@gmail.com>
Date: Wednesday, October 29, 2025 at 11:11=E2=80=AFAM
To: Eric Rescorla <ekr@rtfm.com>
Cc: LAMPS WG <spasm@ietf.org>, CFRG <cfrg@irtf.org>, &quo= t;hpk= e@ietf.org" <hpke@ietf.org>
Subject: [CFRG] Re: New labels in draft-irtf-cfrg-concrete-hybrid-ke= ms-01

=C2=A0

= = NPS WARNING: *external sender* verify before acting.

=C2=A0

As as pointed out by Daniel Van Geest in another thr= ead, the label for=C2=A0MLKEM1024-P384 is supposed to be " | /-\"= , but in the published version of the cfrg draft (both HTML and TXT), it di= splays as=C2=A0` | /-` (note the missing backslash). So that means that the kramdown2rfc tooling is not handling this properly.=

=C2=A0

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

=C2=A0

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 Interi= m in Sept. Your doc is not in WGLC yet, so can you please change your labels to match?

=C2=A0

On Wed, 29 Oct 2025 at 12:47, Eric Rescorla <ekr@rtfm.c= om> wrote:

I can't speak=C2=A0for what has or has not happe= ned in terms of interop, but on the

substance of the labels I agree with Mike. I strongl= y prefer simple human-readable

labels to ASCII art Star Wars references, no matter = how clever those references

might be.

=C2=A0

-Ekr

=C2=A0

On Wed, Oct 29, 2025 at 10:36=E2=80=AFAM Mike Ounsworth <ounswor= th+ietf@gmail.com> wrote:

draft-irtf-cfrg-concrete-hybrid-kems-01 publish on O= ct 20 and made the following label changes:

=C2=A0

=C2=A0

"QSF-P256-MLKEM768-SHAKE256-SHA3256" -->= ;=C2=A0 "|-()-|"

"QSF-P384-MLKEM1024-SHAKE256-SHA3256" --&g= t; " | /-"



Please tell me this is a joke. Then please remove this from the draft and p= ut 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 HPKE t= hing, including multiple rounds of interop-testing against your test vector= s and changing the LAMPS draft, reference impl, and test vectors to match y= ours. This has resulted in delayed publication of the LAMPS draft by several months to accommodate interop wi= th the HPKE draft. The LAMPS Composite-KEM doc went into WGLC on Oct 17 now= using HPKE-style labels of the form "QSF-MLKEM768-P256-SHA3256" = that we pulled FROM YOUR DRAFT instead of the OID-based labels we had before. Then on Oct 20 you publish a new versi= on that goes and changes the labels to this nonsense. Can you guys please a= t least pretend like you care about interop between these two docs?

My specific objections to more ASCII art labels:

1. We're already having interop problems at the PQC hackathon group bec= ause of the backslash in the xwing label -- for example, in python you 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 had 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 incompatibil= ities if not CVEs.

2. The label is not human-readable; it doesn't tell my anything=C2=A0us= eful about the content, nor will it be easy to debug mistakes in source cod= e or config files. At this point, assigning a numeric codepoint would be pr= eferable.

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 get i= nterop between these two documents, and it feels like you guys are doing ev= erything in your power to obstruct it.


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

=C2=A0=

(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

_______________________________________________
hpke mailing list -- hpke@ietf.org
To unsubscribe send an email to hpke-leave@ietf.org


--

Sophie = Schmieg=C2=A0|=C2=A0Inf= ormation Security Engineer=C2=A0|=C2=A0ISE Crypto=C2=A0|=C2=A0sschmieg@google.com

_______________________________________________
CFRG mailing list -- cfrg@irtf.org
To unsubscribe send an email to cfrg-leave@irtf.org
--00000000000072c2c60642524cd6--