Re: [Ace] EDHOC standardization
Benjamin Kaduk <kaduk@mit.edu> Sat, 03 November 2018 14:59 UTC
Return-Path: <kaduk@mit.edu>
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 172961288BD for <ace@ietfa.amsl.com>; Sat, 3 Nov 2018 07:59:10 -0700 (PDT)
X-Quarantine-ID: <DyAtLYD8FMaJ>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 DyAtLYD8FMaJ for <ace@ietfa.amsl.com>; Sat, 3 Nov 2018 07:59:08 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 B19731277D2 for <ace@ietf.org>; Sat, 3 Nov 2018 07:59:07 -0700 (PDT)
X-AuditID: 12074424-ca3ff70000006ced-b7-5bddb7b8a401
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D2.7E.27885.9B7BDDB5; Sat, 3 Nov 2018 10:59:05 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wA3Ex3XX025838; Sat, 3 Nov 2018 10:59:03 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA3EwvG8013609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 3 Nov 2018 10:58:59 -0400
Date: Sat, 03 Nov 2018 09:58:57 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: "salvador.p.f@um.es" <salvador.p.f@um.es>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20181103145857.GG54966@kduck.kaduk.org>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrbtz+91og38bVC2+f+thtjg1czeT RfOqq+wOzB6/vl5l81iy5CeTx7mXbSwBzFFcNimpOZllqUX6dglcGe3/1jAXPBWouPnEroFx HU8XIyeHhICJRGfDM+YuRi4OIYE1TBKrJ79kg3A2MEqcOLiXBcK5wyRxfcdpRpAWFgEViduv v4DZbEB2Q/dlZhBbREBP4lTbS7A4s4CPxIpHS1lAbGEBDYmNXVvZQWxeoHUrPv5jArGFBOwl fu3dywgRF5Q4OfMJC0SvlsSNfy+BajiAbGmJ5f84QMKcAg4St/cdYQOxRQWUJfb2HWKfwCgw C0n3LCTdsxC6FzAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgKXHYXlR2M 3T3ehxgFOBiVeHgNKu9EC7EmlhVX5h5ilORgUhLldeYFCvEl5adUZiQWZ8QXleakFh9ilOBg VhLh/dIKlONNSaysSi3Kh0lJc7AoifNObFkcLSSQnliSmp2aWpBaBJOV4eBQkuDN3HY3Wkiw KDU9tSItM6cEIc3EwQkynAdo+AGQGt7igsTc4sx0iPwpRkUpcd4JIAkBkERGaR5cLyixSGTv r3nFKA70ijDvSZAqHmBSgut+BTSYCWhw9J/bIINLEhFSUg2Mm+PeMbZOF32ibM7YsIftKm9G 0WkW7rULNjnPrKyUj5NlX83Y5ROctURIoGdOV1mK56/CeNUvt6bZHtKpcHh+rOS5RM1ExU7L CWvtmsqrpuluNkt9y/S1JjnG9/AV/uxHca/rdALbOs6t6UlLznl89MfFTu8zkW/zmT6296/4 q8RVuGKyUr0SS3FGoqEWc1FxIgBTRvM+BwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/mY3COjaQ8OAKlqkasIRBAmTi2BU>
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: Sat, 03 Nov 2018 14:59:10 -0000
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] 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