Re: [Secdispatch] EDHOC Summary

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Tue, 16 April 2019 07:18 UTC

Return-Path: <Hannes.Tschofenig@arm.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 177F41201B3 for <secdispatch@ietfa.amsl.com>; Tue, 16 Apr 2019 00:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=armh.onmicrosoft.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 YUPvoAjJItgR for <secdispatch@ietfa.amsl.com>; Tue, 16 Apr 2019 00:18:38 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10064.outbound.protection.outlook.com [40.107.1.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B69B120346 for <secdispatch@ietf.org>; Tue, 16 Apr 2019 00:18:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KrNh+/jhubLICUQVWtREMtnAVJhIJ6x6ogZFaHj+PMc=; b=WdEaxg9fPP0nF6LTIxM1U+sgJM9JURCuzGyUwNq8SdY/ONI+Qp96ZJec5iVvarDBXoNejwXLYRQZOZ4VSreZd0WejhNtWc/FCf5CCpO+CfgmatNBDrT7TY0mdI5zdlb4zuLKP/rRwyOSa8edvM9SVloi7lIIV1kymfk+ggWkdLI=
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB3350.eurprd08.prod.outlook.com (52.135.165.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Tue, 16 Apr 2019 07:18:33 +0000
Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.020; Tue, 16 Apr 2019 07:18:33 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: "Owen Friel (ofriel)" <ofriel@cisco.com>, Göran Selander <goran.selander@ericsson.com>, Richard Barnes <rlb@ipv.sx>, Michael Richardson <mcr+ietf@sandelman.ca>
CC: Carsten Bormann <cabo@tzi.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>, Martin Thomson <mt@lowentropy.net>
Thread-Topic: Re: [Secdispatch] EDHOC Summary
Thread-Index: AdTzyofk3GE/98irTDSVd9BUcvG+cwAWPHFQ
Date: Tue, 16 Apr 2019 07:18:33 +0000
Message-ID: <AM6PR08MB368674B7799F15E103389E9AFA240@AM6PR08MB3686.eurprd08.prod.outlook.com>
References: <CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0@CY4PR11MB1541.namprd11.prod.outlook.com>
In-Reply-To: <CY4PR11MB1541D6FD27E0FBD478FCF362DB2B0@CY4PR11MB1541.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [80.92.121.58]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7b482782-77d9-41a1-6682-08d6c23bbc63
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB3350;
x-ms-traffictypediagnostic: AM6PR08MB3350:
x-microsoft-antispam-prvs: <AM6PR08MB3350682C06C43F39BB64034AFA240@AM6PR08MB3350.eurprd08.prod.outlook.com>
x-forefront-prvs: 000947967F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(376002)(39860400002)(366004)(199004)(189003)(40434004)(229853002)(6246003)(99286004)(9686003)(6436002)(236005)(26005)(53936002)(14444005)(71200400001)(68736007)(5024004)(54896002)(256004)(55016002)(6306002)(316002)(54906003)(66574012)(110136005)(71190400001)(102836004)(66066001)(446003)(11346002)(476003)(86362001)(97736004)(14454004)(33656002)(478600001)(486006)(105586002)(186003)(7696005)(81156014)(25786009)(4326008)(81166006)(106356001)(8936002)(8676002)(2906002)(52536014)(76176011)(7736002)(3846002)(5660300002)(74316002)(790700001)(6116002)(6506007)(53546011)(72206003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3350; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: oiQS6pjJQyLZ6UJZaT6F0zLxARz89ftVTMwuYHtOeW7uuqtGD6Oir9CILy9M2Iex5BW5p0i+ksxUv4sB+0Vgp92Qgt5dKA1Byp/YFgKl/gvLqk1Ll0dCg1w30Xh2ZcqO0xvBI7O9TKlxD0c0zmwF8JP30XPbi6N9zgHRkvm+24Gce3tYk3fLENz/9UG1QzMD+gef1JDkvSqaXFmtLAX+ghFbQt+KJFLdYu/u61TSUlcL3coFA5pv6xNmhdbb0+P3n79B3Q7q4O2RD9KbEo+T6RLBJcQQkE14wO5QGadvgEhAa8HPvflu2NAi9Ce6ymA7IhkN55wOgBO/RPS06jeZtJaj35noL3YxuBd964fl7OqQhS96ikqoIGMNSS9hwjPs+wanMkhO85MaogwRB3wZH+987hZbn6JljfwFpIOnExI=
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB368674B7799F15E103389E9AFA240AM6PR08MB3686eurp_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7b482782-77d9-41a1-6682-08d6c23bbc63
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2019 07:18:33.7993 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3350
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/NA-esxCpSOmR5A3UBkBpUh9-PjA>
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: Tue, 16 Apr 2019 07:18:43 -0000

Owen, I am fine with creating a new working group as you suggested below to work on a lightweight AKA.

However, I need to state that there isn’t even a problem with DTLS/TLS 1.2 in IoT networks. The handshake itself is such a small part of the overall communication in the life of an IoT device that focusing the optimization efforts on the handshake is almost ridiculous. Of course, no protocol designer wants to hear that there are system aspects that play a much bigger role in reducing power consumption.

If you consider that the top IoT companies use MQTT protected with TLS using certificates today in their large deployment today then you might even wondering where the large disconnect comes from.

From: Secdispatch <secdispatch-bounces@ietf.org> On Behalf Of Owen Friel (ofriel)
Sent: Montag, 15. April 2019 22:48
To: Göran Selander <goran.selander@ericsson.com>; Richard Barnes <rlb@ipv.sx>; Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Carsten Bormann <cabo@tzi.org>; secdispatch@ietf.org; Martin Thomson <mt@lowentropy.net>
Subject: Re: [Secdispatch] EDHOC Summary

It seems as if a path forward is a new LAKE WG, not a specific EDHOC WG. Its pretty unanimous and uncontroversial that a lightweight AKE is needed for constrained networks. EDHOC and cTLS are two candidate LAKEs, but neither is a predetermined starting point, let alone winner, yet.

On 12/04/2019 00:08, Göran Selander wrote:
> Hi Richard,
>
> On 2019-04-11, 21:21, "Richard Barnes" <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
>
>     On Thu, Apr 11, 2019 at 3:15 PM Michael Richardson <mcr+ietf@sandelman.ca <mailto:mcr%2Bietf@sandelman.ca<mailto:mcr+ietf@sandelman.ca%20%3cmailto:mcr%2Bietf@sandelman.ca>>> wrote:
>
>
>     Richard Barnes <rlb@ipv.sx<mailto:rlb@ipv.sx>> wrote:
>         > I'd like to push back on this point. It may be that EDHOC has been around for
>         > a while and been well-socialized with the IoT crowd, but it is clearly
>         > deficient in several other types of maturity, e.g., robustness of formal
>         > analyses and state of implementations (AFAICT).
>
>     I want to be sure that I understand you.
>
>     Is it your opinion tha the IETF can not form a WG until after a protocol has
>     had formal analysis?  How many analysis?  How many years?  Which publications?
>
>
>     I didn't mean anything w.r.t. the formation of a WG.  Carsten's implication seemed to be that an EDHOC WG could deliver more quickly than, e.g., one using TLS as a starting point.  That's the point I was pushing back on -- I hope we agree that delivering
>      a final security protocol should be gated on robust analysis and multiple implementations.
>
> [GS] As I mentioned in my recent reply, given the changes you make to TLS to make message sizes on par with EDHOC, it is a new protocol so the statement about relying on the analysis of TLS is questionable. Comparing implementations there are clearly more of TLS, but, again, this is a new protocol.
>
> Göran
>
>
>
>     --Richard
grsdfsdf
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.