Re: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

[Martin Disch <[e-mail]>]

On Mon, Jun 8, 2020 at 3:54 PM Mališa Vučinić <[e-mail]> wrote:
> Please reply to this thread whether you support the adoption, and indicate if you are ready to review if this draft becomes a working group document.

As part of a thesis I built a proof-of-concept implementation of EDHOC
in the Rust programming language available at
https://github.com/martindisch/oscore. The naming of the repository is
due to the subject being both EDHOC and OSCORE on embedded devices,
but the following refers only to the EDHOC implementation.

It's based on draft-selander-ace-cose-ecdhe-14 and as such, sadly,
outdated. Since it was just one part of the overall work, I only
managed to implement the subset I needed, which is RPK and the
signature-signature based scheme (corresponding to what
draft-selander-lake-edhoc calls method 0). I also took some other
shortcuts, such as not supporting auxiliary data. Fortunately, test
vectors were about to be introduced just around the time I was working
on it, so I've been able to successfully verify my implementation
against them when John shared them with me for some preliminary
testing. Since I didn't have any prior experience implementing this
kind of software, I would definitely consider it more of an
experiment, but it's out there and it works, in case it can be useful
to anybody.

I'm convinced that EDHOC will be valuable particularly in the context
of OSCORE, possibly even beyond that. As for the draft itself, I would
like to mention one aspect that I think could be improved from the
perspective of an implementer. Part of the promise of EDHOC is that
it's simple and lightweight due to reusing COSE. That is certainly the
case, but breaks down somewhat when working on a system where no fully
featured library for it is available. This was the case for me and I
personally found it difficult to quickly figure out which aspects of
COSE I needed to implement. The draft does a good job of pointing to
the right places in RFC 8152, but I still ended up trying to
understand another ~100 page document just to implement the few
constructs I actually needed. I know the authors are aware of this and
there has been some effort to inline more information directly in the
specification, which I greatly appreciate. It would be very nice to
have an entirely self-contained document to work with. But I have to
again point out my lack of experience in that area, it's entirely
possible that this draft is in fact much better than others in this
regard and I just don't know it yet.

With that I would like to support the adoption and am looking forward
to seeing how it develops.

Kind regards,

Martin