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

Göran Selander <> Fri, 07 June 2019 08:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A57A712001A for <>; Fri, 7 Jun 2019 01:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.031
X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LSRaj3faRSWp for <>; Fri, 7 Jun 2019 01:52:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC4FA120099 for <>; Fri, 7 Jun 2019 01:52:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r3ImGAG4SfvZNzc1DsGj7YDDFaF56dcr2V/RSvQyKxo=; b=bY9q34PnnvRGk1/m6a4+eogr52jJ8NAG/G6PyfoQtreuQheYcX4otm9V6lpgEX51edCmw46Jyf9FB3DRWtFcFqdO8CJZYFGCbKVVHAhuF1oxRQLztV0dV2erRSmgYVSzXk1v/csx/Ev+B3NXG3C9N/kEimLb0PyND2J7OuHFqjc=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Fri, 7 Jun 2019 08:52:35 +0000
Received: from ([fe80::8890:af24:bc53:9cb]) by ([fe80::8890:af24:bc53:9cb%7]) with mapi id 15.20.1965.011; Fri, 7 Jun 2019 08:52:34 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <>
To: Benjamin Kaduk <>, "" <>
Thread-Topic: [Secdispatch] a proposed path forward on EDHOC/lightweight AKEs
Thread-Index: AQHVGk1ytUkXXyarI0KNBUj9irgJuKaQCZ2A
Date: Fri, 7 Jun 2019 08:52:34 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: bdcfc7ab-1199-4148-6e11-08d6eb257c2b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:HE1PR07MB4153;
x-ms-traffictypediagnostic: HE1PR07MB4153:
x-ms-exchange-purlcount: 15
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0061C35778
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(136003)(346002)(376002)(199004)(189003)(53936002)(7736002)(256004)(6306002)(71200400001)(8936002)(83716004)(3846002)(6116002)(14444005)(2906002)(85202003)(476003)(2616005)(33656002)(66574012)(6486002)(6512007)(71190400001)(11346002)(486006)(229853002)(5660300002)(446003)(6436002)(81166006)(186003)(2171002)(305945005)(25786009)(66066001)(76116006)(110136005)(36756003)(68736007)(66446008)(66476007)(8676002)(64756008)(85182001)(82746002)(58126008)(81156014)(86362001)(2501003)(6246003)(6506007)(99286004)(966005)(478600001)(14454004)(102836004)(76176011)(561944003)(66556008)(26005)(66946007)(73956011)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4153;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: utaLoCn/K9y3FhrnvcoWIm9Ealqx0Ft2xrZxcUo5/XA1/iYfzvhEMD3bkeRb/khjKJbZ9fXW/iryzFena48tfj2ks/iym/NngQ/40foRj72jnFajzCAYD2L9Qbg4kf9cI0enNQFecPo1CTSMum2ovfeaX9iSHz8kQtcZQqPcu8xYpSsDCMo8doqDUJo6KkLMmgcGUTWHVuYwsyNlnzAahQ5Y9PSCZyQUvdC1T7EfEpTRDbYjEa26GyR8FRamIfcN6RGpmhGWzw6RCmkR+jPcf4ThDzTiF4JF+suzo2gyakmwQGOQpFs2xttfNOG13bbz9BoDQDCcU92a9mMglWkP3Lic/VqpqQ0D3t/YcJcPi+UvhnUEuAgaEHlRE65mcZgQsn0JkAWtvKnW/TthcSLGMF8pZg787QjW7cKM+vvsQAE=
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: bdcfc7ab-1199-4148-6e11-08d6eb257c2b
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 08:52:34.7682 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4153
Archived-At: <>
Subject: Re: [Secdispatch] a proposed path forward on EDHOC/lightweight AKEs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Jun 2019 08:52:42 -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. 


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

    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 ]==
    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
    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.
    Ben and Roman
    Secdispatch mailing list