[secdir] EDHOC and Transports

Jim Schaad <ietf@augustcellars.com> Fri, 25 January 2019 05:08 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 11F40129508 for <secdir@ietfa.amsl.com>; Thu, 24 Jan 2019 21:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RE3kqkySz11R for <secdir@ietfa.amsl.com>; Thu, 24 Jan 2019 21:08:32 -0800 (PST)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B2B128D09 for <secdir@ietf.org>; Thu, 24 Jan 2019 21:08:32 -0800 (PST)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 21:08:26 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: secdir@ietf.org
Date: Thu, 24 Jan 2019 21:08:23 -0800
Message-ID: <00ac01d4b46c$00f9de30$02ed9a90$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdS0aYd+IIiEJdHOSfGMDJ3y6un6LA==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/s1cc7MCGSrtCmoZQJazt7MoImIs>
Subject: [secdir] EDHOC and Transports
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jan 2019 05:08:34 -0000

Someplace over the set of messages which I recently scanned one of the
questions was what were the constrained restrictions that we were looking at
as part of the evaluation process.

There are three that I will highlight even though I am only able to provide
any type of quantification for two of them:

1.  Low-power devices that either are battery based or scavenge power, these
devices pay a power penalty for every byte of data sent and thus have a
desire for the smallest messages possible.

2. CoAP over SMS:  SMS has a 140 byte packet size.  There are two approaches
for dealing with packets of larger than 140 bytes:  1) There is a method of
appending multiple packets together to form a single larger packet.  2) You
can use CoAP blockwise transfer.  Using CoAP blockwise would result in 128
byte packets for the underlying transfer assuming that only 12 bytes are
needed for the CoAP header itself.

3. 6LoPan over IEEE 802.15.4:  This has a packet size of 127 bytes.  The
maximum frame overhead size is 25 bytes allowing for 102 bytes of message
space.   If one assumes 20 bytes of overhead for CoAP then this means a
protocol packet size of 82 bytes.  If one needs to break the message across
multiple packets then the maximum data size is going to be 64 bytes using
CoAP blockwise options.

There are of course two additional transports which are to be considered
IPV4 UDP and IPV6 UDP.  Both of these transports have a packet size which is
sufficiently large to hold a any given message using TLS or EDHOC.