Hi, For message sizes you can find a comparision of EDHOC, TLS, TLS with RPK, and cTLS can be found in the document below. You would have to add the EAP(-TLS) request reponse layers. https://datatracker.ietf.org/doc/draft-ietf-iotops-security-protocol-comparison/
Other important metrics for IoT devices are memory, code size, energy, cpu cycles, which are also lower. Code size does of course depend on what you want to support in addition to EAP-EDHOC. If you are a constrained device already supporting CBOR, COSE these can be reused for EDHOC. If you support EAP-TLS the only resuse in EAP-EDHOC would be the algorithms. >If you can show that there is seemingly no way to get EAP-TLS (or anything >else) I don’t know what you mean with anything else, but I think the EMU WG does likely not want to do changes to TLS. cTLS seems quite optimized, I that is a far as you come while not making larger changes that would invalidate the security proofs. Cheers, John From: Alexander Clouter <alex+i...@coremem.com> Date: Tuesday, 7 November 2023 at 18:04 To: John Mattsson <john.matts...@ericsson.com> Cc: EMU WG <emu@ietf.org> Subject: Re: [Emu] FW: New Version Notification for draft-ingles-eap-edhoc-05.txt Hello, On Thu, 28 Sep 2023, at 15:47, John Mattsson wrote: > > EDHOC is high level very similar to the TLS 1.3 handshake but has much > smaller message sizes and is therefore useful in IoT. EAP-EDHOC is just > EDHOC over EAP using the EAP-TLS request and response packet formats. To help get me behind this it would be interesting to see comparisons made against existing EAP methods. For example, how much smaller and better for your use case is EAP-EDHOC compared to: * plain vanilla flavoured EAP-TLS * why is NewSessionTicket (session resumption) * though a draft, make some predictions if there was a EAP-cTLS (based off draft-ietf-tls-ctls) implementation * what if RPK (RFC7250) was an option; draft-chen-emu-eap-tls-ibs attempted this but also lacked information on how much you gained by doing this * could "Trusted CA Indication" (RFC6066, section 6) help; though it probably would need adding to OpenSSL[1] How much slimmer do you need EAP-TLS to be to make EAP-EDHOC no longer necessary? Or is the shape of it just completely inappropriate? >From my perspective, I see work in the pipeline that could be called on to >trim EAP-TLS in a manner that would only require implementers to make tweaks >to their existing implementations. If you can show that there is seemingly no way to get EAP-TLS (or anything else) to fit the bill, it would convince me that this is a good place to put my energy into. Cheers Alex [1] https://protect2.fireeye.com/v1/url?k=31323334-501cfaf3-313273af-454445554331-0fe24c0b277e0f2f&q=1&e=1b3185be-29f0-47b3-8f30-b7b626dfd6eb&u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F3029
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
