Re: [Ace] EDHOC standardization

John Mattsson <john.mattsson@ericsson.com> Fri, 02 November 2018 12:31 UTC

Return-Path: <john.mattsson@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 BAAD8126F72 for <ace@ietfa.amsl.com>; Fri, 2 Nov 2018 05:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.771
X-Spam-Level:
X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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=FQOF9aZF; dkim=pass (1024-bit key) header.d=ericsson.com header.b=AfueUNJN
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 T4OwHGxigkdN for <ace@ietfa.amsl.com>; Fri, 2 Nov 2018 05:31:20 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 0403D124C04 for <ace@ietf.org>; Fri, 2 Nov 2018 05:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1541161877; x=1543753877; 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=asqj5VsIyauaIspZtHKNBZnifIaek7bnZgTGRV5FwUk=; b=FQOF9aZFjIKE1ufe2OTYUoSE/oS9Mur1nzd+AUvQr8SHt+JCKMeOOmaYKmj37T6C kv74srt28uTvIsAQYlIBuq/qnM3t8IXUcCO4PEYfsjeKaMOrtPynwvMj0rC0xFyB Ht4gPUhyGXSmFjQqhAXB7NOkkRYcVqmgSoJXS63EIbY=;
X-AuditID: c1b4fb2d-425ff7000000434d-23-5bdc4395a422
Received: from ESESSMB504.ericsson.se (Unknown_Domain [153.88.183.122]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D4.57.17229.5934CDB5; Fri, 2 Nov 2018 13:31:17 +0100 (CET)
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 2 Nov 2018 13:31:17 +0100
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) 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; Fri, 2 Nov 2018 13:31:17 +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=asqj5VsIyauaIspZtHKNBZnifIaek7bnZgTGRV5FwUk=; b=AfueUNJNhXPmcy3laM60j3cUeFRHcJLqbcjkW83U6rRGP3L9VhbESBKncKHcXjUCO+azwLEIuThrAQ8u1AfTYIcNKx9Ovjq8nAVmQ0U6s0PYN6CdvDD0Znvew8Cw299P6olPAK0ifh+d0Y1l8kedhJlgr7EIkgIkER4RzZ+eUOg=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3483.eurprd07.prod.outlook.com (10.170.247.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Fri, 2 Nov 2018 12:31:16 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::fcb5:ca45:9e56:1910]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::fcb5:ca45:9e56:1910%2]) with mapi id 15.20.1294.024; Fri, 2 Nov 2018 12:31:16 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "alvador.p.f@um.es" <alvador.p.f@um.es>, "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: [Ace] EDHOC standardization
Thread-Index: AQHUcqfzc6iiUOECiUamNJ4vyfghjw==
Date: Fri, 2 Nov 2018 12:31:16 +0000
Message-ID: <379B1A31-1F7E-43A6-A518-4398570CBBC7@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.11.0.180909
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [82.214.46.143]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB3483; 6:YbL9CQJvcx/NV+Tih8zUHh554WZf+xPjVBgeNtW8t9TFJg3Gwy1SI6PdwjRWpSTfXYyAHVgzMej3R7aqvV/ev7IdGLdX/fe40fcXgVlHIB3dcpAHMqA/cJDl2vAXcNF+1uLpns7Sk9dQ+DAJr98eVD9jGzDBUrwqZAIffpkyDp/ZNoQ2WzS0Lz0if7+bk2QKzL79NVR3ksaxiA/+otAYE/ljsEUAQ9FrnOT+CfkAqIT/VqWX3yZM33G+SDZxYdOc76MzIFzd+55sabZSxavalaGBBRw8ggWYd1DqgQz2gm91AsEZbt7tb2g9AQn+xchnR8/Fo3vKPRE8A7QGBKieCT8uCfbMuCJpBMV6QtQxYRBXxRmehpdHnQ6WUNIotNC8TlMs/vFS6PPj/NBhdta+6y8NdFbe4Kg4g4yX6hUXlbFQqMBf66G/yhBTEEg70sGQLdk2DmlcIlRDNmkCs+vaDA==; 5:NH35vAGGW0M+RgN4Pxb9PQGm+Gy2RvLq7d8EoPzGAaBiDDYfeoMqZigO682DUXHExz45LkYv2z5yd+y2gId/lFN6fOdxD4gbl6OWCqTEnBBJviMRncuPi4PkD0/we/MSdr3hDQzFcYMIe81WJKRP+S4dWfpA+gnh8VT2hg1swI4=; 7:JvY3sm5MahJRvTQQQHhQ5T/tF1scmzRkZ8veim9y5rTflnNvrd4cqUP7kguf9LsrVVxJTIyvc3lzISueGjf8aPmUHR7PqMi1YMN2i7kSsHLUCnLYZkZSTCdmjercGicts7Wh3t4+SN4iwPk+R/b14A==
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 3c71bf24-7fd6-47eb-560d-08d640bf159c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3483;
x-ms-traffictypediagnostic: HE1PR07MB3483:
x-microsoft-antispam-prvs: <HE1PR07MB34836CE93B17A8ED03133C1F89CF0@HE1PR07MB3483.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(166708455590820)(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201708071742011)(7699051)(76991095); SRVR:HE1PR07MB3483; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3483;
x-forefront-prvs: 08444C7C87
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(366004)(136003)(39860400002)(189003)(199004)(51444003)(6512007)(476003)(7736002)(229853002)(486006)(106356001)(6306002)(71200400001)(71190400001)(105586002)(83716004)(99286004)(478600001)(110136005)(2616005)(86362001)(66066001)(6506007)(97736004)(256004)(14444005)(5024004)(305945005)(44832011)(316002)(2900100001)(58126008)(6246003)(102836004)(2501003)(186003)(25786009)(5660300001)(53936002)(26005)(82746002)(14454004)(966005)(81156014)(81166006)(36756003)(8936002)(2906002)(3846002)(6116002)(33656002)(6486002)(68736007)(6436002)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3483; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: uepLo2+znlsxlzT7YZd3f9AeNCjd3MxF4pXCYls54rQAwKbTIGSttKLm1IoW5+0VDwvG8MLEyi/0FPwWo42wWWxL5fOZOR02ctRdCeLamDrQ4iXt2o7S2KpdF0ZUCoxqIYJV71V4XF1uCSMgHUWD0SUMlH2aF/Rmp4xK/K+Lsy87aW2iGVXxmH56D/pyz7QmobhQ+PLSZCUtvSBn6wRLHF37dAM5W0SK21TtR3Cuh+wrabRhmpw0ucPAJgEqkFaK4aXivzIm6PMkrHsR0EaBUHtaQvN2ITar420Gc3NGgmkrIFKghYfiqAtNaWPGZz6iezFm9XdVnskKHeVdistdt6XHv5dlNE7yBcazBQ8Fij0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <479C323C8E96A1468B2F900D660C8493@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c71bf24-7fd6-47eb-560d-08d640bf159c
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2018 12:31:16.4261 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3483
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNKsWRmVeSWpSXmKPExsUyM2J7le5U5zvRBi0TNSy+f+thtljXfYXV oudQP7sDs8eSJT+ZPFrm7GH2OPeyjSWAOYrLJiU1J7MstUjfLoEr4/eG3ywFk3Qqphxewd7A 2KDdxcjJISFgIjHz1GeWLkYuDiGBI4wSz76eZ4VwvjJKLL26H8pZzCTx9uZkRhCHRWACs8T3 qUeheiYzSbx7PZMJwnnIKDHjdjsjyGQ2AQOJuXsa2EBsEYFaic9bDrOD2MICGhIbu7ayQ8Q1 Jaa++MgEYetJfG87BBZnEVCRuPZwPZjNK2Av8WB9FzOIzSggJvH91BqwemYBcYlbT+YzQXwh ILFkz3lmCFtU4uXjf6wgtqiAvsT8Bx2sEL2xEq2t01khahQlTu9bAVUvK3FpfjcjhH2NTWLN OSUIW1fiw9SpUDW+ErOXXwGHhYTAcUaJDx0roQZpScx7PQfqiGyJ3StWQA3ykdh05yWULSex qvchC1Qzs8TMrqtQCRmJOQ1v2CYwGsxC8tAsRg4gW1Ni/S59CNNDorndBKJCUWJK90P2WeBg EZQ4OfMJywJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgUnm4JbfujsYV792PMQowMGo xMPro3gnWog1say4MvcQowQHs5IIr9v729FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEefVW7YkS EkhPLEnNTk0tSC2CyTJxcEo1MFpP7xcqfhOjuStmDaNCfaP84cVVpa/Cjs6vV8n8urBA9nl/ rRIfo9nTmC9qtY+zjCxdzXvWyb+8JHXKZkn/vMczlBZl1fc6xnSEtshp6a5SMeSQLGm+G8FV lBxavim/5oJU4K03Gv7yr82Sa5+u4I7+/OSr35fgfvOqqxd1f+8qKHF1irivxFKckWioxVxU nAgA6Y5gES4DAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/aALvRo1tnSkHjsbvj2xi_7q1fI8>
Subject: Re: [Ace] EDHOC standardization
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: Fri, 02 Nov 2018 12:31:23 -0000

