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 <[email protected]>
Date: Wednesday, 21 November 2018 at 16:25
To: John Mattsson <[email protected]>, "[email protected]"
<[email protected]>, "[email protected]" <[email protected]>
Cc: 'Benjamin Kaduk' <[email protected]>, "[email protected]" <[email protected]>
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 <[email protected]> On Behalf Of John Mattsson
> Sent: Wednesday, November 21, 2018 7:03 AM
> To: [email protected]; [email protected]
> Cc: Benjamin Kaduk <[email protected]>; [email protected]
> 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 <[email protected]>
> Date: Saturday, 3 November 2018 at 15:59
> To: John Mattsson <[email protected]>
> Cc: "[email protected]" <[email protected]>, "[email protected]"
> <[email protected]>
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ace
_______________________________________________
Lwip mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lwip
