[Ssh] Mohamed Boucadair's No Objection on draft-ietf-sshm-mlkem-hybrid-kex-08: (with COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-sshm-mlkem-hybrid-kex-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-sshm-mlkem-hybrid-kex/



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

Hi Panos, Douglas, and Torben,

Thank you for the effort put into this well-written specification.

Thanks also to Thomas Graf for the OPSDIR review and the authors for engaging.

Please find below few comments:

# c2pq

I have one minor comment about this part:

   However, if sufficiently large quantum computers become available,
   these instances would no longer be computationally infeasible
   rendering the current key exchange and authentication methods in SSH
   insecure [I-D.hoffman-c2pq].

I-D.hoffman-c2pq was expired since 2020. More importantly, it is not clear to
me which parts of that draft is important here.

If the intent is to have a reference for CRQC threats, maybe better to cite
draft-ietf-pquip-pqc-engineers#Section 3.

# Packet Size

CURRENT:
   This document does not define behavior in cases where
   a PQ/T Hybrid key exchange message causes a packet to exceed the
   minimally supported packet length.

I understand that this is left unspecified. However, rfc4253#section-6.1 has
the following provision:

   Implementations SHOULD
   support longer packets, where they might be needed.  For example, if
   an implementation wants to send a very large number of certificates,
   the larger packets MAY be sent if the identification string indicates
   that the other party is able to process them.  However,
   implementations SHOULD check that the packet length is reasonable in
   order for the implementation to avoid denial of service and/or buffer
   overflow attacks.

Are we also saying that part of 4253 should be skipped?

BTW, if the message is not sent because of a packet length issue, it would be
helpful if that event is logged as this would help with troubleshooting.

Cheers,
Med