Re: [Lwip] [Ace] EDHOC standardization
Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 04 March 2019 16:26 UTC
Return-Path: <Hannes.Tschofenig@arm.com>
X-Original-To: lwip@ietfa.amsl.com
Delivered-To: lwip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F3A12D84C; Mon, 4 Mar 2019 08:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 XMGY_0eFiXOn; Mon, 4 Mar 2019 08:25:59 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140082.outbound.protection.outlook.com [40.107.14.82]) (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 9F3CC128B14; Mon, 4 Mar 2019 08:25:58 -0800 (PST)
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=LFKf508dURSVIaUDUvavip6naoPNaP2UhTMnpGdksBw=; b=QhhtWq0fZxG1g3NmNONsnu+fo3QVzXWYESNxDSsw6EMSnnvwjVnoeCYQOc4kEtPaaoCnLZlaSeEKivO/wbLjwMAap0LNRHss0e+YHBjeigDqXO8v8rkTiloiunftQLpX9n9oetVIMgHfOdue7j0NMF+pZjQuYzUlI5mb76ro4Mk=
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1695.eurprd08.prod.outlook.com (10.168.67.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Mon, 4 Mar 2019 16:25:54 +0000
Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::dd0a:bfcc:b6ce:8d65%11]) with mapi id 15.20.1665.019; Mon, 4 Mar 2019 16:25:54 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: John Mattsson <john.mattsson@ericsson.com>, "ace@ietf.org" <ace@ietf.org>, "lwip@ietf.org" <lwip@ietf.org>, "secdispatch@ietf.org" <secdispatch@ietf.org>
CC: Benjamin Kaduk <kaduk@mit.edu>, "salvador.p.f@um.es" <salvador.p.f@um.es>
Thread-Topic: [Ace] EDHOC standardization
Thread-Index: AQHUcrwmx6N1o4AsH0uz6RMW3Bvpj6U+JgWAgBxb0gD///JFkICR01oAgBAeIvA=
Date: Mon, 04 Mar 2019 16:25:54 +0000
Message-ID: <VI1PR0801MB21126B59E4319FF466D144B9FA710@VI1PR0801MB2112.eurprd08.prod.outlook.com>
References: <C79F1336-A297-4E64-AB32-2F5D474A200E@ericsson.com> <20181103145857.GG54966@kduck.kaduk.org> <7F78CC92-5C48-4BFC-8087-E25D4D95A74F@ericsson.com> <VI1PR0801MB2112FB5DB96C48C36D4D0B98FADA0@VI1PR0801MB2112.eurprd08.prod.outlook.com> <94433D36-E1D5-4A62-AA45-2B19D72D8BC9@ericsson.com>
In-Reply-To: <94433D36-E1D5-4A62-AA45-2B19D72D8BC9@ericsson.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.118.223]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0e23241c-0591-4388-7921-08d6a0be134b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1695;
x-ms-traffictypediagnostic: VI1PR0801MB1695:
x-ms-exchange-purlcount: 6
x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1695; 20:fuYvhhDDrNR1j4Z9x1ScIBu14uNLcrJAZhqXytJyd3/ekkXZp9kNzl8iH6ks4fIs4ekZpj0jQTTnfkHSCEe86SiaxYQnFolBT/Tpet9ScVOeixGdw9Li4cFCIg4ocmE4ZK+jUD6Oe01617Hzb0haVBjwmkec6Xb5UCgtlPxw8fM=
x-microsoft-antispam-prvs: <VI1PR0801MB1695F80134B943EC994692CAFA710@VI1PR0801MB1695.eurprd08.prod.outlook.com>
x-forefront-prvs: 09669DB681
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(136003)(396003)(376002)(53754006)(40434004)(51444003)(51914003)(189003)(199004)(13464003)(2906002)(478600001)(14454004)(6116002)(3846002)(72206003)(316002)(74316002)(7736002)(305945005)(6246003)(71200400001)(25786009)(81166006)(8676002)(66066001)(81156014)(86362001)(5660300002)(4326008)(97736004)(33656002)(76176011)(99286004)(106356001)(105586002)(2501003)(7696005)(966005)(93886005)(186003)(26005)(102836004)(53546011)(6506007)(229853002)(6436002)(14444005)(5024004)(486006)(66574012)(30864003)(11346002)(52536013)(8936002)(256004)(476003)(53946003)(55016002)(54906003)(71190400001)(110136005)(53936002)(446003)(68736007)(9686003)(2201001)(6306002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1695; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: JSK9v9D8TzSGmx2nx2Pce74vYZM1+4Zi6yBVdbLygch85YfXU7bXPXm7DLTRAENZMT+uMAX7Bp/rVtzFLPCt5dlixqHRghqhIAsaRaZ9IXqe7y1E6wstJ6hukSPql8pWo9nhU1Slzr+IfzfhLuLY1UW9cJgUoWHCllCRmm4gsEtJY/+OgqVpdkKnSJqa+a7sG9AJ80TumP4wdtLgWjeydugFlVgZ4+Gxk6ClupGYHeiQYuFt6PrYMSLQtrbwqaouT7M9NbqhuchUGpjePKlcaLoMwUjvstnkPVrQrMIaXpZnf/9D4T1PmKD+8Ibtxc7Drivn/geumbrWK6stYQmq9ioi9580DBhjuOr1+UdATqglbPe3p1O9KZSqwKIb+yKq0ZW6N9YaGO5QbDGxebgU2S7km/GGH+QEB/a2RJHVnaA=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0e23241c-0591-4388-7921-08d6a0be134b
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Mar 2019 16:25:54.5966 (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: VI1PR0801MB1695
Archived-At: <https://mailarchive.ietf.org/arch/msg/lwip/oPYt9XYrH53_Hp2AOz32cYoEOWY>
Subject: Re: [Lwip] [Ace] EDHOC standardization
X-BeenThere: lwip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Lightweight IP stack. Official mailing list for IETF LWIG Working Group." <lwip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lwip>, <mailto:lwip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lwip/>
List-Post: <mailto:lwip@ietf.org>
List-Help: <mailto:lwip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lwip>, <mailto:lwip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2019 16:26:03 -0000
Hi John, I have a slightly different perspective. ECDHE-PSK is not used because those companies who want to use security on really low end IoT devices use PSKs only and there is a lot of overhead from the public key crypto. We have been offering different ciphersuites that use ECDHE-PSK for a while and the interest was pretty much zero. RPK was a nice idea but it turns out that those who want to deploy IETF IoT security solutions either want to go totally minimalistic (=PSK) or they go for certificates because they have an installed base. That's what we are seeing. As a co-author of the RPK document I have been talking to our Mbed TLS team a lot and they keep telling me that there is no interest. People ask once in a while for it on Github but don’t want to allocate any resources implementing it. To me that's a pretty strong hint of what people want and do not want. Ciao Hannes -----Original Message----- From: John Mattsson <john.mattsson@ericsson.com> Sent: Freitag, 22. Februar 2019 10:08 To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; ace@ietf.org; lwip@ietf.org; secdispatch@ietf.org Cc: Benjamin Kaduk <kaduk@mit.edu>; salvador.p.f@um.es Subject: Re: [Ace] EDHOC standardization Hi Hannes, No wonder that ECDHE-PSK is not widely used in (D)TLS when the relevant ECDHE-PSK cipher suites TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 for TLS 1.2 (and similarly ECDHE + PSK + TLS_AES_128_CCM_8_SHA256 for TLS 1.3) were standardized just a few months ago (RFC 8442 and RFC 8446). Luckily most, if not all TLS 1.3 implementations are likely to support ECDHE + PSK + TLS_AES_128_CCM_8_SHA256. Similarly, PRK (RFC 7250) is not supported in many TLS implementations (e.g. it is not supported in mbed TLS). The main use case for RPK and self-signed certificates are not as a replacement for PKI, it's a replacement for symmetrical group keys. My experience is that almost all IoT devices are capable of doing ECDH and doing so is very important as a way to get PFS. As required by RFC 725, IEFT protocols need to mitigate pervasive monitoring and one very effective way is to use PFS. Looking at a lot of currently deployed IoT systems makes me sad, if security is used at all, it is often hop-by-hop and often not over the full path. The systems seldom provide PFS and in many cases use symmetrical group keys where they should not. A common reason that systems do not use PFS is because they think it’s an easy way to enable intercept. IETF has a role to educate and guide people on what to use. I think that IETF should strongly recommend PFS in all use cases and recommend using RPK/ self-signed certificates instead of group keys where possible. A pre-requisite for doing so is to provide protocols that can be used even in very constrained systems. Cheers, John -----Original Message----- From: Hannes Tschofenig <Hannes.Tschofenig@arm.com> Date: Wednesday, 21 November 2018 at 16:16 To: John Mattsson <john.mattsson@ericsson.com>, "ace@ietf.org" <ace@ietf.org>, "lwip@ietf.org" <lwip@ietf.org> Cc: Benjamin Kaduk <kaduk@mit.edu>, "salvador.p.f@um.es" <salvador.p.f@um.es> Subject: RE: [Ace] EDHOC standardization Hi John, From our experience neither PSK+ECDHE nor RPK usage is common in IoT deployments among the bigger IoT providers. Today, most companies use certificate-based authentication in almost all cases. In some cases plain PSK is used for those cases where devices are particularly constraint. Ciao Hannes -----Original Message----- From: Ace <ace-bounces@ietf.org> On Behalf Of John Mattsson Sent: Wednesday, November 21, 2018 4:03 PM To: ace@ietf.org; lwip@ietf.org Cc: Benjamin Kaduk <kaduk@mit.edu>; 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> Date: Saturday, 3 November 2018 at 15:59 To: John Mattsson <john.mattsson@ericsson.com> Cc: "salvador.p.f@um.es" <salvador.p.f@um.es>, "ace@ietf.org" <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 https://www.ietf.org/mailman/listinfo/ace 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. 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.
- Re: [Lwip] [Ace] EDHOC standardization John Mattsson
- Re: [Lwip] [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Lwip] [Ace] EDHOC standardization Hannes Tschofenig
- Re: [Lwip] [Ace] EDHOC standardization Jim Schaad
- Re: [Lwip] [Ace] EDHOC standardization John Mattsson
- Re: [Lwip] [Ace] EDHOC standardization John Mattsson
- [Lwip] (protocol flows) Re: [Ace] EDHOC standardi… Rene Struik
- Re: [Lwip] (protocol flows) Re: [Ace] EDHOC stand… John Mattsson
- Re: [Lwip] [Ace] EDHOC standardization John Mattsson
- Re: [Lwip] [Ace] EDHOC standardization Hannes Tschofenig