[Secdispatch] brief feedback on draft-selander-lake-reqs-00
Rene Struik <rstruik.ext@gmail.com> Mon, 15 April 2019 18:38 UTC
Return-Path: <rstruik.ext@gmail.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732561200D8 for <secdispatch@ietfa.amsl.com>; Mon, 15 Apr 2019 11:38:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV_LQIw8rCgM for <secdispatch@ietfa.amsl.com>; Mon, 15 Apr 2019 11:38:37 -0700 (PDT)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA85B120046 for <secdispatch@ietf.org>; Mon, 15 Apr 2019 11:38:37 -0700 (PDT)
Received: by mail-io1-xd29.google.com with SMTP id n11so15458668ioh.1 for <secdispatch@ietf.org>; Mon, 15 Apr 2019 11:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=FAo+swbpbs9cdML1z7iEVaCtQm+cUTSdPGVLMdl9wxI=; b=kxnk9pQ+klmQHS3lRV4t8Jlu1keqTzKGk0+R7ipKd2bBpEN6XyLtysF+OvZ7hLuxtV LUBHr3n1IwYfW887BIwG8JtJid803McWp07DylRvbXMTR56sCJPT5T8sbf25lMGHVIMJ 9HYRrMTL6jSscazrIkF/6cWQuvNSppEmb5qykaite+hYCCk3iwH7OBrqWTv31C+UVFUI KpWH2Lfli5iEP+ZoJoR1ksNIFCZU1Wm/TH/+TcGH4CiR4ImR+v54GJJJT/p+y+evI8FE IrRJO/Uk36x47s9ry44U9fg93NqKHsQNppP3BotjDtl6MFG+lez+63CGoNHre5eMZQD+ /ccw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=FAo+swbpbs9cdML1z7iEVaCtQm+cUTSdPGVLMdl9wxI=; b=Agi3os7XA7nc49860SQvO/zgHDWD69lQK2eBBkWl5J60BxzkY9yDVE9qTQfp5OZhEq COwTo0CyiwcMWdu75fwwFFutE5FQFQ8IYLdyuZd5m3/5BnE8Y0qLE0OeNVzj5WUqiGJG qXX0HyZZ3KR3MJ+BvBSt1+XnHCPSgsCFg7gjtw0JjLpQ9S/5p3RWa+uPUb5c4dExjXDb OpBZ/x92e/TOXkzGkCTcFm3s+XZs0DomX5CwsJb2qmJlGR3Aj+jZS0aTRJysxpILjF3G UtL5kBS3h+oygfspgBo3haTjG0VR6ony6Y2W4Md8+R9YVL1m0+XIHTYo/qD65EpxX9TH d70w==
X-Gm-Message-State: APjAAAXnN1HzSim3rKo6Rm1KvxZZifgZfP6tWjgUgsFD5BNwxn1hyS+V isS7WZc+ThG6bHGn5JM7fsy/mJ5x
X-Google-Smtp-Source: APXvYqxXNC93+GgK+xrA2R3r8ic0y/pN6qmgK0Noi/2h1NWXs/s/ZEYL+FFqS85etj2vv5keNMmzFQ==
X-Received: by 2002:a6b:3f86:: with SMTP id m128mr42542944ioa.275.1555353516848; Mon, 15 Apr 2019 11:38:36 -0700 (PDT)
Received: from ?IPv6:2607:fea8:69f:f5eb:fc5f:12b:d173:619a? ([2607:fea8:69f:f5eb:fc5f:12b:d173:619a]) by smtp.gmail.com with ESMTPSA id q8sm17826498ioi.33.2019.04.15.11.38.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Apr 2019 11:38:36 -0700 (PDT)
To: Göran Selander <goran.selander@ericsson.com>, "secdispatch@ietf.org" <secdispatch@ietf.org>
References: <155507882604.16959.2935532240318784994.idtracker@ietfa.amsl.com> <D054DAE0-DD1C-494E-8E42-FA15DB0F618F@ericsson.com>
From: Rene Struik <rstruik.ext@gmail.com>
Message-ID: <7a604b70-1c6a-e799-f30c-c9369e62d8d0@gmail.com>
Date: Mon, 15 Apr 2019 14:38:33 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <D054DAE0-DD1C-494E-8E42-FA15DB0F618F@ericsson.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/JFc3nu2Jk3e-MmJ0CfVT2H8ioVU>
Subject: [Secdispatch] brief feedback on draft-selander-lake-reqs-00
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2019 18:38:41 -0000
Dear Goran: Some brief remarks on draft-selander-lake-reqs: a) duty cycle (see Section 4.2.1 - LoRaWaN): Duty cycle depends on context (e.g., duty cycle during Tx of a single frame is always 100%). According to ETSI [1], Section 5.4.1, duty cycle is relative to observation time window (Tobs) of 1 hour, where conformance ([1], Section 5.4.2), is defined relative to normal use during operational lifetime, where "the representative period shall be the most active one in normal use of the device. As a guide "Normal use" is considered as representing the behaviour of the device during transmission of 99 % of transmissions generated during its operational lifetime", and where "Procedures such as setup, commissioning and maintenance are not considered part of normal operation". This does suggest that inter-frame spacing is not necessarily 99 frames for each frame sent, as this section seems to claim. In fact, if key agreement is only done as part of network formation, it falls outside the duty cycle regulatory requirement. b) few messages/few frames (Section 4.2 - Discussion): The suggestion that a 3-message protocol is a requirement seems to be more an opinion/preference by the author, since lacking detailed technical justification. {If sending an additional frame causes "the probability of errors [to] increase exponentially", the medium access control layer seems to be unfit for use. Or, do you mean that if error probability is p, one gets prob no error in t frames equals (1-p)^t? If so, with small p with viable networks and small t, one definitely has (1-p)^t ~ 1 - t*p (i.e., almost linear degradation rather than the more dramatically sounding exponential).} c) conflicting requirements (Section 4.1 - AKE for OSCORE vs. Section 4.2 - Lightweight): There are trade-offs between communication overhead and security properties, which generally should be explored in more detail before imposing a requirement. As an example, a strict requirement for PFS may necessitate increased communication overhead, since, e.g., a communication failure during an AKC-scheme with strict PFS may preclude reusing this keying material with a retry mechanism. d) security considerations (Section 6): Contrary to what is suggested, the document is mostly about "size" arguments and does not offer a definition of desired algorithmic and operational security properties for sensor networks. e) protocol flavors (Section 2): The suggested protocol options include authenticated key agreement using symmetric-key, raw public keys, and certified public keys. Another option, which may be worth exploring (even if discarded based on sound rationale) is a key agreement scheme where authentication is based on a short secret authentication string (password) or a short public authentic, yet not secret string that is provided by a user (see, e.g., [3]). f) COSE algorithms (Section 4.1): The algorithms in the current COSE specification (RFC 8152) may not have a rich enough set of primitives to instantiate the sought after authenticated key agreement protocol. As an example, to my understanding, COSE only facilitates use of static-ephemeral co-factor Diffie-Hellman. Thus, some changes to the COSE specification may be required if one wishes to use a protocol that uses co-factor Diffie-Hellman based on ephemeral key shares. (Of course, this may be easily facilitated, esp. if the underlying core crypto primitive is already defined). These comments illustrate that some requirements are less clear-cut than as suggested in draft-selander-lake-reqs-00 and, that, in fact, there may be more to this than just a "smaller is always better" argument. Rene Ref: [1] ETSI EN 300 220-1 V3.1.1 (2017-02); [2] ETSI EN 300 220-2 V3.1.1 (2017-02); [3] Authenticated Key Agreement - Using Short Authenticated Strings (Serge Vaudenay, Crypto 2005) On 4/12/2019 12:20 PM, Göran Selander wrote: > On request I compiled the requirements for the lightweight AKE for OSCORE discussed on the list into a draft. This is not exactly the formulation by the security ADs but the main requirements should be there. > > Göran > > On 2019-04-12, 16:20, "internet-drafts@ietf.org" <internet-drafts@ietf.org> wrote: > > > A new version of I-D, draft-selander-lake-reqs-00.txt > has been successfully submitted by Göran Selander and posted to the > IETF repository. > > Name: draft-selander-lake-reqs > Revision: 00 > Title: Requirements for a Lightweight AKE for OSCORE. > Document date: 2019-04-12 > Group: Individual Submission > Pages: 7 > URL: https://www.ietf.org/internet-drafts/draft-selander-lake-reqs-00.txt > Status: https://datatracker.ietf.org/doc/draft-selander-lake-reqs/ > Htmlized: https://tools.ietf.org/html/draft-selander-lake-reqs-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-selander-lake-reqs > > > Abstract: > This document contains the requirements for a lightweight > authenticated key exchange protocol for OSCORE. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > Secdispatch mailing list > Secdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/secdispatch -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [Secdispatch] FW: New Version Notification for dr… Göran Selander
- [Secdispatch] brief feedback on draft-selander-la… Rene Struik
- Re: [Secdispatch] brief feedback on draft-selande… Göran Selander