Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization
Göran Selander <goran.selander@ericsson.com> Tue, 05 March 2019 11:42 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 12EE9131270 for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 03:42:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level:
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=drGx3Qe/; dkim=pass (1024-bit key) header.d=ericsson.com header.b=R2CXgHyV
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 oWOuEX_srt5D for <ace@ietfa.amsl.com>; Tue, 5 Mar 2019 03:42:09 -0800 (PST)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 BEA76131271 for <ace@ietf.org>; Tue, 5 Mar 2019 03:42:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551786124; x=1554378124; 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=sadSBt2S943WWLGrqYOWFra5zzlbdOIzDlghmfwjt4c=; b=drGx3Qe/inafdW7ngmFVQ4+jiw575od0UFDc8kILPCjgKXSq3lmVjVJl4GIsieP2 uN1DevWZragLUZyzaRqII7OjzB9I8zlyfYz7I5zClZV4GRUHyLQGOHSdBtqATeGH M9vtewTQLgml2QA+SvwMnnYgKBRDOL1mOmlH/59SNIE=;
X-AuditID: c1b4fb3a-14fff7000000672c-60-5c7e608c1bb0
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9F.B8.26412.C806E7C5; Tue, 5 Mar 2019 12:42:04 +0100 (CET)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESBMB505.ericsson.se (153.88.183.118) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 12:42:03 +0100
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 12:42:02 +0100
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.157) 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 via Frontend Transport; Tue, 5 Mar 2019 12:42:01 +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=sadSBt2S943WWLGrqYOWFra5zzlbdOIzDlghmfwjt4c=; b=R2CXgHyVLJd3MnUmsbce0XsppQgnzd+ffaJSbxBr52I5cR47AGeEYKOV7tkVyPauW16fD3mb22mz2+aXyB2RRKKHLyRin58R/giV8dbCiFv0LyA/QW9kySsDPnxy/aMG52BSZQxqYxraUYI/vDxlpbWXAC1fub4F8oh3mdfFDF4=
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com (20.176.166.25) by HE1PR07MB3132.eurprd07.prod.outlook.com (10.170.245.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.9; Tue, 5 Mar 2019 11:41:58 +0000
Received: from HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::ec09:4e6b:509a:c86e]) by HE1PR07MB4172.eurprd07.prod.outlook.com ([fe80::ec09:4e6b:509a:c86e%2]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 11:41:58 +0000
From: Göran Selander <goran.selander@ericsson.com>
To: Rene Struik <rstruik.ext@gmail.com>, John Mattsson <john.mattsson@ericsson.com>
CC: "secdispatch@ietf.org" <secdispatch@ietf.org>, 'Benjamin Kaduk' <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: (details on use case scenario?) Re: [Lwip] [Ace] EDHOC standardization
Thread-Index: AQHU0tUzmKd7qLDRs0yXrXayhiGvPKX8+/mA
Date: Tue, 05 Mar 2019 11:41:58 +0000
Message-ID: <985573C6-A4A6-4CDE-BDC6-6E53EE80C025@ericsson.com>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com> <20181103145857.GG54966@kduck.kaduk.org> <7F78CC92-5C48-4BFC-8087-E25D4D95A74F@ericsson.com> <000001d481ae$57cd4530$0767cf90$@augustcellars.com> <B119A1D8-08B5-431E-BB16-35D84AA6F6CB@ericsson.com> <8155ccb8-6b44-cd49-caae-8915ef0cef7d@gmail.com> <89483a94-8c12-9fc7-a4ed-75fb250beb14@gmail.com>
In-Reply-To: <89483a94-8c12-9fc7-a4ed-75fb250beb14@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.1.190220
x-originating-ip: [213.89.213.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9d3d655a-5c7d-42fa-6602-08d6a15f9369
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3132;
x-ms-traffictypediagnostic: HE1PR07MB3132:
x-ms-exchange-purlcount: 10
x-microsoft-exchange-diagnostics: 1;HE1PR07MB3132;23:FdSUF3x+IPfj/67qqvAHghhQllty89QS3EC1g96Qd8oCSymd8VPWFpeVP4BZ4LKNWbG6WWbbyeA4p81NdFowskWINOHR/DZcfiRQ1S1veRrSyL3tBR3riO0cKf+v+aPobmVoYlB63HRR6poyP1KNpVW5dbWDGb2LwaXDe1v0FXx4zA4bbDYvaE2EJxyUwIG7vOgRCkMIbQ6lK4Y2veKEhpi7HkAdLXu/N9Uho243r2ZasNAl4d/S1I4fEuU+iaDfURbAd8uxpf+Ts0xkWggb0lFMP2HtDGYWGjN2CG8fyNrHXleBFLhruAuRM9nX/F4dqe/AzugGpDPT44CDVXV9XMRBKKCZB4YAmV25/MdMYWCpm5LYzk9Mu4A9mBnCGmi4Qvm9egV9F0ri0+QJyPO8ehinsxnEkO47qy1klKKrAQiQHJf3Vj5dsYQ4qdisuktd9HnpSZ89aZhyNLLSeg8MV3wCgJDK7RLiLcS/X3dA5E3VD/zkOFyTEOk+ycQS/pDuJjqIDcqfqbdp25BDSTAmsUktoREBmq4nFB5AES0RgTMrWsgH17ocN45mi8PKNRphlgG+RYYZUfPgQD7P9fWMn43q+mH7z8vlhaWrPBQAiuQpwJTJEiiC0qcRLRBP+f8u8kUSCVNhhWf+vemVtEbWuxcStbgWWYs95Nedq6/1z7HfjEqC8DuuD6pZdpszZWjtpflfUAr9+N9H8PoWdIPI2BuO1pgn5vy75GhEX82dBLGlMbI/qI6bl/lsSFq48z0eKaiDal4lAKcSVvtqdPG3Svb08R0TBpfQ78zRQzMjrjLRflCC1RVtl8B4cyMzZWoYqd0RiEF97VzVOgjk9XqcyDa3oFuLGUpp+29hllgVyV5IfmcIA0OzmVCKrH6br2MbRt5fpFiDLq9Z3m1EfLs+1IuYwOQFDixGHuNwQhbdb7lqQS/w3azWW/ZgU9bOxr63Wrbr/I/UyjOKPm/L1OzpZai1XL3wxe7pthVIigBJi+muiAPBGRqjbW6V8b/pLY16ePZkfca0FoGp6g91VXEHyT24OyODk+7VWVcsZxgXdlp4a8GKzXNGfi7TDcCsHm4Mo66sv/B9r0/hv3yPTwmn8+yJpM/nYRDlhwfOmwoL5VF9J4TWN+7KjzRAUQqnGf9IogjdugWOHeNhuE1V2P8sue/dJahmFpY5Y1DyHy4feWfZeQtMz+HQBwwrY6HL1I3IgktiK5fu/6UW2fTj8icdQb456MU5u+OTLdaZJmqkykia5vcVSP2S6hh8b71+tflE1/B8Ee1TbZUXQL0sqHx8wB5V7Cc27RUyIsGVqulus8Ht2xsDLQKpgh/mah7rvba6U4NzSWL1JTO26GWdmv3aKnwfbLBjqZNMpWlc+eDUWqh1/T8VGomrJ9mNsxJRV8RnBb9VsYEGmp0kAWBkGAUYT/tyNIEvdyuQ1tnxVFeggPPzNQhTJds61rSb0IO3elOJ65X2goKgeIH2l7NIGQDJ8i1QLyFTR6DzSGB666a3nFY1Cj2hNpVXq9R6OvQ/+Yz2koZghEHY9nvdLIzIO08V8XyOw/DvXtsw4BBmAuyGKlShAsFhH+W81zioo5K2xKz8QgnUd2r9t0uuK33MBqrSkzSm9BkJcwaI3iIXabe+R+BJSbg5JKZGhSneeg0+7OxUfVGXdMnczkZoxQr9Cq5/Qg==
x-microsoft-antispam-prvs: <HE1PR07MB3132D212CD4ACB13ACB48D7FF4720@HE1PR07MB3132.eurprd07.prod.outlook.com>
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(136003)(396003)(13464003)(51914003)(199004)(189003)(53754006)(110136005)(316002)(325944009)(7736002)(33656002)(86362001)(53946003)(26005)(446003)(66066001)(30864003)(14454004)(236005)(476003)(6306002)(966005)(478600001)(8676002)(11346002)(2616005)(6512007)(54896002)(486006)(8936002)(81156014)(97736004)(71200400001)(81166006)(25786009)(71190400001)(83716004)(6636002)(82746002)(5024004)(5660300002)(105586002)(85182001)(606006)(256004)(85202003)(106356001)(14444005)(6486002)(53546011)(6346003)(2906002)(102836004)(4326008)(6506007)(68736007)(6436002)(229853002)(6246003)(93886005)(66574012)(186003)(99286004)(53936002)(3846002)(6116002)(58126008)(76176011)(36756003)(54906003)(579004)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3132; H:HE1PR07MB4172.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.selander@ericsson.com;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Lwvzj5O6/f7JDjS6zBQnFGP5p8uNfbpWqC+1DWJZLHS2gxKFjeP7fesyf8CLzXxzsmLMhWrPAI9qwK+Mb0zoe/khg9yQKW9odzdO/uE09iKNEt3KqicW2qYzILGGAEBuZcMbThIwEYhuY0OKXExsf9U3VQY/8rDdSQpumZnENWv6RqbKtW5vABieqRY1GdEtWo/yydHATUk3MTLW2gzsJQbtUacqUFXx5zQoBXdJ6haIR8TQ2j07w2L71Z9v6134R+zQf7j4el/65EydIloDDSF2VzCPSkLnpDaa1kU/T/BkoSolFAi68wj+cMsFM41WbgdWOjrWeP3d7NmRnfwHF9PpOEip3MCHyYenfonzIVC5cU39PIoF581S5FPcahfyWrx4oXV/KzjbbijUQCwbkLFoCoy/uR6Nh5iETHvCw7A=
Content-Type: multipart/alternative; boundary="_000_985573C6A4A64CDEBDC66E53EE80C025ericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d3d655a-5c7d-42fa-6602-08d6a15f9369
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 11:41:58.5346 (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: HE1PR07MB3132
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85246j2evS+Xjpg6sPZaklFhalDhL8Ikk3woQcelDzys4U jRDJQvNus2xe0GyolVNTKw394NLACzXStHm/JkJqihdiJm07K/z2e/7P/7m9vDQp7uU50zEJ SkaRII+T8oWU+ub7FI+88PSwUw1NtO/Odh7pW/dGTfi+/r5E+TaMjPICqKCOsklBkEbzmwi6 P9hLhpChwguRTFxMCqPw8gsXRjcPvKOSNvpEqfqxTUEGUlWKcpANDdgHtopKUQ4S0mLcg6BZ W83ngi0ENZO16H+w/KufxwUvCGjKaqfMAYWLSOgqzOObm4lxMQEdRppzzSKYNeh55gQfX4KZ jDnCzPb4OjybyrLoJFbCUmsLMvMhk96gXSE5zw1QFWVQHHuDcUVrqqVN045CdvYRsyzC/qBZ Hye5WRsErA9OWWpt8EV4OaC11CIsgZ3+BoKb5QhjC1UEdzUGTecXkmMHWJ7fs+zjgL2grWCG 4nQ3mNMV8jg+DF+rchHHwfBzVW/tY0CwVhPIsTtMTgxb/S5QXt5jeSHAXRIYzH9sbRoL8yWr pPkYwK6wtikoQl5l+9bjOALUVXp+meVOO+hTL1BlpgoSH4emD1a7G5Tkzgo4PgYPKyqtHAQj GgN/v6ca0a+QA8uwbHyUt7cno4iJYNnEBM8ERtmCTJ+ru814vh11L8l0CNNIekBUH5IeJubJ U9i0eB0CmpTai3YdTZIoUp52l1Ek3lYkxzGsDrnQlNRRtCu2CxPjKLmSiWWYJEbxL0vQNs4Z KFhS86239s6TkNSJTM+NW7oHdVFPl4yq6bc83aOCK9eSew7Klk+qjuSdu+o/MdRb0aj3H7V1 NWh8no/H4WHb8oDSTsMi5Sdr1fNHJJfP1P+wb/P4s72X37g9VFpcGunEV4VWNgePCaYdSj5m ovD6z3XDMrX4RK2TaPHsJyLwnlZKsdHy0+6kgpX/BWE8xuVYAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/sQoOlrtw7keAQ5jjcUd1ZKrkICc>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] 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: Tue, 05 Mar 2019 11:42:14 -0000
Hi Rene, From: Rene Struik <rstruik.ext@gmail.com> Date: Monday, 4 March 2019 at 22:57 To: John Mattsson <john.mattsson@ericsson.com> Cc: "secdispatch@ietf.org" <secdispatch@ietf.org>, Göran Selander <goran.selander@ericsson.com>, 'Benjamin Kaduk' <kaduk@mit.edu>, "ace@ietf.org" <ace@ietf.org> Subject: (details on use case scenario?) Re: [Lwip] [Ace] EDHOC standardization Hi John, Goran: It is not easy to follow the discussion on EDHOC (except for witnessing a byte-count slinging contest on the mailing list). I think it would be good to look at the big picture, i.e., which problem does one solve and/or does one solve the right problem. I would like to understand somewhat better how the scheme suggested in [1] could help in facilitating fast network enrollment and network formation. Could you describe how to use this in the following scenario: 1) Network with one central manager and N=1,000 nodes that wish to join the network roughly at the same time, where the network manager is, say, 10 hops away from the joining nodes; 2) Authenticated key agreement using cert-based key agreement; 3) Network uses time-synchronized scheduling (such as in 6tisch) - where local single-hop communication time latency is 10 seconds); 4) The network manager may have high-bandwidth with outside world, but joining node/network manager path uses relatively low-bandwidth pipe that may only be available intermittently, with preset schedule); 5) It is unknown beforehand which entry point the joining nodes will pick when trying to enroll to the network? Something like this is briefly discussed under the benchmarking subject on today’s agenda, but with PSK/RPK ECHDE instead of certificates. This is an excellent use case where message sizes is expected to have a large impact and simulations can be made, e.g. using https://bitbucket.org/6tisch/simulator/ While the draft refers to lots of details from other protocols that are used under the hood, it would be good to abstract from this for now and describe basics first. We have considered this. Our conclusion at the time was the having a precise description of an abstract protocol, in addition to the concrete mapping to COSE would perhaps be more confusing, and instead we tried to introduce people to CBOR and COSE in Appendix A. Considering the positive outcome from the CFRG Crypto Panel, I assume the protocol is sufficient readable for review. Please let us know if you have further issues reading it. I tend to agree with others that lossless data compression could result in some savings, with some give and take re encoding rules (see also [2]). Even if one finds a magic compression bullet at zero incremental cost, though, the more important question is what problem one solves and/or whether one solves the right problem. {As an aside, 802.15.4 (which is the MAC with the 127-byte payload limit mentioned) does not easily allow mixed secured/unsecured communications (but I do not think it is useful to have a side-discussion on that detail right now).} Some things cannot be compressed, like e.g. nonces, they can only be omitted by removing them at design time. Compression algorithms in themselves also add to the footprint. The approach of OSCORE and EDHOC has been to elide redundant information and define a compact format from the start. Do you think a lossless data compression performs better? The other question I have is whether it would be more important to hide the identity of the joining node in a network enrollment scenario than to hide the network manager's identity, or the other way around. There are different options to embed EDHOC in CoAP, the first request could be message_1 and the last response just an empty payload. Or the first request can be a trigger and message_1 carried in the first response. Hope that helps, Göran From [1], Section 1.1: EDHOC is optimized for small message sizes and can therefore be sent over a small number of radio frames. The message size of a key exchange protocol may have a large impact on the performance of an IoT deployment, especially in noisy environments. For example, in a network bootstrapping setting a large number of devices turned on in a short period of time may result in large latencies caused by parallel key exchanges. Ref: [1] draft-selander-ace-cose-ecdhe-12 [2] Email RS as of October 31, 2018, 2.32pm EDT, subject: https://mailarchive.ietf.org/arch/browse/ace/?q=struik On 11/22/2018 10:43 AM, Rene Struik wrote: Hi John: When comparing protocols, it would be useful to protocol flows optimization, as follows: a) optimized for parallelized online computations; b) optimized for minimization of message flows. See also slide 6 of my CFRG-83 presentation of March 30, 2012 (slides-83-cfrg-05 attached; I could not find CFRG records online). The current draft-selander-ace-cose-ecdhe-10 document considers optimization b), which minimizes the number of message flows, but does require each party to compute the shared key consecutively, rather than in parallel (as in optimization a). With option a), if one really wishes to squeeze as much info into a 128-octet datagram, one can already send A's ephemeral ECDSA signature key in message flow 1, thereby cutting down the size of the second message flow of the Sigma protocol depicted in Fig. 1 (https://tools.ietf.org/html/draft-selander-ace-cose-ecdhe-10#page-11) by 32 octets. This tackles the 120-octet byte count for the second flow of Fig. 1 quite simply, while leading to a 4-pass protocol flow (with roughly 70/70/55/55 bytes in flows 1/2/3/4). Obviously, this presents a trade-off, but quite well be worth it in settings where online key computations are quite slow on some platforms and where scheduling (e.g., with TSCH) can now be done with less consideration of the individual computational capabilities of devices (since now one does not need to build-in a worst-case 2 x "key computation back-off" for least capable devices, but can just use the 1x contingency for this). The parallel version is depicted below. Party U Party V | C_U, X_U, ALG_1, UAD_1, R_Sig(U;...) | +--------------------------------------------------------------------->| | message_1 | | | | C_U, C_V, X_V, ALG_2, R_Sig(V; ...) | |<---------------------------------------------------------------------+ | message_2 | | | | S_U, AEAD(K_3; ID_CRED_U, s_Sig(U; CRED_U, aad_3), PAD_3) | +--------------------------------------------------------------------->+ | message_3 | | | | S_V, AEAD(K_2; ID_CRED_V, s_Sig(V; CRED_V, aad_2), UAD_2)| | +<---------------------------------------------------------------------| | message_4 | ============================================================================== Flight #1 #2 #3 #4 Total ------------------------------------------------------------------------------ DTLS 1.3 RPK + ECDHE 143 364 212 - 721 TLS 1.3 RPK + ECDHE 129 322 194 - 645 EDHOC RPK + ECDHE 37 120 85 - 242 --> EDHOC parallel flow 70 70 55 55 250 On 11/22/2018 7:23 AM, John Mattsson wrote: Hi Jim, In the analysis that I did I very deliberately used TLS not DTLS. The main reason for using DTLS is because one is operating in the UDP environment and one cannot have reliable in order delivery. Since EDHOC is being built on top of CoAP, one can use CoAP to create reliable in order delivery. Thus, the extra bytes that DTLS has to deal with this are not needed. I started with DTLS as that was what was discussion between Salvador and Benjamin. Below are numbers for TLS 1.3. Changes compared to DTLS 1.3 are that the record header is smaller, handshake headers are smaller, and that Connection ID is not supported in TLS 1.3. The numbers I get for TLS 1.3 are overall slightly bigger than the numbers in your estimate (but for PSK Flight #3 I get slightly smaller numbers). I think the difference is due to many smaller things like handshake headers and fields in the certificate structure that adds up. I plan to add TLS 1.3 numbers to draft-ietf-lwig-security-protocol-comparison as well. I agree with your comment Jim. Just now, I am just trying to count the number of bytes of the security protocol. To do a fair comparison, you have to choose a specific deployment and look at the topology, the whole protocol stack, frame sizes (e.g. 128 bytes), how and where in the protocol stack fragmentation is done, and the expected packet loss. There is ongoing work on such simulations for 6tisch. Fragmentation and/or packet loss lead to the total number of bytes in the table below has to be multiplied by some linear factor. And as more bytes often lead to increased packet loss, you often see a non-linear relation between logical number of bytes on the transport/application layer as shown in the table below and physical number of bytes and/or time from completion of the protocol. Any realistic comparison over constrained radio would make the difference between TLS 1.3 and EDHOC larger. A problem with TLS is that it does not support Connection ID. TLS Assumptions: - Minimum number of algorithms and cipher suites offered - Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256 - Length of key identifiers: 4 bytes - TLS RPK with point compression (saves 32 bytes) - Only mandatory TLS extentions ============================================================================== Flight #1 #2 #3 Total ------------------------------------------------------------------------------ DTLS 1.3 RPK + ECDHE 143 364 212 721 TLS 1.3 RPK + ECDHE 129 322 194 645 EDHOC RPK + ECDHE 37 120 85 242 ------------------------------------------------------------------------------ DTLS 1.3 PSK + ECDHE 180 183 56 419 TLS 1.3 PSK + ECDHE 166 157 50 373 EDHOC PSK + ECDHE 42 46 11 99 ------------------------------------------------------------------------------ DTLS 1.3 PSK 130 143 56 329 TLS 1.3 PSK 116 117 50 283 ============================================================================== Number of bytes (No connection ID) Below is detailed information about the different flights: ====================================================== TLS 1.3 Flight #1 RPK + ECDHE ====================================================== Record Header - TLSPlaintext (5 bytes) 16 03 03 LL LL Handshake Header - Client Hello (4 bytes) 01 LL LL LL Legacy Version (2 bytes) 03 03 Client Random (32 bytes) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Legacy Session ID (1 bytes) 00 Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes) 00 02 13 05 Compression Methods (null) (2 bytes) 01 00 Extensions Length (2 bytes) LL LL Extension - Supported Groups (x25519) (8 bytes) 00 0a 00 04 00 02 00 1d Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes) 00 0d 00 04 00 02 08 07 Extension - Key Share (42 bytes) 00 33 00 26 00 24 00 1d 00 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Extension - Supported Versions (1.3) (7 bytes) 00 2b 00 03 02 03 04 Extension - Client Certificate Type (Raw Public Key) (6 bytes) 00 13 00 01 01 02 Extension - Server Certificate Type (Raw Public Key) (6 bytes) 00 14 00 01 01 02 5 + 4 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 = 129 bytes ------------------------------------------------------ TLS 1.3 Flight #1 PSK + ECDHE ------------------------------------------------------ Differences compared to RPK + ECDHE + Extension - PSK Key Exchange Modes (6 bytes) 00 2d 00 02 01 01 + Extension - Pre Shared Key (51 bytes) 00 29 00 2F 00 0a 00 04 ID ID ID ID 00 00 00 00 00 21 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f - Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes) - Extension - Client Certificate Type (Raw Public Key) (6 bytes) - Extension - Server Certificate Type (Raw Public Key) (6 bytes) 129 + 6 + 51 - 8 - 6 - 6 = 166 bytes ------------------------------------------------------ TLS 1.3 Flight #1 PSK ------------------------------------------------------ Differences compared to PSK + ECDHE - Extension - Supported Groups (x25519) (8 bytes) - Extension - Key Share (42 bytes) 166 - 8 - 42 = 116 bytes ====================================================== TLS 1.3 Flight #2 RPK + ECDHE ====================================================== Record Header - TLSPlaintext (5 bytes) 16 03 03 LL LL Handshake Header - Server Hello (4 bytes) 02 LL LL LL Legacy Version (2 bytes) fe fd Server Random (32 bytes) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Legacy Session ID (1 bytes) 00 Cipher Suite (TLS_AES_128_CCM_8_SHA256) (2 bytes) 13 05 Compression Method (null) (1 bytes) 00 Extensions Length (2 bytes) LL LL Extension - Key Share (40 bytes) 00 33 00 24 00 1d 00 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Extension - Supported Versions (1.3) (6 bytes) 00 2b 00 02 03 04 Record Header - TLSCiphertext (5 bytes) 17 03 03 LL LL Handshake Header - Encrypted Extensions (4 bytes) 08 LL LL LL Extensions Length (2 bytes) LL LL Extension - Client Certificate Type (Raw Public Key) (6 bytes) 00 13 00 01 01 02 Extension - Server Certificate Type (Raw Public Key) (6 bytes) 00 14 00 01 01 02 Handshake Header - Certificate Request (4 bytes) 0d LL LL LL Request Context (1 bytes) 00 Extensions Length (2 bytes) LL LL Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes) 00 0d 00 04 00 02 08 07 Handshake Header - Certificate (4 bytes) 0b LL LL LL Request Context (1 bytes) 00 Certificate List Length (3 bytes) LL LL LL Certificate Length (3 bytes) LL LL LL Certificate (59 bytes) // Point compression .... Certificate Extensions (2 bytes) 00 00 Handshake Header - Certificate Verify (4 bytes) 0f LL LL LL Signature (68 bytes) ZZ ZZ 00 40 .... Handshake Header - Finished (4 bytes) 14 LL LL LL Verify Data (32 bytes) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Record Type (1 byte) 16 Auth Tag (8 bytes) e0 8b 0e 45 5a 35 0a e5 5 + 90 + 5 + 18 + 15 + 72 + 72 + 36 + 1 + 8 = 322 bytes ------------------------------------------------------ TLS 1.3 Flight #2 PSK + ECDHE ------------------------------------------------------ Differences compared to RPK + ECDHE - Handshake Message Certificate (72 bytes) - Handshake Message CertificateVerify (72 bytes) - Handshake Message CertificateRequest (15 bytes) - Extension - Client Certificate Type (Raw Public Key) (6 bytes) - Extension - Server Certificate Type (Raw Public Key) (6 bytes) + Extension - Pre Shared Key (6 bytes) 00 29 00 02 00 00 322 - 72 - 72 - 15 - 6 - 6 + 6 = 157 bytes ------------------------------------------------------ TLS 1.3 Flight #2 PSK ------------------------------------------------------ Differences compared to PSK + ECDHE - Extension - Key Share (40 bytes) 157 - 40 = 117 bytes ====================================================== TLS 1.3 Flight #3 RPK + ECDHE ====================================================== Record Header - TLSCiphertext (5 bytes) 17 03 03 LL LL Handshake Header - Certificate (4 bytes) 0b LL LL LL Request Context (1 bytes) 00 Certificate List Length (3 bytes) LL LL LL Certificate Length (3 bytes) LL LL LL Certificate (59 bytes) // Point compression .... Certificate Extensions (2 bytes) 00 00 Handshake Header - Certificate Verify (4 bytes) 0f LL LL LL Signature (68 bytes) 04 03 LL LL //ecdsa_secp256r1_sha256 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Handshake Header - Finished (4 bytes) 14 LL LL LL Verify Data (32 bytes) // SHA-256 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Record Type (1 byte) 16 Auth Tag (8 bytes) // AES-CCM_8 00 01 02 03 04 05 06 07 5 + 72 + 72 + 36 + 1 + 8 = 194 bytes ------------------------------------------------------ TLS 1.3 Flight #3 PSK + ECDHE ----------------------------------------------------- Differences compared to RPK + ECDHE - Handshake Message Certificate (72 bytes) - Handshake Message Certificate Verify (72 bytes) 194 - 72 - 72 = 50 bytes ------------------------------------------------------ TLS 1.3 Flight #3 PSK ----------------------------------------------------- Differences compared to PSK + ECDHE None 50 bytes -----Original Message----- From: Jim Schaad <ietf@augustcellars.com><mailto:ietf@augustcellars.com> Date: Wednesday, 21 November 2018 at 16:25 To: John Mattsson <john.mattsson@ericsson.com><mailto:john.mattsson@ericsson.com>, "ace@ietf.org"<mailto:ace@ietf.org> <ace@ietf.org><mailto:ace@ietf.org>, "lwip@ietf.org"<mailto:lwip@ietf.org> <lwip@ietf.org><mailto:lwip@ietf.org> Cc: 'Benjamin Kaduk' <kaduk@mit.edu><mailto:kaduk@mit.edu>, "salvador.p.f@um.es"<mailto:salvador.p.f@um.es> <salvador.p.f@um.es><mailto:salvador.p.f@um.es> Subject: RE: [Ace] EDHOC standardization John, In the analysis that I did I very deliberately used TLS not DTLS. The main reason for using DTLS is because one is operating in the UDP environment and one cannot have reliable in order delivery. Since EDHOC is being built on top of CoAP, one can use CoAP to create reliable in order delivery. Thus the extra bytes that DTLS has to deal with this are not needed. Jim -----Original Message----- From: Ace <ace-bounces@ietf.org><mailto:ace-bounces@ietf.org> On Behalf Of John Mattsson Sent: Wednesday, November 21, 2018 7:03 AM To: ace@ietf.org<mailto:ace@ietf.org>; lwip@ietf.org<mailto:lwip@ietf.org> Cc: Benjamin Kaduk <kaduk@mit.edu><mailto:kaduk@mit.edu>; salvador.p.f@um.es<mailto:salvador.p.f@um.es> Subject: Re: [Ace] EDHOC standardization Hi all, Inspired by the discussion in this thread, I did more detailed calculations of the number of bytes when DTLS 1.3 is used for typical IoT use cases (PSK, RPK, Connection ID). The plan is to add this information to draft-ietf-lwig-security- protocol-comparison as this has been requested by several people. I think some bytes were missing in the earlier estimates for TLS 1.3, and as Ben commented, DTLS 1.3 adds some bytes compared to TLS 1.3. ================================================================ ============== Flight #1 #2 #3 Total ------------------------------------------------------------------------------ DTLS 1.3 RPK + ECDHE 149 373 213 735 DTLS 1.3 PSK + ECDHE 186 190 57 433 DTLS 1.3 PSK 136 150 57 343 ------------------------------------------------------------------------------ EDHOC RPK + ECDHE 38 121 86 245 EDHOC PSK + ECDHE 43 47 12 102 ================================================================ ============== Number of bytes Assumptions: - Minimum number of algorithms and cipher suites offered - Curve25519, ECDSA with P-256, AES-CCM_8, SHA-256 - Length of key identifiers: 4 bytes - Connection identifiers: 1 byte - The DTLS RPKs use point compression (saves 32 bytes) - No DTLS handshake message fragmentation - Only mandatory DTLS extentions, except for connection ID - Version 30 https://tools.ietf.org/html/draft-ietf-tls-dtls13-30 (EDHOC numbers are for the soon to be published -11 version with cipher suites) I hope this information is useful for people. Please comment if I missed something or if you have any suggestion of things to add or how to present things. I do not know currently how these numbers compare to DTLS 1.2. Below is detailed information about where the byte in different flights as well as the RPKs (SubjectPublicKeyInfo). Most of the bytes should have the correct value, but most of the length fields are just written as LL LL LL. Below is also information about how resumption, cached information [RFC 7924], and not using Connection ID affects the number of bytes. ====================================================== DTLS 1.3 Flight #1 RPK + ECDHE ====================================================== Record Header - DTLSPlaintext (13 bytes) 16 fe fd EE EE SS SS SS SS SS SS LL LL Handshake Header - Client Hello (10 bytes) 01 LL LL LL SS SS 00 00 00 LL LL LL Legacy Version (2 bytes) fe fd Client Random (32 bytes) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Legacy Session ID (1 bytes) 00 Cipher Suites (TLS_AES_128_CCM_8_SHA256) (4 bytes) 00 02 13 05 Compression Methods (null) (2 bytes) 01 00 Extensions Length (2 bytes) LL LL Extension - Supported Groups (x25519) (8 bytes) 00 0a 00 04 00 02 00 1d Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes) 00 0d 00 04 00 02 08 07 Extension - Key Share (42 bytes) 00 33 00 26 00 24 00 1d 00 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Extension - Supported Versions (1.3) (7 bytes) 00 2b 00 03 02 03 04 Extension - Client Certificate Type (Raw Public Key) (6 bytes) 00 13 00 01 01 02 Extension - Server Certificate Type (Raw Public Key) (6 bytes) 00 14 00 01 01 02 Extension - Connection Identifier (43) (6 bytes) XX XX 00 02 01 42 13 + 10 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 + 6 = 149 bytes ------------------------------------------------------ DTLS 1.3 Flight #1 PSK + ECDHE ------------------------------------------------------ Differences compared to RPK + ECDHE + Extension - PSK Key Exchange Modes (6 bytes) 00 2d 00 02 01 01 + Extension - Pre Shared Key (51 bytes) 00 29 00 2F 00 0a 00 04 ID ID ID ID 00 00 00 00 00 21 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f - Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes) - Extension - Client Certificate Type (Raw Public Key) (6 bytes) - Extension - Server Certificate Type (Raw Public Key) (6 bytes) 149 + 6 + 51 - 8 - 6 - 6 = 186 bytes ------------------------------------------------------ DTLS 1.3 Flight #1 PSK ------------------------------------------------------ Differences compared to PSK + ECDHE - Extension - Supported Groups (x25519) (8 bytes) - Extension - Key Share (42 bytes) 186 - 8 - 42 = 136 bytes ====================================================== DTLS 1.3 Flight #2 RPK + ECDHE ====================================================== Record Header - DTLSPlaintext (13 bytes) 16 fe fd EE EE SS SS SS SS SS SS LL LL Handshake Header - Server Hello (10 bytes) 02 LL LL LL SS SS 00 00 00 LL LL LL Legacy Version (2 bytes) fe fd Server Random (32 bytes) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Legacy Session ID (1 bytes) 00 Cipher Suite (TLS_AES_128_CCM_8_SHA256) (2 bytes) 13 05 Compression Method (null) (1 bytes) 00 Extensions Length (2 bytes) LL LL Extension - Key Share (40 bytes) 00 33 00 24 00 1d 00 20 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Extension - Supported Versions (1.3) (6 bytes) 00 2b 00 02 03 04 Extension - Connection Identifier (43) (6 bytes) XX XX 00 02 01 43 Record Header - DTLSCiphertext, Full (6 bytes) HH ES SS 43 LL LL Handshake Header - Encrypted Extensions (10 bytes) 08 LL LL LL SS SS 00 00 00 LL LL LL Extensions Length (2 bytes) LL LL Extension - Client Certificate Type (Raw Public Key) (6 bytes) 00 13 00 01 01 02 Extension - Server Certificate Type (Raw Public Key) (6 bytes) 00 14 00 01 01 02 Handshake Header - Certificate Request (10 bytes) 0d LL LL LL SS SS 00 00 00 LL LL LL Request Context (1 bytes) 00 Extensions Length (2 bytes) LL LL Extension - Signature Algorithms (ecdsa_secp256r1_sha256) (8 bytes) 00 0d 00 04 00 02 08 07 Handshake Header - Certificate (10 bytes) 0b LL LL LL SS SS 00 00 00 LL LL LL Request Context (1 bytes) 00 Certificate List Length (3 bytes) LL LL LL Certificate Length (3 bytes) LL LL LL Certificate (59 bytes) // Point compression .... Certificate Extensions (2 bytes) 00 00 Handshake Header - Certificate Verify (10 bytes) 0f LL LL LL SS SS 00 00 00 LL LL LL Signature (68 bytes) ZZ ZZ 00 40 .... Handshake Header - Finished (10 bytes) 14 LL LL LL SS SS 00 00 00 LL LL LL Verify Data (32 bytes) 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Record Type (1 byte) 16 Auth Tag (8 bytes) e0 8b 0e 45 5a 35 0a e5 13 + 102 + 6 + 24 + 21 + 78 + 78 + 42 + 1 + 8 = 373 bytes ------------------------------------------------------ DTLS 1.3 Flight #2 PSK + ECDHE ------------------------------------------------------ Differences compared to RPK + ECDHE - Handshake Message Certificate (78 bytes) - Handshake Message CertificateVerify (78 bytes) - Handshake Message CertificateRequest (21 bytes) - Extension - Client Certificate Type (Raw Public Key) (6 bytes) - Extension - Server Certificate Type (Raw Public Key) (6 bytes) + Extension - Pre Shared Key (6 bytes) 00 29 00 02 00 00 373 - 78 - 78 - 21 - 6 - 6 + 6 = 190 bytes ------------------------------------------------------ DTLS 1.3 Flight #2 PSK ------------------------------------------------------ Differences compared to PSK + ECDHE - Extension - Key Share (40 bytes) 190 - 40 = 150 bytes ====================================================== DTLS 1.3 Flight #3 RPK + ECDHE ====================================================== Record Header (6 bytes) // DTLSCiphertext, Full ZZ ES SS 42 LL LL Handshake Header - Certificate (10 bytes) 0b LL LL LL SS SS XX XX XX LL LL LL Request Context (1 bytes) 00 Certificate List Length (3 bytes) LL LL LL Certificate Length (3 bytes) LL LL LL Certificate (59 bytes) // Point compression .... Certificate Extensions (2 bytes) 00 00 Handshake Header - Certificate Verify (10 bytes) 0f LL LL LL SS SS 00 00 00 LL LL LL Signature (68 bytes) 04 03 LL LL //ecdsa_secp256r1_sha256 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Handshake Header - Finished (10 bytes) 14 LL LL LL SS SS 00 00 00 LL LL LL Verify Data (32 bytes) // SHA-256 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f Record Type (1 byte) 16 Auth Tag (8 bytes) // AES-CCM_8 00 01 02 03 04 05 06 07 6 + 78 + 78 + 42 + 1 + 8 = 213 bytes ------------------------------------------------------ DTLS 1.3 Flight #3 PSK + ECDHE ----------------------------------------------------- Differences compared to RPK + ECDHE - Handshake Message Certificate (78 bytes) - Handshake Message Certificate Verify (78 bytes) 213 - 78 - 78 = 57 bytes ------------------------------------------------------ DTLS 1.3 Flight #3 PSK ----------------------------------------------------- Differences compared to PSK + ECDHE None 57 bytes ====================================================== DTLS 1.3 - Cached information [RFC 7924] ====================================================== - Cached information together with server X.509 can be used to move bytes from flight #2 to flight #1 (cached RPK increases the number of bytes compared to cached X.509) Differences compared to RPK + ECDHE Flight #1 - Extension - Server Certificate Type (Raw Public Key) (6 bytes) + Extension - Client Cashed Information (39 bytes) 00 19 LL LL LL LL 01 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 149 + 33 = 182 bytes Flight #2 - Extension - Server Certificate Type (Raw Public Key) (6 bytes) + Extension - Server Cashed Information (7 bytes) 00 19 LL LL LL LL 01 - Server Certificate (59 bytes -> 32 bytes) 373 - 26 = 347 bytes ================================================================ ============== Flight #1 #2 #3 Total ------------------------------------------------------------------------------ DTLS 1.3 Cached X.509/RPK + ECDHE 182 347 213 742 DTLS 1.3 RPK + ECDHE 149 373 213 735 ================================================================ ============== ====================================================== DTLS 1.3 - Resumption ====================================================== To enable resumption, a 4th flight (New Session Ticket) is added Flight #4 - New Session Ticket Record Header - DTLSCiphertext, Full (6 bytes) HH ES SS 43 LL LL Handshake Header - New Session Ticket (10 bytes) 04 LL LL LL SS SS 00 00 00 LL LL LL Ticket Lifetime (4 bytes) 00 01 02 03 Ticket Age Add (4 bytes) 00 01 02 03 Ticket Nonce (2 bytes) 01 00 Ticket (6 bytes) 00 04 ID ID ID ID Extensions (2 bytes) 00 00 Auth Tag (8 bytes) // AES-CCM_8 00 01 02 03 04 05 06 07 6 + 10 + 4 + 4 + 2 + 6 + 2 + 8 = 42 bytes The resumption handshake is just a PSK handshake with 136 + 150 + 57 = 343 bytes ================================================================ ============== Flight #1 #2 #3 #4 Total ------------------------------------------------------------------------------ DTLS 1.3 RPK + ECDHE + NewSessionTicket 149 373 213 42 777 DTLS 1.3 PSK (resumption) 136 150 57 343 ================================================================ ============== ====================================================== DTLS 1.3 - Connection ID ====================================================== Without a Connection ID the DTLS 1.3 flight sizes changes as follows DTLS 1.3 Flight #1: -6 bytes DTLS 1.3 Flight #2: -7 bytes DTLS 1.3 Flight #3: -1 byte ================================================================ ============== Flight #1 #2 #3 Total ------------------------------------------------------------------------------ DTLS 1.3 RPK + ECDHE (no cid) 143 364 212 721 DTLS 1.3 PSK + ECDHE (no cid) 180 183 56 419 DTLS 1.3 PSK (no cid) 130 143 56 329 ================================================================ ============== ====================================================== DTLS Raw Public Keys ====================================================== SubjectPublicKeyInfo without point compression ----------------------------------------------------- 0x30 // Sequence 0x59 // Size 89 0x30 // Sequence 0x13 // Size 19 0x06 0x07 0x2A 0x86 0x48 0xCE 0x3D 0x02 0x01. // OID 1.2.840.10045.2.1 (ecPublicKey) 0x06 0x08 0x2A 0x86 0x48 0xCE 0x3D 0x03 0x01 0x07 // OID 1.2.840.10045.3.1.7 (secp256r1) 0x03 // Bit string 0x42 // Size 66 0x00 // Unused bits 0 0x04 // Uncompressed ...... 64 bytes X and Y Total of 91 bytes SubjectPublicKeyInfo with point compression ----------------------------------------------------- 0x30 // Sequence 0x59 // Size 89 0x30 // Sequence 0x13 // Size 19 0x06 0x07 0x2A 0x86 0x48 0xCE 0x3D 0x02 0x01. // OID 1.2.840.10045.2.1 (ecPublicKey) 0x06 0x08 0x2A 0x86 0x48 0xCE 0x3D 0x03 0x01 0x07 // OID 1.2.840.10045.3.1.7 (secp256r1) 0x03 // Bit string 0x42 // Size 66 0x00 // Unused bits 0 0x03 // Compressed ...... 32 bytes X Total of 59 bytes ====================================================== Helpful Sources of Information ====================================================== In addition to relevant RFCs and the estimates done by Jim, the following references were helpful: Every Byte Explained: The Illustrated TLS 1.3 Connection https://tls13.ulfheim.net/ Digital Certificates for the Internet of Things https://kth.diva- portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf /John -----Original Message----- From: Benjamin Kaduk <kaduk@mit.edu><mailto:kaduk@mit.edu> Date: Saturday, 3 November 2018 at 15:59 To: John Mattsson <john.mattsson@ericsson.com><mailto:john.mattsson@ericsson.com> Cc: "salvador.p.f@um.es"<mailto:salvador.p.f@um.es> <salvador.p.f@um.es><mailto:salvador.p.f@um.es>, "ace@ietf.org"<mailto:ace@ietf.org> <ace@ietf.org><mailto:ace@ietf.org> Subject: Re: [Ace] EDHOC standardization On Fri, Nov 02, 2018 at 02:55:54PM +0000, John Mattsson wrote: Hi Benjamin, Salvador While DTLS 1.3 have done a very good job of lowering the overhead of the record layer when application data is sent (see e.g. https://tools.ietf.org/html/draft-ietf-lwig-security-protocol-comparison-01 for a comparison between different protocols), I do not think the handshake protocol is much leaner (is it leaner at all?). (There are some handshake messages that are removed entirely.) We tried to make an fair comparison between EDHOC and TLS 1.3 in the presentation at IETF 101 (see https://datatracker.ietf.org/meeting/101/materials/slides-101-ace-key- exchange-w-oscore-00). Since then, we have significantly optimized the encoding in EDHOC and the upcoming version (-11) is expected to have the following message sizes. Auth. PSK RPK x5t x5chain -------------------------------------------------------------------- EDHOC message_1 43 38 38 38 EDHOC message_2 47 121 127 117 + Certificate chain EDHOC message_3 12 86 92 82 + Certificate chain -------------------------------------------------------------------- Total 102 245 257 237 + Certificate chains As Salvador writes, the handshakes in TLS 1.3 and DTLS 1.3 are basically the same, so the numbers presented at IETF 101 should be a good estimate also for DTLS 1.3. Auth. PSK RPK -------------------------------------------------------------------- (D)TLS message_1 142 107 (D)TLS message_2 135 264 (D)TLS message_3 51 167 -------------------------------------------------------------------- Total 328 538 Thanks for the numbers! The numbers above include ECDHE. For handshake messages, my understanding is that the DTLS 1.3 and TLS 1.3 record layer have exactly the same size. The DTLS 1.3 ones will be worse, due to the epoch and sequence number fields. -Ben _______________________________________________ Ace mailing list Ace@ietf.org<mailto:Ace@ietf.org> https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Lwip mailing list Lwip@ietf.org<mailto:Lwip@ietf.org> https://www.ietf.org/mailman/listinfo/lwip -- email: rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com> | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com> | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
- [Ace] EDHOC standardization Salvador Pérez
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Salvador Pérez
- Re: [Ace] EDHOC standardization Rene Struik
- Re: [Ace] EDHOC standardization Antonio Skarmeta
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Göran Selander
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization Benjamin Kaduk
- Re: [Ace] EDHOC standardization Owen Friel (ofriel)
- Re: [Ace] EDHOC standardization Michael Richardson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Ace] EDHOC standardization Jim Schaad
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization John Mattsson
- [Ace] (protocol flows) Re: [Lwip] EDHOC standardi… Rene Struik
- Re: [Ace] EDHOC standardization John Mattsson
- Re: [Ace] EDHOC standardization Hannes Tschofenig
- [Ace] (details on use case scenario?) Re: [Lwip] … Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander
- Re: [Ace] (details on use case scenario?) Re: [Lw… Rene Struik
- Re: [Ace] (details on use case scenario?) Re: [Lw… Göran Selander