Re: [Ace] [Secdispatch] EDHOC

Göran Selander <goran.selander@ericsson.com> Thu, 24 January 2019 16:31 UTC

Return-Path: <goran.selander@ericsson.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C91131184 for <ace@ietfa.amsl.com>; Thu, 24 Jan 2019 08:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.873
X-Spam-Level:
X-Spam-Status: No, score=-7.873 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=BrVRgUD9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=k2XRH06Q
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 3RAF4J2cCZNd for <ace@ietfa.amsl.com>; Thu, 24 Jan 2019 08:31:36 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 00DD213117F for <ace@ietf.org>; Thu, 24 Jan 2019 08:31:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1548347494; x=1550939494; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6XV7Zg6kvvC21J4Mi82luJ3Rw9/Oln3DCnf3iiK3lwA=; b=BrVRgUD914kgexCzHsQmVizybOdYCS6r4TfIlRwlwPeswTQEAx/oRgkNghhUm4Ts vp2Gk+Qq7DyDx18mId4jAJbRKZQncskFhP/y7YQfoN4esEfso8zlj8l2/OKBsKXh 1YwyTMDqe4tVcFjEuutvN/C48BsOjGq7H6q1shw1zTQ=;
X-AuditID: c1b4fb30-f93ff7000000355c-6c-5c49e8662ba4
Received: from ESESBMB503.ericsson.se (Unknown_Domain [153.88.183.116]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CE.EC.13660.668E94C5; Thu, 24 Jan 2019 17:31:34 +0100 (CET)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 24 Jan 2019 17:31:33 +0100
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Thu, 24 Jan 2019 17:31:33 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6XV7Zg6kvvC21J4Mi82luJ3Rw9/Oln3DCnf3iiK3lwA=; b=k2XRH06QbOXUfLpRhicW0flk+ZNSiLsFr+gNAoCcMxioJHsqgHL0AkKBdVJfLclSwausRGsO+E64/9jdMy7xF+PI18F/iU7Ndbvekxyxp8H/BTZTOo2s+tTG7z402ejfMh4vfUe6O1li4zqdJprS5Ms/4OvLeV2Qmb+SIM1EJ1Q=
Received: from DB6PR07MB4167.eurprd07.prod.outlook.com (10.168.19.153) by DB6PR07MB3110.eurprd07.prod.outlook.com (10.170.223.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1580.7; Thu, 24 Jan 2019 16:31:32 +0000
Received: from DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4]) by DB6PR07MB4167.eurprd07.prod.outlook.com ([fe80::a10c:961e:8639:85f4%4]) with mapi id 15.20.1580.004; Thu, 24 Jan 2019 16:31:28 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Richard Barnes <rlb@ipv.sx>, Roman Danyliw <rdd@cert.org>
CC: "secdispatch@ietf.org" <secdispatch@ietf.org>, "ace@ietf.org" <ace@ietf.org>, Francesca Palombini <francesca.palombini@ericsson.com>, "John Mattsson" <john.mattsson@ericsson.com>
Thread-Topic: [Ace] [Secdispatch] EDHOC
Thread-Index: AQHUou5Zx1xiDx+jgESY4I5hUyszWqWcqBGAgAINKACAFqIAAIAACQQAgAanMgCAASTpAIABoxCA
Date: Thu, 24 Jan 2019 16:31:28 +0000
Message-ID: <05C8AB73-EFD1-4AC8-A795-D3624153F4D2@ericsson.com>
References: <D629D980-C059-474F-B259-2700F2EEAE41@ericsson.com> <79FD6563-8ADA-4D73-B8D5-C3D70604CD76@gmail.com> <F72354EF-2FB7-41C0-BCA1-6D4511A410B2@ericsson.com> <47F03C99-68C1-4ADB-873D-F01987D66849@ipv.sx> <20190118172714.GJ81907@kduck.mit.edu> <359EC4B99E040048A7131E0F4E113AFC0185795C45@marathon> <CAL02cgQgoxrxzBHk9pCvWwg8n91gpfK=4kReGfFfb=Av8=CoCw@mail.gmail.com>
In-Reply-To: <CAL02cgQgoxrxzBHk9pCvWwg8n91gpfK=4kReGfFfb=Av8=CoCw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.15.0.190115
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-originating-ip: [192.176.1.89]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6PR07MB3110; 6:MoYmL+1rJL1Ok5ij6OlexV+V5RQpWTT4a1CTBe60Jz3TFNdnicVa7ikr4PLL0hrB8aQVl+sRTfrYAKdjz7cGMq0z9LZy56x2xZ1KXhfZptDZHn6kppCenVj7oxpGLGE9vDwFYAqF3Fb3oKWgs0zvxS6zZMx3EGWEzbaGf3JVn+4bRyemaANUgbFuHdujSV1ZQjHshKLgM9BESHwCCjpTDBrMp9H5JOQAYx61LzQ+aZt+hRONwVlOyvZS/22cCT1BbiW7T7chnltp1SrLey3Lwt6t7FstO6SgQ3R9z+JCa1yWKxxtSfpbMf7jdBz1sQG/oY/38W/lwvuDh0bqIHJiupq14pkA29Rb5sUJc1QrfZdUqRkMLpMPfYCECGSDXIkOQV0W/i0OFmOnv12FRltAMOLdO1fS2iWHcJQdpew7UFZRznw/V7mmZc95vdPfGCKIe6thLQyVLtrRO1NyGj+aOQ==; 5:y3FuSbH/Uv3Gw0Xe/9b2WQgjJ9/nzUAkvCH871gdm5c+EhuTIHS3OO+VA0ycwV5f7QXuC8tKShnf/R4msfy204LrF1lgzKd7PvxiYgk/+YrTIeE1L/ZnlqVTOLjz89F8FUoUYnQTDZFKnMWf1SM4iwoOm78XnU3608yyLbYuyKIXydUp1p2tPqdDi9UrWb+JrX/0R9HBpJycmmrTbjsR3w==; 7:9kkhmsP+JllkL/iqDXX8u8hXsqCx0kxfvh8Rl5a6Of+qMADOdausHENU4EsipnTMZNWu3JoIIFeUaDtBp/MIDwsFzdIoZZ6+dF1sCplmZ56bVnzdFBktxBWyQqT5U8JvCH8d9Ui7KZccBMFywWg47w==
x-ms-exchange-antispam-srfa-diagnostics: SOS;SOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(396003)(39860400002)(136003)(189003)(199004)(4326008)(102836004)(86362001)(71200400001)(6506007)(54906003)(71190400001)(26005)(478600001)(58126008)(110136005)(99286004)(186003)(476003)(81156014)(81166006)(8676002)(486006)(25786009)(11346002)(83716004)(14454004)(2616005)(446003)(256004)(14444005)(107886003)(66574012)(36756003)(6246003)(76176011)(316002)(53936002)(85182001)(2906002)(33656002)(6486002)(7736002)(66066001)(229853002)(85202003)(68736007)(106356001)(105586002)(6306002)(6512007)(54896002)(93886005)(3846002)(6116002)(97736004)(8936002)(82746002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3110; H:DB6PR07MB4167.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-office365-filtering-correlation-id: fa6046f1-fc21-4072-68e7-08d682196466
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:DB6PR07MB3110;
x-ms-traffictypediagnostic: DB6PR07MB3110:
x-microsoft-antispam-prvs: <DB6PR07MB311005119BFF0B27241EF069F49A0@DB6PR07MB3110.eurprd07.prod.outlook.com>
x-forefront-prvs: 0927AA37C7
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 9tYvHFDF+eai9d0iaymT3vV8ai3YOwnf1LHlZOz7gcMaoRArHHwuZT/DvjVOYEEMlkWUT1j4PejpOQ7HE4CA2+DB/tfvMdof/zR2xLSALkEsYFae4GjybA8UWiOKRpyhAYhQhMCV0obsKJmc+4a4hlN6csAj7+pmWtSI5pOsXQKOLGizZWu1iBrLyyTRaXYPnCQ93Nl+R8mLEoWjuy12xxhR/Ziab3a4R9B0nNOMfGuKzt743JP8/hqmTfADQa+DT2ArTrG4OuNUSnhkrQW9nz+3ktya+LnkphHA9stQiZCFbW9x6sIuhK2kYNQf1Raf3rfgQlqCKQfqM94ioKjlttW4qCbHHa40L6ApeMQsEI73ZFJNM5DsU56LwYRKrEwZDjckWNdn2ZcOomSkfwQdNEuPOUf3fqsYioopYyT7hDA=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_05C8AB73EFD14AC8A795D3624153F4D2ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fa6046f1-fc21-4072-68e7-08d682196466
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2019 16:31:28.8139 (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: DB6PR07MB3110
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe/7bns3HB2XuodpZQOtpLzRByHtAmVTCiz8ELLKqW9zeN+W lyKamiIqYl5AR6bmKEtNLSExU1NRjMK8lOaNtJmXGQnJtFLJ7V3gt99z/v/n+Z/ncGhS1MeR 0Kp4LaOOV8RKuQKq/Mor7bEbi0Fy797vPL91cz7p9yub61daEOBX/3mMc5qSlTVdkBkMvwlZ cbOeCiHDBP5RTKwqmVF7nQwXRI+3N5GJvflEqslYT+nQ6ywiF/FpwMdh688cykUCWoR7EZjK KnlsYUawNjVoUwwEmGv6KEtB4UIS8rOrSVYpImC1Lt1WzCFIH16iLJO5+Cx81c1ZUxxwANwz LSELk7gNwUvdZQvvxe6QMfqeYj2H4PFKDZflMCjQP7Iyhd2gYcVIWliIT8FUYweHDdOR0Dpf Zw3g40tgvv/JOghhJ1h/V0+wYWKYMFbaVsVgaB8kWXaEpW/bHAs7Yi/IWt/gsL3XIOO5jst6 XKG/9oeN98FwZZ71MQBn8GC4ZZvHCj7Q/7STZAU9F7qaxziscBFWJmoJVviCYKaoziZ4wOCq 3tYdA+mjnagQeet33ZblSCiZKebprWvbw0C5kdIjeuf8CDS2ebGWg1CSN8tj+TBkPaiwsQwW NjqI3Z4qRD9DjhpGExGn9PX1ZNSqSI0mId4zntG+QDu/623LX+9WtLRwphthGknthBWzQXIR R5GsSYvrRkCTUgfhuaFAuUgYpUi7xagTrqtvxjKabuRMU1KxcFNkLxdhpULLxDBMIqP+rxI0 X6JDYmnP4uZyEGWKrpKIzKZccYiz0+ik3bRvQsqTHBwefLU/UNv8UXICzfg0jIxV7gnLpENv 33no0+EkOzrg/ka1vNYuKBCfbwoolfMpZVmK0jV1LSknJLM6yT+4xqXhbtdkj5v3xHTeB+74 T5ekWvGBjtChoeQeZsS4NR/RuH9ESmmiFT4epFqj+AcnNIg8WQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/VRwtaMFSa-ifDDqMEm7FBjj44yo>
Subject: Re: [Ace] [Secdispatch] EDHOC
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 24 Jan 2019 16:31:40 -0000

Hi Richard, Roman, all


Thanks for kind welcome and for progressing the discussion. Apologies for a long email.

From: Richard Barnes <rlb@ipv.sx>


Summing up where I believe the conversation stands now, it seems like what folks are asking for is either:


  1.  An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS), or

2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE)