Hi Salvador, Michael,

Regarding your comments on negotiation and out-of-band. We have gotten similar comments from Klaus Hartke regarding cipher suites and out-of-band. I added your comments to the open issue on GitHub

https://github.com/EricssonResearch/EDHOC/issues/57

We agree with you both, this can and should be optimized, but some kind of negotiation is still needed. The current plan for the next version is to introduce cipher suites and to let the cipher suite with value 0 indicate that algorithms have been negotiated out-of-band. For the constrained deployments targeted by EDHOC, I think this might be the best trade-off between negotiation, overhead, and simplicity. While I think TLS 1.3 did the right thing to split up the cipher suites, I agree that for most constrained IoT deployments, the implemented algorithm(s) will often be the same for all nodes and fixed for long periods of time. As you stated Salvador, this would be an an important optimization. The message sizes would look as follows:

                 PSK       RPK       x5t     x5chain
   --------------------------------------------------------------------
   message_1      43        38        38        38
   message_2      47       121       127       117 + Certificate chain
   message_3      12        86        92        82 + Certificate chain
   --------------------------------------------------------------------
   Total         102       245       257       237 + Certificate chains

                 Figure 6: Typical message sizes in bytes

Cheers,
John

Michael Richardson wrote:

    > we have implemented a previous version of EDHOC
    > (draft-selander-ace-cose-ecdhe) and want to share some experiences.

