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

[Göran Selander <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> wrote:

    
    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
    
    _______________________________________________
    Secdispatch mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/secdispatch