[Secdispatch] a proposed path forward on EDHOC/lightweight AKEs

[Benjamin Kaduk <[e-mail]>]

Hello!

In late March, we summarized our perception of the information and
discussion that came out of the interim meeting [2], and solicited
feedback on proposed next steps [1].  Our proposed next step at that
time was to “charter a narrowly scoped, short-lived WG … with EDHOC as a
starting point”.

Since then, we received additional feedback, both on the summary and the
approach, including:

  * Support for the proposed approach in the form of:
    - Numerous individuals (>15) supported the proposed approach
    - A WG consensus endorsement for the approach from the CORE WG [3]
    - A reminder that the 6TISCH WG has consensus to use EDHOC in two WG drafts [6]
      and that it has been discussed in the WG since IETF 97 [7]
    - Interest in EDHOC for LPWAN [8] and for use in the Intelligent Transportation
      Union (ITU) [9]
    - Publication of draft-selander-lake-reqs to clarify requirements

  * Challenges to the proposed approach in the form of:
    - An individual supporting the formation of a WG, but defining no starting body
      of work
    - Questions on whether the design constraints are sufficiently well
      understood to evaluate solutions [12] [13] – rejecting “as low as
      reasonably possible” [10] or “as cheap as possible” as requirements 
    - Proposals to use a TLS derivative as an alternative to the EDHOC starting point
    - Publication of draft-rescorla-tls-ctls
    - Publication of experimental code designed to explore CTLS [11]
    - Spirited exchanges on the details, specificity and validity of
      lightweight AKE designs constraints, and real-world needs
    - Caution about the efficacy of narrow WGs [14] and the experiences of TCPINC [5]

As a result of this feedback and related discussions, we continue to
feel that there is support for the stance that developing a lightweight
AKE (LAKE) is an important problem to solve.  Furthermore, we also feel
that there is energy and interest to work on a LAKE, and that a focused
WG is the right structure to find a solution.  Another key ingredient
for success is a tight partnership with the WGs which have requirements
for such a LAKE.  In our assessment, at present, design constraints from
these requirements holders do not appear to be sufficiently precise to
allow the evaluation of alternative approaches.  A focused WG should be
able to tease apart the requirements from the various use cases into a
form that is precise enough to evaluate alternative approaches.

As a starting point, we would propose to charter a LAKE WG as follows:

==[ CHARTER ]==
Problem

Constrained environments using OSCORE in network environments such as
NB-IoT, 6TiSCH, and LoRaWAN need a ‘lightweight’ authenticated key
exchange (LAKE) that enables forward security.  'Lightweight' refers to:

  * resource consumption, measured by bytes on the wire, wall-clock time to
    complete, or power consumption
  * the amount of new code required on end systems which already have an
    OSCORE stack

Goals

This working group is intended to be a narrowly focused activity
intended to produce only at most one LAKE and close.

The working group will collaborate and coordinate with other IETF WGs
such as ACE, CORE, 6TISCH, and LPWAN to understand and validate the
requirements and solution.  The WG will also evaluate prior work from
the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe.

Program of Work

The deliverables of this WG are:

1. Design requirements of the LAKE in constrained environments (this
draft will not be published as an RFC but will be used to driving WG
consensus on the deliverable (2)

2. Standardize a lightweight authenticated key exchange (LAKE) for
suitable for use in a documented class of constrained environments  
==[ CHARTER ]==
 
We seek your feedback on this proposed approach.  Please share your
comments by Tuesday, June 18.  To keep momentum going on this topic we
plan to request a BoF slot at IETF 105, though the agenda for such a
slot will depend strongly on how the mailing list discussion proceeds.


Regards,

Ben and Roman
 
References
[1] https://mailarchive.ietf.org/arch/msg/secdispatch/Kz_6y6Jq4HsWxglsUHafWjXIm0c
[2] https://mailarchive.ietf.org/arch/msg/secdispatch/9AfqrecZfFMlMGxSXOo4ENZtrVk
[3] https://mailarchive.ietf.org/arch/msg/secdispatch/7UufjMgpCTifzoAmVeIDaT7bUuk
[4] https://datatracker.ietf.org/doc/draft-selander-lake-reqs/
[5] https://mailarchive.ietf.org/arch/msg/secdispatch/G2zo1cyO3AOhbPuM2r5pqVNI5hI
[6] https://mailarchive.ietf.org/arch/msg/secdispatch/nHQhxQ1v40HJ_8LuHvu3mC7b9Vg
[7] https://mailarchive.ietf.org/arch/msg/secdispatch/E0M1msLAmkSACB6T6wcG5h28XXE
[8] https://mailarchive.ietf.org/arch/msg/secdispatch/lMykdmZSoTFrHPuiU5F1EUlb7h8
[9] https://mailarchive.ietf.org/arch/msg/secdispatch/hihSp2ePB_kvl7Q8_tZ1DqMSRbI
[10] https://mailarchive.ietf.org/arch/msg/secdispatch/oXgki50_RNS7LNwEgYqjJOkBxF8
[11] https://mailarchive.ietf.org/arch/msg/secdispatch/s_AH1H73gttLv9XDCBaqLynMJ64
[12] https://mailarchive.ietf.org/arch/msg/secdispatch/vi55JLn-4XVuSOFUC6j28xcmePo
[13] https://mailarchive.ietf.org/arch/msg/secdispatch/oDmByIB_zRqZ316Vw6HyLyA_Jww
[14] https://mailarchive.ietf.org/arch/msg/secdispatch/6vnv7ZTEHw1JAdldn7qQz17YxBw