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

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 3 Jun 2019 13:46:18 -0700

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Jun 2019 18:28:18 -0400

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

The charter text seems fine.
Thank you for considering to go directly to WG.

    > slot will depend strongly on how the mailing list discussion proceeds.

As it is difficult to enter conflicts for BOFs, it would be great if the
session request for this BOF could be done soonest, and that it include at a
minimum the following conflicts:
   1st: CORE ANIMA ACE LPWAN CBOR
   2nd: 6TISCH TLS SECDISPATCH ACME

Maybe Carsten or Goran have some additions here.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Göran Selander <[email-masked]>
Date: Fri, 7 Jun 2019 08:52:34 +0000

Hi Ben, Roman, 

I support the proposed approach with some comments on the draft charter:

What is clear from the inputs to this discussion and from your summary, but not clear from the charter text, is that this work is long overdue. Adopted drafts have been stalled for over 2 years pending the adoption of an AKE for OSCORE. 

The draft charter text expresses well that this work targets a lightweight AKE for OSCORE through a narrowly focused activity, but it lacks the sense of urgency. Aggressive milestones could add such information, but milestones are known to have become delayed, in particular if there is no support in the charter for not doing so. I would like to have a formulation in the charter expressing the timing aspect and that the role of LAKE is not to design a new AKE for OSCORE but to decide on an AKE for OSCORE out of existing specified protocols (or profiles thereof which does not change the formal security properties).

 For the same reason, I believe this part needs to be rephrased:  

"The WG will also evaluate prior work from the TLS WG and derivatives thereof, and draft-selander-ace-cose-ecdhe." 

As I read "derivates thereof", any hitherto unseen proposal loosely coupled to prior work in the TLS WG - even with unknown security properties - is a valid input in scope of LAKE. Clearly, that could prolong the completion time significantly. Therefore, the scope of derivate work in the TLS WG that will be evaluated needs to be much more restricted, most appropriately by listing drafts like draft-rescorla-tls-ctls. 

If people were interested in making a key exchange protocol for OSCORE they have had the chance for many years. If there is not even a specification by now, I think the stakeholders - the users of OSCORE - agree that it does not fit the timeline for this work. 

Göran

On 2019-06-03, 22:46, "Secdispatch on behalf of Benjamin Kaduk" <[email-masked] on behalf of [email-masked]> wrote:

    Hello!

    

    
    
    ==[ CHARTER ]==
    Problem

    
    Goals

    
    Program of Work

    

    Regards,
    
    Ben and Roman
     
    References
    
    _______________________________________________
    Secdispatch mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/secdispatch