That's very cool.
Some questions for you!

    > Our work so far has focused on implementation and evaluation of version
    > -08 of EDHOC over CoAP using real IoT hardware. The obtained results
    > show a significant performance improvement compared to other key
    > establishment protocols, such as DTLS handshake (version 1.2),
    > especially with respect to length and number of exchanged messages.

What did you use for authentication?  RSA? ECDSA? EDDSA? PSK?
Were they raw public keys, or was it in a certificate?
Did you try a certificate in one direction and a raw public key in the other?
Did you offer more than 1 algorithm when you negotiated?

    > We have reviewed version -10 and noted the reduction of message
    > length. Based on our experience, we propose that also removing the
    > overhead due to security parameter negotiation could be an important
    > optimization, and relevant in many use cases where these parameters are
    > available through an out-of-band process.

If the list of valid algorithms is available securely by out-of-band
processes, then couldn't use this mechanism to do key agreement instead,
saving 100% of the bytes on the wire?  :-)

We need to do security parameter negotiation in order to be agile against
future algorithm attacks, and there will be algorithm attacks in the 20 to
40 year lifespans that we expect... and we need to leave space for replacing
the DH process with some QMDH process.  The CBOR encoding is really really
very nice for this, and I wish we had CBOR when we did IKEv2.

    > Accordingly and taking into account that EDHOC provides a basic
    > security functionality for any context where security needs to be
    > enabled, we are currently considering the application of this protocol
    > in different IoT deployments, such as LoRaWAN networks, OSCORE-enabled
    > scenarios or its integration with capabilities. We therefore would like
    > to see the progress of EDHOC in standardization.

I don't see how LORaWAN has enough bytes available for even EDHOC.
I think that LoRaWAN needs a key agreement protocol that can be run once
while the sensor is attached to the installer's smartphone.  The important
thing is that one is able to use the key agrement protocol over IPs A<->B,
in order to setup a context that can be used between IPs C<-->D.