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

From: Göran Selander <[email-masked]>
Date: Tue, 7 Jul 2020 14:27:47 +0000

Hi Martin, all,

> It would be very nice to have an entirely self-contained document to work with.

We got a similar comment previously, and tried to make the spec more easy to digest without previous experience with CBOR and COSE. Appendix A is one such attempt, this was already draft-selander-ace-cose-ecdhe-14 as you noted. We later made some updates to the appendix on test vectors (appendix C in draft-selander-ace-cose-ecdhe-14, appendix B in the latest version) so it should now be possible to follow each step in building the messages. But you do need to understand how to build a COSE_Encrypt, for which we only provide references as we didn't want to repeat text from RFC 8152. In principle we could go one step further and expand on the COSE constructs, e.g. in appendix A.2. Was this what you were thinking about?

Does anyone else have an opinion about this?

I opened an issue:
https://github.com/lake-wg/edhoc/issues/1

Göran

On 2020-06-13, 22:35, "Martin Disch" <[email-masked]> wrote:

    On Mon, Jun 8, 2020 at 3:54 PM Mališa Vučinić <[email-masked]> 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://protect2.fireeye.com/v1/url?k=a7ca1c16-f96afc82-a7ca5c8d-86d2114eab2f-c763711efdc1ed79&q=1&e=326758fa-f31f-4bf0-b1f0-8a347f7427b8&u=https%3A%2F%2Fgithub.com%2Fmartindisch%2Foscore. 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

    -- 
    Lake mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/lake

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 7 Jul 2020 17:15:02 +0200

> Does anyone else have an opinion about this?

I also believe that making the spec more useful for implementers is a reasonable request.

We do have to be careful about not misrepresenting the information in the normative documents.  That happens all too easy.  I also believe an actual implementer needs to be aware of the underlying technologies and their security considerations.  Maybe less so someone who just wants to use EDHOC; for this audience the security considerations in the document should be very good.

Maybe the request also is a symptom that we haven’t made those underlying technologies very accessible.  We can work on that, even better if we have some feedback on what created obstacles to understanding.

Grüße, Carsten

---

From: Martin Disch <[email-masked]>
Date: Tue, 7 Jul 2020 18:06:16 +0200

Hi Göran,

Thanks for following up on this. Yes, in my opinion expanding on the
COSE constructs would be helpful. But I also sympathize with not
wanting to duplicate what is already defined in another RFC (and
possibly getting it wrong, as Carsten points out). Considering that
there are quite a few implementers already and besides mine you have
only received one other similar comment, maybe this isn't an issue for
a meaningful majority.

In any case, the draft has made great strides already in terms of
accessibility and is in a good state now, so I don't see improvements
in this area as an absolute necessity.

Kind regards,

Martin