[Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

[Rene Struik]

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?

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.

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).}

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.

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<i...@augustcellars.com>
Date: Wednesday, 21 November 2018 at 16:25
To: John Mattsson<john.matts...@ericsson.com>,"ace@ietf.org"  
<ace@ietf.org>,"l...@ietf.org"  <l...@ietf.org>
Cc: 'Benjamin Kaduk'<ka...@mit.edu>,"salvador....@um.es"  <salvador....@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-boun...@ietf.org>  On Behalf Of John Mattsson
Sent: Wednesday, November 21, 2018 7:03 AM
To:ace@ietf.org;l...@ietf.org
Cc: Benjamin Kaduk<ka...@mit.edu>;salvador....@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 30https://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 Thingshttps://kth.diva-
portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf

/John




-----Original Message-----
From: Benjamin Kaduk<ka...@mit.edu>
Date: Saturday, 3 November 2018 at 15:59
To: John Mattsson<john.matts...@ericsson.com>
Cc:"salvador....@um.es"  <salvador....@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
_______________________________________________
Lwip mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lwip


--
email:rstruik....@gmail.com  | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


--
email: rstruik....@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace