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

From: Stefan Hristozov <[email-masked]>
Date: Mon, 15 Jun 2020 12:26:26 +0200

Dear all,

I also support the adoption of the document.

We have implemented the latest versions of EDHOC
(draft-selander-lake-edhoc-01) and OSCORE in C.
Our EDHOC implementation supports all modes of authentication: PSK,
signatures and static DH keys.
Moreover, for the signature and static DH keys modes we support the
usage of RPKs and native CBOR certificates [1].
We tested our implementation on several Cortex M and Xtensa devices:
nRF9160, nRF5144, nRF52843 and ESP32.
We have verified our implementation against the test vectors in [2].

Currently we are working towards open sourcing of our implementations
(probably as Apache 2).

Best regards
Stefan Hristozov

[1]: https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04
[2]:
https://github.com/EricssonResearch/EDHOC/blob/master/Test%20Vectors/vectors.txt

-- 
Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC
Lichtenbergstraße 11, 85748 Garching near Munich, Germany
Tel. +49 89 32299 86 157
[email-masked]
http://www.aisec.fraunhofer.de
http://twitter.com/FraunhoferAISEC

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 23 Jun 2020 02:59:57 +0000

I do not support adoption of this draft.

Introducing yet another AKE into the ecosystem seems risky and will cause implementor confusion. It will also introduce uncertainty for operators and add unnecessary complexity into their vendor compliance programs, with no real tangible benefits.

There is a well understood and thoroughly analysed AKE here (cTLS), that has working code proving it meets the low byte requirements outlined in draft-ietf-lake-reqs.

Can we reach definitive consensus in this WG  on whether cTLS meets the requirements laid out in draft-ietf-lake-reqs? This does not seem to have been explicitly agreed by all parties yet. Reaching this consensus on whether cTLS meets the requirements should be independent of whether EDHOC vs. cTLS is actually chosen.

And if there is unambiguous consensus that cTLS does in fact meet the draft-ietf-lake-reqs requirements, then surely this becomes an objective bake off similar to the recent CFRG PAKE decision.

Wearing my vendor hat (cisco) where we make low end low powered things (low end phones / headsets / cameras / wearables), the cost internally to a development organisation of having to train development teams to have to understand and integrate yet another cryptographic protocol and software stack, and the overhead associated with having internal security organisations ensure development teams are compliant, ensuring we fully understand the new protocol nerd knobs and their security implications, and ensuring we meet any market-entry compliance and hardening requirements for any new cryptographic protocol would be truly massive. Whereas basing the low end AKE on the tried and trusted TLS AKE avoids all that unnecessary cost and complexity, and as has been argued on this list, provides a better solution that is field hardened, is well understood across the entire industry, has strong security proofs, has far better interop characteristics, and can still meet draft-ietf-lake-reqs requirements.

-----Original Message-----
From: Lake <[email-masked]> On Behalf Of Stefan Hristozov
Sent: 15 June 2020 18:26
To: [email-masked]
Subject: [Lake] Call for adoption for draft-selander-lake-edhoc - respond by June 22

Dear all,

We have implemented the latest versions of EDHOC
(draft-selander-lake-edhoc-01) and OSCORE in C.
Our EDHOC implementation supports all modes of authentication: PSK, signatures and static DH keys.
Moreover, for the signature and static DH keys modes we support the usage of RPKs and native CBOR certificates [1].
We tested our implementation on several Cortex M and Xtensa devices:
nRF9160, nRF5144, nRF52843 and ESP32.
We have verified our implementation against the test vectors in [2].

Currently we are working towards open sourcing of our implementations (probably as Apache 2).

Best regards
Stefan Hristozov

--
Stefan Hristozov
Department Hardware Security
Fraunhofer Institute for Applied and Integrated Security AISEC Lichtenbergstraße 11, 85748 Garching near Munich, Germany Tel. +49 89 32299 86 157 [email-masked]
http://www.aisec.fraunhofer.de
http://twitter.com/FraunhoferAISEC

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Jun 2020 04:34:46 +0100

Hi Owen,

On 23/06/2020 03:59, Owen Friel (ofriel) wrote:
> Can we reach definitive consensus in this WG  on whether cTLS meets
> the requirements laid out in draft-ietf-lake-reqs? 

I don't think that'd be a useful thing to attempt, as it
is entirely obvious. (Please do correct me if I'm wrong.)

The eventual outcome of such a protracted and boring
debate would be that both edhoc and cTLS can meet the
requirements. For me, that means it'd be pointless.

The TLS WG has adopted cTLS, so there would be zero utility
in yet another WG opining upon the details of that. (If the
TLS WG decide to treat the lake-WG-reqs as a useful input,
that'd be a fine but independent thing.)

> This does not seem
> to have been explicitly agreed by all parties yet. Reaching this
> consensus on whether cTLS meets the requirements should be
> independent of whether EDHOC vs. cTLS is actually chosen.

I find it hard to even parse that tbh. It is entirely
clear that "all parties" will not agree here.

cTLS is being developed elsewhere. Opinions as to cTLS
are therefore no longer relevant (for lake) except to
the point where someone says "cTLS can do <x> but edhoc
cannot" and I have yet to see any such argument that
has not been immediately countered by either "yes, it
can" or else "sure, here's how."

Cheers,
S.