Hey Francisco et. al., Thank you for the additional context. I appreciate both suggested changes from my optional feedback and think they both make the document clearer for a wider audience. Best of luck with your other remaining publication steps.
I will update my ballot accordingly, though it of course will remain No Objection so you can proceed. Thanks, Tommy > > On May 27, 2026 at 19:44, FRANCISCO LOPEZ GOMEZ <[email protected]> > wrote: > > > Hi everyone, > > Please find inline our responses to the comments raised. > > Thank you for your review and feedback. > > Best regards, > The EAP-EDHOC Authors. > > > > > > > > > > > > > > > > > > > > Francisco López Gómez > > > > > > > > > > Predoctoral Researcher > Dept. Ingeniería de la Información y las Comunicaciones > > > > > > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > De: Tommy Jensen via Datatracker <[email protected]> > Enviado: Miércoles, 29 de Abril de 2026 7:16 > Para: The IESG <[email protected]> > CC: [email protected] > <[email protected]>; [email protected] > <[email protected]>; [email protected] <[email protected]>; [email protected] > <[email protected]> > Asunto: Tommy Jensen's No Objection on draft-ietf-emu-eap-edhoc-09: (with > COMMENT) > > > Tommy Jensen has entered the following ballot position for > draft-ietf-emu-eap-edhoc-09: 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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!D9dNQwwGXtA!TNJun2yhs5nnWjCC6d34625j1l08Imu96pQjpEUvI1dC2dDE8Jr4pOsbZyzrgJOK0cMT0K-EUrAlHrrCsey-$ > > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-emu-eap-edhoc/__;!!D9dNQwwGXtA!TNJun2yhs5nnWjCC6d34625j1l08Imu96pQjpEUvI1dC2dDE8Jr4pOsbZyzrgJOK0cMT0K-EUrAlHn4ah4u1$ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I support this document as an efficient way to improve the > security/performance > trade-off for low-resource devices. > > One point I think should be clarified is this bit from Section 3.1: > > Resumption of EAP-EDHOC may be defined using the EDHOC-PSK > > authentication method [I-D.ietf-lake-edhoc-psk]. > > ...compared to Section 6.9: > > The cross-protocol attack of [RFC9190] does not apply here, as no > > resumption mechanism has been defined for EAP-EDHOC. > > I suggest 6.9 should be updated to more explicitly delegate responsibility to > documents that define resumption mechanisms rather than just say it isn't > this > draft's responsibility. > > > [Authors] Thank you for this comment. Resumption is not defined in the > current document, as EDHOC-PSK is still under standardization in LAKE wg. > However, in the future, once EDHOC-PSK reaches a stable version, we would > like to add a resumption mechanism for EAP-EDHOC, addressing the > cross-protocol attack concern at that moment. We will update the text to > explicitly delegate responsibility on cross-protocol attacks to the future > document defining the resumption mechanism, as suggested. > > > > Regarding Section 6.5: > > EAP-EDHOC relies on EDHOC, which is designed to encrypt and integrity > > protect as much information as possible. Any change in any message > > is detected by means of the transcript hashes integrity verification. > > The statement that EDHOC is designed to "encrypt and integrity protect as > much > information as possible" (opportunistic) seems to be at odds with "any change > in any message" (deterministic). As far as I can tell, the latter claim is > true. Therefore, I would change how EDHOC is described here to match that. If > in fact there are some changes that can be made to a message that cannot be > detected, then the text needs corrected of course. > > > [Authors] Thank you for this suggestion. Since EDHOC uses transcript hashes > that include the plaintext messages for key derivation, any modification to a > message will result in a mismatch in the keys used to perform the protocol by > both parties. Therefore, an attacker cannot introduce unnoticed changes to a > message. > > However, the phrase “protect as much information as possible” is used > because not all fields and messages in EDHOC are encrypted. We acknowledge > the possible ambiguity in the text, so we will rephrase it as follows: > > “EAP-EDHOC relies on EDHOC, which is designed to maximize confidentiality by > encrypting handshake elements as early as the protocol state permits. In > addition, the protocol is cryptographically bound such that any modification > to any message—encrypted or unencrypted—results in a verification failure, as > transcript hashes computed over the plaintext messages are used to derive the > cryptographic material used by both endpoints.” > > > > >
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
