#edhoc — Public Fediverse posts

@leyrer That is my understanding as well. (With #EDHOC it's the other way around: Both parties being authenticated is the common case, and we call accepting any credential that is sent by value just "unilaterally authenticated" in the Onion CoAP draft).

While I do maintain that "it's coming from the LAN" is not a good #security boundary, there are services where it is practical (eg. media center volume control), but also fault prone (oups my phone just switched to LTE for power saving – a generally justified thing).

Before I start formalizing how "a device can retain permissions it gets from being local for a few days" could work with EST / #TLS / #EDHOC: Does this model have a name, and/or have you ever seen it discussed or deployed anywhere?

The demos themselves are not new, but compared to back in https://chaos.social/@chrysn/112679478336788933, a lot of the band-aids have come off. (Some were replaced by others, eg. to work with the latest release of the Lakers #EDHOC implementation – the documentation can't build this way on readthedocs yet).

Lakers, an implementation of #EDHOC, i.e., lightweight security for #IoT, now uses formal verification to continuously check a first small part of its code using #hax and F*, proving our buffers won't reach out of their bounds and panic. Thanks @cryspen for making that tool rather straightforward to learn.

Lakers, an implementation of #EDHOC, i.e., lightweight security for #IoT, now uses formal verification to continuously check a first small part of its code using #hax and F*, proving our buffers won't reach out of their bounds and panic. Thanks @cryspen for making that tool rather straightforward to learn.

Lakers, an implementation of #EDHOC, i.e., lightweight security for #IoT, now uses formal verification to continuously check a first small part of its code using #hax and F*, proving our buffers won't reach out of their bounds and panic. Thanks @cryspen for making that tool rather straightforward to learn.

Lakers, an implementation of #EDHOC, i.e., lightweight security for #IoT, now uses formal verification to continuously check a first small part of its code using #hax and F*, proving our buffers won't reach out of their bounds and panic. Thanks @cryspen for making that tool rather straightforward to learn.

Lakers, an implementation of #EDHOC, i.e., lightweight security for #IoT, now uses formal verification to continuously check a first small part of its code using #hax and F*, proving our buffers won't reach out of their bounds and panic. Thanks @cryspen for making that tool rather straightforward to learn.

The #IETF122 hackathon starts in a few hours. I will be joining remotely, work on #EDHOC on @ariel (let's see if its out-of-the-box support also interoperates out-of-the-box), and play with #embeddfriendly URIs expressed in #CBOR.

#IETF #IETFHackathon #ArielOS

The #IETF122 hackathon starts in a few hours. I will be joining remotely, work on #EDHOC on @ariel (let's see if its out-of-the-box support also interoperates out-of-the-box), and play with #embeddfriendly URIs expressed in #CBOR.

#IETF #IETFHackathon #ArielOS

The #IETF122 hackathon starts in a few hours. I will be joining remotely, work on #EDHOC on @ariel (let's see if its out-of-the-box support also interoperates out-of-the-box), and play with #embeddfriendly URIs expressed in #CBOR.

#IETF #IETFHackathon #ArielOS

The #IETF122 hackathon starts in a few hours. I will be joining remotely, work on #EDHOC on @ariel (let's see if its out-of-the-box support also interoperates out-of-the-box), and play with #embeddfriendly URIs expressed in #CBOR.

#IETF #IETFHackathon #ArielOS

The #IETF122 hackathon starts in a few hours. I will be joining remotely, work on #EDHOC on @ariel (let's see if its out-of-the-box support also interoperates out-of-the-box), and play with #embeddfriendly URIs expressed in #CBOR.

#IETF #IETFHackathon #ArielOS

Bad dotbot! No destroying the swarm today!
#RIOTSummit #IoT #robotics #EDHOC

Just released version 0.4.10 of #aioCoAP, the asynchronous #Python library for #CoAP. The latest feature is support for #EDHOC (RFC9528), a highly efficient key establishment protocol. Documentation is at <https://aiocoap.readthedocs.io/>; the demo server described at <https://coap.amsuess.com/> also offers EDHOC now.

A new lightweight authenticated key exchange protocol provides improved security with less overhead for Internet-of-Things devices. Read about #EDHOC, as described in #RFC9528 & #RFC9529, from LAKE Working Group co-chairs Mališa Vučinić & Stephen Farrell: https://www.ietf.org/blog/edhoc/

A new lightweight authenticated key exchange protocol provides improved security with less overhead for Internet-of-Things devices. Read about #EDHOC, as described in #RFC9528 & #RFC9529, from LAKE Working Group co-chairs Mališa Vučinić & Stephen Farrell: https://www.ietf.org/blog/edhoc/

A new lightweight authenticated key exchange protocol provides improved security with less overhead for Internet-of-Things devices. Read about #EDHOC, as described in #RFC9528 & #RFC9529, from LAKE Working Group co-chairs Mališa Vučinić & Stephen Farrell: https://www.ietf.org/blog/edhoc/

A new lightweight authenticated key exchange protocol provides improved security with less overhead for Internet-of-Things devices. Read about #EDHOC, as described in #RFC9528 & #RFC9529, from LAKE Working Group co-chairs Mališa Vučinić & Stephen Farrell: https://www.ietf.org/blog/edhoc/

A new lightweight authenticated key exchange protocol provides improved security with less overhead for Internet-of-Things devices. Read about #EDHOC, as described in #RFC9528 & #RFC9529, from LAKE Working Group co-chairs Mališa Vučinić & Stephen Farrell: https://www.ietf.org/blog/edhoc/

If the goal of a hackathon is to connect with other teams and exchange ideas, the @RIOT_OS participation in the #IETF hackathon was quite successful. (If not, we still made some improvements and now have tested interoperability with other #EDHOC implementations).

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

Getting ready for the #IETF LAKE hackathon combined with the #IRTF T2TRG meeting at INRIA Paris <https://parishackathon.lakewg.org/> on the next two days.
We will interop #EDHOC implementations (eg. using @RIOT_OS and its #RustLang companion RIOT-rs), test it directly on #CoAP, and discuss current engineering and research questions on how #IoT devices can communicate in a secure and privacy preserving manner while fitting on the tiniest of devices.

@tryst Transmitting secret keys may be problematic, but doing key exchange may be an option to derive keys for MACs. No concrete plans yet, but I hope to use #EDHOC (RFC9528) in amateur radio.

@zimpenfish The edhoc-rs crate technically does have examples, because there is a #CoAP server/client example, but its mix of hacspec and pure Rust is quite hard to read (simplifications are incoming). It implements #EDHOC, a very compact authenticated DH key exchange.
If the question is more about data formats (and full EDHOC is not what you need), you could look into CWTs or (if you don't need them authenticaded) CWT Claims Sets (CCS), but sadly I can't point you at good crates for them yet.

It's funny how mTLS (mutually authenticated #TLS) is special enough to get its own acronym, and in the context of #EDHOC I'm often finding myself talking about "unilaterally authenticated EDHOC". Both can do either, but the expectations differ.