Subject: [IPsec] Mike Bishop's No Objection on draft-ietf-ipsecme-ikev2-mlkem-08: (with COMMENT)
From: Mike Bishop via Datatracker <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Mon, 29 Jun 2026 10:45:29 -0700
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>

Mike Bishop has entered the following ballot position for
draft-ietf-ipsecme-ikev2-mlkem-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# IESG review of draft-ietf-ipsecme-ikev2-mlkem-07

CC @MikeBishop

## Comments

### "Abstract", paragraph 1
```
     specifies how to use ML-KEM by itself or as an additional key
     exchange in IKEv2 along with a traditional key exchange.  These
```
Given that both options are "in IKEv2", this could be reworded for clarity.
Perhaps "specifies how to use ML-KEM as a key exchange in IKEv2, either by
itself or alongside a traditional key exchange."?

### Section 2, paragraph 1

It might be worth being more explicit here that [RFC9370] already
defines arbitrary "hybrid" key exchanges, so all that's needed is to have the PQ
algorithm assigned a codepoint.

### Section 3, paragraph 7
```
     out-of-band that a responder supports ML-KEM, it SHOULD only include
     proposals for ML-KEM or abort the negotiation if the responder
```
This could be read as recommending only non-hybrid proposals, which I think is
not the intent.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term `man`; alternatives might be `individual`, `people`, `person`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 1
```
-    communications in the future after a CRQC became available to them
-    which is also known as a 'harvest-now-decrypt-later' attack.  Such
-   --------------
+    communications in the future after a CRQC became available to them,
+                                                                      +
```

#### Section 1, paragraph 3
```
-    algorithms, another use of a PQ/T Hybrid key exchanges in IKEv2 is to
-                              --
```

### Section 2.1, paragraph 8
```
     ciphertext size for this ML-KEM parameter may not push the UDP packet
```
Is this to be understood as "might not (but also might)" or as "cannot" / "do not"?

### Section 3, paragraph 6

Consider "IKEv2 downgrades are" or "IKEv2's vulnerability to downgrades is"

### Grammar/style

#### Section 1.1, paragraph 3
```
turn a distinguished error value. Instead it will always produce an ss value
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Instead".

#### Section 3, paragraph 7
```
t an IKE_INTERMEDIATE exchange. Subsequently the peers can rekey the initial
                                ^^^^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Subsequently".