Hi Valery, On 2019-02-18, 08:07, "Valery Smyslov" <smyslov.i...@gmail.com> wrote:
Hi, > Richard Barnes <r...@ipv.sx> wrote: > > Finally, to be totally honest, I find the EDHOC spec pretty inscrutable. A > > little more prose to explain what's going on would go a long way toward > > helping this discussion be productive. > > Sure. > Find a WG to adopt it, and we can make the text beautiful. > The packets are all there, and the references pretty much explain all the crypto. > This stuff is not any newer than IKEv2. I have only a quick look over the draft, but one thing strikes me - the protocol is claimed not to bound to a particular transport (so I assume that implementing it on top of pure UDP is fine), and it has an odd number of messages. That's OK from cryptographic point of view, but it's a headache for implementations if the transport protocol is unreliable, since in this case retransmissions must be sent by both parties. We learned this lesson from IKEv1 (Aggressive and Quick modes) and in IKEv2 the number of messages in any exchange is always even, that simplifies implementations and makes protocol more reliable. Of course if only reliable transports are considered, then this doesn't matter. Current version of EDHOC is 3-pass to allow traffic data after one round trip, which reduces latency in many applications. A 4-pass version has also been discussed: https://mailarchive.ietf.org/arch/msg/ace/ZDHYEhvI0PenU6nGrhGlULIz0oQ When EDHOC is used as key exchange for OSCORE, and also in other settings, EDHOC will commonly run on top of CoAP. For example, in 6tisch the join protocol relies on CoAP proxy functionality. CoAP is defined for reliable transport (RFC 8323) as well as UDP (RFC 7252), the latter handles retransmissions by client and server. An example of using EDHOC with CoAP is given in appendix D.1: https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-11#appendix-D.1 It sounds like we should add some considerations for the setting you outline. Do you have an example or pointer explaining the specific problem in more detail? Thanks, Göran _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace