Content-Type: multipart/alternative;
	boundary="------------CvZTVj0amRl4h0aVxjg4BKZD"
Message-ID: <89f93eb8-2285-4426-8975-ef175a9011e1@amongbytes.com>
Date: Thu, 5 Feb 2026 00:50:09 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Deb Cooley <debcooley1@gmail.com>, The IESG <iesg@ietf.org>
References: 
 <177005673315.2419131.721588813854381299@dt-datatracker-77f8b84995-z4hzn>
Content-Language: en-US
From: Kris Kwiatkowski <kris@amongbytes.com>
In-Reply-To: 
 <177005673315.2419131.721588813854381299@dt-datatracker-77f8b84995-z4hzn>
Message-ID-Hash: 7TUZJKKNVYIFANUGRCVGPI5UWPNJJV4B
CC: draft-ietf-tls-ecdhe-mlkem@ietf.org, tls-chairs@ietf.org, tls@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Deb_Cooley=27s_No_Objection_on_draft-ietf-tls-ecdh?=
 =?utf-8?q?e-mlkem-03=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/TnPBhcuD-R7i_G87E9b4DN6KOLk>

--------------CvZTVj0amRl4h0aVxjg4BKZD
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

Hello,

Thank you Deb for the review. Please find my answers inline below:

> Thanks to Joe Salowey for the shepherd write up explanation of why the registry
> setting is what it is.
>
> Section 4.1, 4.2:  Please check the order and sizes of the client share and
> server shares.  It appears that they don't match between section 4.1 and 4.2.
> For example, for X25519MLKEM768 is 1184 bytes for the MLKEM portion of the
> client share, and 1088 bytes for the server share.  The order of the items in
> () for both the SecP/MLKEM groups are opposite between client share and server
> share (maybe this doesn't matter, but it certainly looks odd).

I have verified the sizes and confirmed that they are correct. Note that, unlike ECDH,
the ML-KEM client and server shares are not the same size: the client transmits a public key,
while the server returns a ciphertext, and these objects have different lengths. Consequently,
the sizes reported in Sections 4.1 and 4.2 are not equal.

The key and ciphertext sizes are derived from Table 3 in FIPS 203.

> Section 5:  I do agree with Gunter that the name of this section is less than
> descriptive.

As per previous email  - this is being addressed here:
https://github.com/tlswg/tls-ecdhe-mlkem/pull/61

Any feedback is more than welcome.

>
> Section 5, FIPS compliance:  Does the order that the shared secrets are
> combined matter?
>
Yes, the order of shares is swapped for X25519 and NIST curves, due to FIPS compliance.
The presentation I've done at IETF 121 provides more details.
- Video:https://youtu.be/46ItvWI_k4Y?list=PLC86T-6ZTP5iW_EW2fpjMvIhLb1uTEkMQ&t=7000
- Slides:https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00.pdf

As a side note - we know that NIST is planning to allow custom order (it was confirmed by NIST). But at the time of writing, this is not finalized yet.

Kind regards,
Kris

--------------CvZTVj0amRl4h0aVxjg4BKZD
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><font face="monospace">Hello,<br>
        <br>
        Thank you Deb for the review. Please find my answers inline
        below:<br>
        <br>
      </font></p>
    <blockquote type="cite"
cite="mid:177005673315.2419131.721588813854381299@dt-datatracker-77f8b84995-z4hzn">
      <pre wrap="" class="moz-quote-pre">Thanks to Joe Salowey for the shepherd write up explanation of why the registry
setting is what it is.

Section 4.1, 4.2:  Please check the order and sizes of the client share and
server shares.  It appears that they don't match between section 4.1 and 4.2. 
For example, for X25519MLKEM768 is 1184 bytes for the MLKEM portion of the
client share, and 1088 bytes for the server share.  The order of the items in
() for both the SecP/MLKEM groups are opposite between client share and server
share (maybe this doesn't matter, but it certainly looks odd).</pre>
    </blockquote>
    <pre>I have verified the sizes and confirmed that they are correct. Note that, unlike ECDH, 
the ML-KEM client and server shares are not the same size: the client transmits a public key,
while the server returns a ciphertext, and these objects have different lengths. Consequently, 
the sizes reported in Sections 4.1 and 4.2 are not equal.

The key and ciphertext sizes are derived from Table 3 in FIPS 203.</pre>
    <blockquote type="cite"
cite="mid:177005673315.2419131.721588813854381299@dt-datatracker-77f8b84995-z4hzn">
      <pre wrap="" class="moz-quote-pre">
Section 5:  I do agree with Gunter that the name of this section is less than
descriptive.</pre>
    </blockquote>
    <pre>As per previous email  - this is being addressed here:
<a class="moz-txt-link-freetext" href="https://github.com/tlswg/tls-ecdhe-mlkem/pull/61">https://github.com/tlswg/tls-ecdhe-mlkem/pull/61</a>

Any feedback is more than welcome.</pre>
    <blockquote type="cite"
cite="mid:177005673315.2419131.721588813854381299@dt-datatracker-77f8b84995-z4hzn">
      <pre wrap="" class="moz-quote-pre">

Section 5, FIPS compliance:  Does the order that the shared secrets are
combined matter?

</pre>
    </blockquote>
    <pre>Yes, the order of shares is swapped for X25519 and NIST curves, due to FIPS compliance. 
The presentation I've done at IETF 121 provides more details.
- Video: <a class="moz-txt-link-freetext" href="https://youtu.be/46ItvWI_k4Y?list=PLC86T-6ZTP5iW_EW2fpjMvIhLb1uTEkMQ&amp;t=7000">https://youtu.be/46ItvWI_k4Y?list=PLC86T-6ZTP5iW_EW2fpjMvIhLb1uTEkMQ&amp;t=7000</a>
- Slides: <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00.pdf">https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00.pdf</a>

As a side note - we know that NIST is planning to allow custom order (it was confirmed by NIST). But at the time of writing, this is not finalized yet.

Kind regards,
Kris</pre>
  </body>
</html>

--------------CvZTVj0amRl4h0aVxjg4BKZD--