Göran et al: Do you have thoughts on those points?

Yes. I’ll get back to this later in this email.

It seems like it could be a productive use of an hour or two of virtual interim time to help the group understand one of those lines of argument.

Agree.

--Richard


As requested in a previous email, here is a background.



The work on EDHOC is motivated by the need for an authentication and key exchange protocol for OSCORE (draft-ietf-core-object-security) optimized for constrained-node networks (RFC 7228). OSCORE is applied within the IETF, e.g. in 6TiSCH minimal security (draft-ietf-6tisch-minimal-security), but also requested by other SDOs and industry fora such as OMA Specworks, Open Connectivity Foundation and Fairhair Alliance. The properties of OSCORE motivating its use include: support for CoAP forward proxies, support for change of underlying transports including non-IP, low overhead, low additional footprint and memory to existing CoAP implementations, support for multicast security, security for end-to-end REST.



Given the large interest in OSCORE already before it has become an RFC we anticipate a wide range of deployments. For example, we see an interest for OSCORE in Cellular IoT with traffic running over the cellular air interface control channel, where we can have end-to-end CoAP, but not necessarily end-to-end IP between an application server and a cellular device. Or between an application server and a device behind a cellular gateway. Comparing just these two cases, the difference in capabilities of the devices can be significant which makes it difficult to point at some sort of “reference devices” for benchmarking.



