Re: [Secdispatch] EDHOC Summary

Tero Kivinen <kivinen@iki.fi> Thu, 11 April 2019 22:16 UTC

Return-Path: <kivinen@iki.fi>
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 C3AED1201E7 for <secdispatch@ietfa.amsl.com>; Thu, 11 Apr 2019 15:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.42
X-Spam-Level:
X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Wu45OXD4jNWM for <secdispatch@ietfa.amsl.com>; Thu, 11 Apr 2019 15:16:25 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4BD1201C0 for <secdispatch@ietf.org>; Thu, 11 Apr 2019 15:16:24 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x3BMGEK9022579 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Apr 2019 01:16:14 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x3BMGDkJ016427; Fri, 12 Apr 2019 01:16:13 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23727.48301.311217.991808@fireball.acr.fi>
Date: Fri, 12 Apr 2019 01:16:13 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: Christopher Wood <caw@heapingbits.net>, "secdispatch@ietf.org" <secdispatch@ietf.org>
In-Reply-To: <D7468312-88B4-4546-9D72-8895780A6DD4@ericsson.com>
References: <359EC4B99E040048A7131E0F4E113AFC01B3311A9F@marchand> <012a4798-fc70-4b5d-b0da-373221c95d38@www.fastmail.com> <721B6044-8DA1-4173-BE73-87D37136DFEE@ericsson.com> <1bfbef5a-027a-460e-b421-fb4c3a82e583@www.fastmail.com> <D7468312-88B4-4546-9D72-8895780A6DD4@ericsson.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 9 min
X-Total-Time: 8 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/kCcciglpwd9FaK9271_0TsZKXr8>
Subject: Re: [Secdispatch] EDHOC Summary
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: Thu, 11 Apr 2019 22:16:28 -0000

John Mattsson writes:
> constrained some of them are. For the target network technologies
> LPWAN over LoRaWAN and 6TiSCH over IEEE 802.15.4, the requirements
> for message size are clear (under 50 bytes).

IEEE 802.15.9 specifies how to use KMPs in IEEE 802.15.4, and it
provides fragmentation of larger messages, so message size limits are
not absolute in IEEE 802.15.4 environment. Of course the fewer
fragments are needed the more efficient the protocol will be, but
there is no absolute limit that is required.

Some of the PHYs in IEEE 802.15.4 support larger frame sizes (up to
2048 bytes) and some of them support smaller (smallest are 20-30 bytes
or so, but that PHY also includes another layer of fragmentation).

The most common maximum frame size is 127 bytes, including header, and
the header is usually less than 20 octets if no security header is
used (which normally is not used for key management protocols as there
is no keys yet). Even with security the overhead is usually about 12
bytes more, thus the total overhead is around 20-40 bytes. This means
there is space for around 80-100 bytes of actual frame payload for
IEEE 802.15.4 in normal cases.

Targetting for 50 bytes is quite pessimistic for IEEE 802.15.4.
-- 
kivinen@iki.fi