Hello EAP-EDHOC authors, thanks for providing this document, which I think is in a good shape; I'm looking forward to using this combination of technologies.
I'm late for the WGLC, but hope that these comments still help. BR Christian Protocol flow ============= * Looking at figure 1 it seems odd that there's a full round-trip before starting EDHOC messages. The EAP-Response/Identity should be able to easily carry a message_1, and there is no identifiying data in there (most sensitive is method and cipher suite, but that's not many bits of identification, it's mostly pure entropy). This looks like a needless round-trip to me. Or are the Identity messages actually more of an exception (it is stated they are optional), so doing anything there would just make matters complicated for little practical gain? (But then, why is it in every example?) This may be obvious to readers coming from the EAP side, but for me coming from EDHOC and knowning EAP mainly as a user, it is not. * Cipher suite negotiation: EDHOC says that "The Initiator SHOULD remember which selected cipher suite to use until the next message_1 has been sent". The initiator here is the peer, so remembering this information means recognizing that it's the same server (and same authenticator) that is making the request. Is that something EAP provides in general, and can you make a recommendation as to what precisely to key the memory on? (This is a general concern in EDHOC (see [thread]), but until that is resolved, I hope that EAP has the easy way out and can remember). [thread]: https://mailarchive.ietf.org/arch/msg/lake/Aq2KEecA1PnX5rXHBYLytoXLuqw Ecosystem interactions ====================== * Section 3.2 talks at length about how server certificate is verified. Exceeding the typical certificate mechanisms, EDHOC extensions provide additional means to verify the server's credentials, such as [ELA]; this could be a useful poiner to anyone struggling to provide the right root CA. [ELA]: https://datatracker.ietf.org/doc/draft-ietf-lake-authz/ Editorial ========= * "The optimization combining the execution of EDHOC with the first subsequent OSCORE": "not supported" sounds like one could potentially make it supported; "not applicable" might describe things better. * "EAP_1" and "EAP_2" are mentioned only once, and are not terms I found in the referenced documents. Which are those, and where do they show up in the hashes? (Should those say "EAD_1" and "EAD_2"? Or are they really TBD5? TBD1 x 1/2 for Code Request/Response?) -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