In order to support the low end use cases the AKE must be performant in low bandwidth deployments with battery powered devices restricted in RAM and ROM. Message sizes and round trips have a direct impact on latency, power consumption and battery lifetime, and can be calculated which is the reason for this being a commonly used metric. While it may be more difficult to compare memory and storage requirements, the ability to reuse existing code is an important indication. If a device can support a CoAP stack (in the sense of memory and flash, etc) it is expected to also be able to support OSCORE. Similarly, it is desirable that a device with CoAP and OSCORE implemented should be able to support an additional AKE. Considering that EDHOC reuses CBOR and COSE primitives from OSCORE the additional code for EDHOC can be very limited.



From a security point of view OSCORE requires that the endpoints have agreed on a Master Secret with a good amount of randomness, and each other’s Sender IDs, and those must be different for a given Master Secret.



Now returning to the questions.


  1.  An analysis that shows that EDHOC is equivalent to an existing AKE (e.g., IKE or TLS)


Considering EDHOC is a new protocol it should be thoroughly analysed and verified against all currently known issues of AKEs. Roman sent a mail to the secdispatch list referencing a paper presented at SSR 2018 which could be used as a starting point. How do folks want to digest this: Do they want to study the model themselves or should we ask the authors if they could present their work at the interim?

2. An argument that a new AKE is necessary (vs. a re-encoding of an existing AKE)



