Thanks Mike. -09 will include these fixes. I did not add that [RFC9370] already 
defines arbitrary "hybrid" key exchanges because it is covered already in the 
Appendix. 


-----Original Message-----
From: Mike Bishop via Datatracker <[email protected]> 
Sent: Monday, June 29, 2026 1:45 PM
To: The IESG <[email protected]>
Cc: [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: [EXTERNAL] Mike Bishop's No Objection on 
draft-ietf-ipsecme-ikev2-mlkem-08: (with COMMENT)

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you can confirm the sender and know the 
content is safe.



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".



_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to