Hi Valery,
On 2019-02-18, 08:07, "Valery Smyslov" <[email protected]> wrote:
Hi,
> Richard Barnes <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ace