We have done this comparison with TLS/DTLS for some time now, and what once seemed like a reasonable question has turned out to be never ending exercise. I do not want to get into IETF archeology but for those who have not followed the discussion some data points could be relevant.



Not long ago, the design of security protocols did not take into account constrained IoT devices. With OSCORE we showed that the message overhead could be reduced by a factor 3 compared to DTLS 1.2 records. Before this comparison it was believed that the record layer was performing well, then the difference in overhead was characterized as insignificant, and then finally a compact format was designed for DTLS 1.3.



With EDHOC we showed that the message overhead of the key exchange can be reduced with up to a factor 4 compared to the current version of DTLS 1.3 (see Appendix E in EDHOC). Before this exercise it was believed that the TLS/DTLS handshake was performing well, then the difference in overhead was characterized as insignificant, and now the discussion has shifted to downsizing the TLS handshake or other protocol.



We are not against optimizations to the TLS handshake, just as we welcome the more optimal DTLS 1.3 records. But TLS was not designed to be an AKE for OSCORE optimized for constrained environments. As I remember, optimizing for message overhead was an explicit non-requirement of TLS 1.3. Reverting those design decisions seems like the wrong way to go: One reason to use TLS would be to reuse an existing implementation. But existing TLS implementation would most likely not compare favorably in terms of code size and RAM. Adding code for compression or re-encoding of the messages would add to that. Re-specifying the protocol with the new encoding may require a new formal verification. To make a more compact code and processing may involve two incompatible message formats of TLS depending on what is being signed. New implementations would be needed.


We think we have done our part of the comparison exercise and that the burden of proof should now be reversed. Could we ask those that claim to have a more performant key exchange protocol for OSCORE and are prepared to do the work to make that plausible and provide the numbers? To be clear: if there is another key exchange protocol suitable for OSCORE which outperforms EDHOC in constrained characteristics and then we are very interested.

And again, with the statements in this mail we neither want to belittle the considerable effort made on formal verification, nor claim that DTLS is not fit for IoT deployments. It is an important hammer in our IoT security toolbox, but at the moment we don’t need a hammer.




Göran