Subject: Re: [Ace] EDHOC standardization

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 4 Mar 2019 16:25:54 +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 <[email-masked]>
Sent: Freitag, 22. Februar 2019 10:08
To: Hannes Tschofenig <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]
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 <[email-masked]>
Date: Wednesday, 21 November 2018 at 16:16
To: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>, "[email-masked]" <[email-masked]>
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 <[email-masked]> On Behalf Of John Mattsson
Sent: Wednesday, November 21, 2018 4:03 PM
To: [email-masked]; [email-masked]
Cc: Benjamin Kaduk <[email-masked]>; [email-masked]
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-masked]>
Date: Saturday, 3 November 2018 at 15:59
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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-masked]
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.

---

From: Rene Struik <[email-masked]>
Date: Mon, 4 Mar 2019 16:56:43 -0500

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 | 
> 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:
>> - TLS RPK with point compression (saves 32 bytes)
>> - Only mandatory TLS extentions
>>
>> 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)
>> 5 + 4 + 2 + 32 + 1 + 4 + 2 + 2 + 8 + 8 + 42 + 7 + 6 + 6 = 129 bytes
>>
>> TLS 1.3 Flight #1 PSK + ECDHE
>> 129 + 6 + 51 - 8 - 6 - 6 = 166 bytes
>>
>> TLS 1.3 Flight #1 PSK
>> 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)
>> Record Header - TLSCiphertext (5 bytes)
>> 17 03 03 LL LL
>>
>> 	Handshake Header - Encrypted Extensions (4 bytes)
>> 	08 LL LL LL
>>
>> 	Handshake Header - Certificate Request (4 bytes)
>> 	0d LL LL LL
>>
>> 	Handshake Header - Certificate (4 bytes)
>> 	0b LL LL LL
>>
>> 	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)
>> 5 + 90 + 5 + 18 + 15 + 72 + 72 + 36 + 1 + 8 = 322 bytes
>>
>> TLS 1.3 Flight #2 PSK + ECDHE
>> - Handshake Message Certificate (72 bytes)
>>
>> - Handshake Message CertificateVerify (72 bytes)
>>
>> - Handshake Message CertificateRequest (15 bytes)
>>
>> 322 - 72 - 72 - 15 - 6 - 6  + 6 = 157 bytes
>>
>> TLS 1.3 Flight #2 PSK
>> 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
>>
>> 	Handshake Header - Certificate Verify (4 bytes)
>> 	0f LL LL LL
>>
>> 		Signature  (68 bytes)
>> 	Handshake Header - Finished (4 bytes)
>> 	14 LL LL LL
>>
>> 5 + 72 + 72 + 36 + 1 + 8 = 194 bytes
>>
>> TLS 1.3 Flight #3 PSK + ECDHE
>> - Handshake Message Certificate (72 bytes)
>>
>> - Handshake Message Certificate Verify (72 bytes)
>>
>> 194 - 72 - 72 = 50 bytes
>>
>> TLS 1.3 Flight #3 PSK
>> 50 bytes
>> From: Jim Schaad<[email-masked]>
>> Date: Wednesday, 21 November 2018 at 16:25
>> To: John Mattsson<[email-masked]>,"[email-masked]"  <[email-masked]>,"[email-masked]"  <[email-masked]>
>> Cc: 'Benjamin Kaduk'<[email-masked]>,"[email-masked]"  <[email-masked]>
>> 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
>>
>>
>>> From: Ace<[email-masked]>  On Behalf Of John Mattsson
>>> Sent: Wednesday, November 21, 2018 7:03 AM
>>> To:[email-masked];[email-masked]
>>> Cc: Benjamin Kaduk<[email-masked]>;[email-masked]
>>> 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.
>>>
>>> - Version 30https://tools.ietf.org/html/draft-ietf-tls-dtls13-30
>>>
>>> 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.
>>>
>>>
>>> 			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
>>>
>>> DTLS 1.3 - Cached information [RFC 7924]
>>> Digital Certificates for the Internet of Thingshttps://kth.diva-
>>> portal.org/smash/get/diva2:1153958/FULLTEXT01.pdf
>>>
>>> /John
>>>
>>>
>>>
>>>
>>> From: Benjamin Kaduk<[email-masked]>
>>> To: John Mattsson<[email-masked]>
>>> Cc:"[email-masked]"  <[email-masked]>,"[email-masked]"
>>> <[email-masked]>
>>>> 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?).
>>>
>>>> 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.
>>>> 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
>>>> 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.
>>>
>> Lwip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/lwip
>
>
> -- 
> email:[email-masked]  | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Göran Selander <[email-masked]>
Date: Tue, 5 Mar 2019 11:41:58 +0000

Hi Rene,

From: Rene Struik <[email-masked]>
Date: Monday, 4 March 2019 at 22:57
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Göran Selander <[email-masked]>, 'Benjamin Kaduk' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: (details on use case scenario?) Re: [Lwip] [Ace] EDHOC standardization

Hi John, Goran:

It is not easy to follow the discussion on EDHOC (except for witnessing a byte-count slinging contest on the mailing list).

I think it would be good to look at the big picture, i.e., which problem does one solve and/or does one solve the right problem.

I would like to understand somewhat better how the scheme suggested in [1] could help in facilitating fast network enrollment and network  formation.

Could you describe how to use this in the following scenario:
1) Network with one central manager and N=1,000 nodes that wish to join the network roughly at the same time, where the network manager is, say, 10 hops away from the joining nodes;
2) Authenticated key agreement using cert-based key agreement;
3) Network uses time-synchronized scheduling (such as in 6tisch) - where local single-hop communication time latency is 10 seconds);
4) The network manager may have high-bandwidth with outside world, but joining node/network manager path uses relatively low-bandwidth pipe that may only be available intermittently, with preset schedule);
5) It is unknown beforehand which entry point the joining nodes will pick when trying to enroll to the network?

Something like this is briefly discussed under the benchmarking subject on today’s agenda, but with PSK/RPK ECHDE instead of certificates.
This is an excellent use case where message sizes is expected to have a large impact and simulations can be made, e.g. using https://bitbucket.org/6tisch/simulator/

While the draft refers to lots of details from other protocols that are used under the hood, it would be good to abstract from this for now and describe basics first.

We have considered this. Our conclusion at the time was the having a precise description of an abstract protocol, in addition to the concrete mapping to COSE would perhaps be more confusing, and instead we tried to introduce people to CBOR and COSE in Appendix A. Considering the positive outcome from the CFRG Crypto Panel, I assume the protocol is sufficient readable for review. Please let us know if you have further issues reading it.

I tend to agree with others that lossless data compression could result in some savings, with some give and take re encoding rules (see also [2]). Even if one finds a magic compression bullet at zero incremental cost, though, the more important question is what problem one solves and/or whether one solves the right problem. {As an aside, 802.15.4 (which is the MAC with the 127-byte payload limit mentioned) does not easily allow mixed secured/unsecured communications (but I do not think it is useful to have a side-discussion on that detail right now).}

Some things cannot be compressed, like e.g. nonces, they can only be omitted by removing them at design time. Compression algorithms in themselves also add to the footprint. The approach of OSCORE and EDHOC has been to elide redundant information and define a compact format from the start. Do you think a lossless data compression performs better?

The other question I have is whether it would be more important to hide the identity of the joining node in a network enrollment scenario than to hide the network manager's identity, or the other way around.

There are different options to embed EDHOC in CoAP, the first request could be message_1 and the last response just an empty payload. Or the first request can be a trigger and message_1 carried in the first response.

Hope that helps,
Göran

From [1], Section 1.1:
EDHOC is optimized for small message sizes and can therefore be sent over a small number of radio frames. The message size of a key exchange protocol may have a large impact on the performance of an IoT deployment, especially in noisy environments. For example, in a network bootstrapping setting a large number of devices turned on in a short period of time may result in large latencies caused by parallel key exchanges.

Ref: [1] draft-selander-ace-cose-ecdhe-12
        [2] Email RS as of October 31, 2018, 2.32pm EDT, subject: https://mailarchive.ietf.org/arch/browse/ace/?q=struik

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

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

Hi Jim,

TLS Assumptions:

Flight                                #1         #2        #3       Total

16 03 03 LL LL

     01 LL LL LL

             Legacy Version (2 bytes)

             03 03

             Client Random (32 bytes)

             00

             00 02 13 05

             01 00

             LL LL

                    00 0a 00 04 00 02 00 1d

                    00 0d 00 04 00 02 08 07

                    00 2b 00 03 02 03 04

                    00 13 00 01 01 02

                    00 14 00 01 01 02

  00 2d 00 02 01 01

  00 29 00 2F

TLS 1.3 Flight #1 PSK

166 - 8 - 42 = 116 bytes

16 03 03 LL LL

     02 LL LL LL

             Legacy Version (2 bytes)

             fe fd

             Server Random (32 bytes)

             00

             13 05

             00

             LL LL

                    00 33 00 24 00 1d 00 20

                    00 2b 00 02 03 04

17 03 03 LL LL

     08 LL LL LL

             LL LL

                    00 13 00 01 01 02

                    00 14 00 01 01 02

     0d LL LL LL

             00

             LL LL

                    00 0d 00 04 00 02 08 07

     0b LL LL LL

             00

             LL LL LL

             LL LL LL

             Certificate (59 bytes) // Point compression

             ....

             00 00

     0f LL LL LL

             Signature  (68 bytes)

             ZZ ZZ 00 40 ....

     14 LL LL LL

             Verify Data (32 bytes)

     Record Type (1 byte)

     16

Auth Tag (8 bytes)

e0 8b 0e 45 5a 35 0a e5

  00 29 00 02 00 00

TLS 1.3 Flight #2 PSK

157 - 40 = 117 bytes

17 03 03 LL LL

     0b LL LL LL

             00

             LL LL LL

             LL LL LL

             Certificate (59 bytes) // Point compression

             ....

             00 00

     0f LL LL LL

             Signature  (68 bytes)

     14 LL LL LL

     Record Type (1 byte)

     16

00 01 02 03 04 05 06 07

194 - 72 - 72 = 50 bytes

TLS 1.3 Flight #3 PSK

None

50 bytes

-----Original Message-----

From: Jim Schaad <[email-masked]><mailto:[email-masked]>

To: John Mattsson <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

Cc: 'Benjamin Kaduk' <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

John,

Jim

-----Original Message-----

From: Ace <[email-masked]><mailto:[email-masked]> On Behalf Of John Mattsson

To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Cc: Benjamin Kaduk <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi all,

================================================================

==============

Flight                                #1         #2        #3       Total

================================================================

==============

                                 Number of bytes

Assumptions:

(EDHOC numbers are for the soon to be published -11 version with cipher

suites)

              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

              00

              00 02 13 05

              01 00

              LL LL

                      00 0a 00 04 00 02 00 1d

                      Extension - Signature Algorithms

(ecdsa_secp256r1_sha256) (8 bytes)

                      00 0d 00 04 00 02 08 07

                      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

  00 2d 00 02 01 01

  00 29 00 2F

  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

DTLS 1.3 Flight #1 PSK

186 - 8 - 42 = 136 bytes

              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

              00

              13 05

              00

              LL LL

                      00 33 00 24 00 1d 00 20

                      00 2b 00 02 03 04

                      Extension - Connection Identifier (43) (6 bytes)

                      XX XX 00 02 01 43

              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

              00

              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

              00

              LL LL LL

              LL LL LL

              Certificate (59 bytes) // Point compression

              ....

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

              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

  00 29 00 02 00 00

DTLS 1.3 Flight #2 PSK

190 - 40 = 150 bytes

       Handshake Header - Certificate (10 bytes)

       0b LL LL LL SS SS XX XX XX LL LL LL

              00

              LL LL LL

              LL LL LL

              Certificate (59 bytes) // Point compression

              ....

              00 00

       Handshake Header - Certificate Verify (10 bytes)

       0f LL LL LL SS SS 00 00 00 LL LL LL

              Signature  (68 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

              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

       Record Type (1 byte)

       16

00 01 02 03 04 05 06 07

213 - 78 - 78 = 57 bytes

DTLS 1.3 Flight #3 PSK

None

57 bytes

- Cached information together with server X.509 can be used to move bytes

from flight #2 to flight #1

Flight #1

  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

  00 19 LL LL LL LL 01

373 - 26 = 347 bytes

================================================================

==============

Flight                                #1         #2        #3       Total

================================================================

==============

DTLS 1.3 - Resumption

              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

00 01 02 03 04 05 06 07

The resumption handshake is just a PSK handshake with 136 + 150 + 57 = 343

bytes

================================================================

==============

Flight                                      #1     #2     #3     #4    Total

================================================================

==============

DTLS 1.3 - Connection ID

================================================================

==============

Flight                                #1         #2        #3       Total

================================================================

==============

DTLS Raw Public Keys

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

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

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-

/John

-----Original Message-----

From: Benjamin Kaduk <[email-masked]><mailto:[email-masked]>

To: John Mattsson <[email-masked]><mailto:[email-masked]>

Cc: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]>

<[email-masked]><mailto:[email-masked]>

Hi Benjamin, Salvador

following message sizes.

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!

same size.

-Ben

Ace mailing list

[email-masked]<mailto:[email-masked]>

Lwip mailing list

[email-masked]<mailto:[email-masked]>

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

--

email: [email-masked]<mailto:[email-masked]> | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Tue, 5 Mar 2019 09:05:58 -0500

Hi Goran:

Brief feedback below:

Something like this is briefly discussed under the benchmarking subject 
on today’s agenda, but with PSK/RPK ECHDE instead of certificates.

This is an excellent use case where message sizes is expected to have a 
large impact and simulations can be made, e.g. using 
https://bitbucket.org/6tisch/simulator/

RS>> My 10-hop enrollment use case was aimed to force consideration of 
not just abstract "protocol flow arrows", but also effects on the 
network and its actors. A simple byte-count is not enough...
<<RS

Some things cannot be compressed, like e.g. nonces, they can only be 
omitted by removing them at design time. Compression algorithms in 
themselves also add to the footprint. The approach of OSCORE and EDHOC 
has been to elide redundant information and define a compact format from 
the start. Do you think a lossless data compression performs better?

There are different options to embed EDHOC in CoAP, the first request 
could be message_1 and the last response just an empty payload. Or the 
first request can be a trigger and message_1 carried in the first response.

RS>> If the first request is a trigger, one ends up with a four-pass 
protocol and might as well use the one I that allows parallel key 
computations and where all byte-counts could possibly fit within frames 
(see my message on "protocol flows" of October 31, 2018 and John 
Mattson's response hereto of Feb 19, 2019).
<<RS

On 3/5/2019 6:41 AM, Göran Selander wrote:
>
> Hi Rene,
>
> *From: *Rene Struik <[email-masked]>
> *Date: *Monday, 4 March 2019 at 22:57
> *To: *John Mattsson <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, Göran Selander 
> <[email-masked]>, 'Benjamin Kaduk' <[email-masked]>, 
> "[email-masked]" <[email-masked]>
> *Subject: *(details on use case scenario?) Re: [Lwip] [Ace] EDHOC 
> standardization
>
> Hi John, Goran:
>
> It is not easy to follow the discussion on EDHOC (except for 
> witnessing a byte-count slinging contest on the mailing list).
>
> I think it would be good to look at the big picture, i.e., which 
> problem does one solve and/or does one solve the right problem.
>
> 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;
>
> 3) Network uses time-synchronized scheduling (such as in 6tisch) - 
> where local single-hop communication time latency is 10 seconds);
>
> Something like this is briefly discussed under the benchmarking 
> subject on today’s agenda, but with PSK/RPK ECHDE instead of 
> certificates.
>
> This is an excellent use case where message sizes is expected to have 
> a large impact and simulations can be made, e.g. using 
> https://bitbucket.org/6tisch/simulator/
>
> While the draft refers to lots of details from other protocols that 
> are used under the hood, it would be good to abstract from this for 
> now and describe basics first.
>
> We have considered this. Our conclusion at the time was the having a 
> precise description of an abstract protocol, in addition to the 
> concrete mapping to COSE would perhaps be more confusing, and instead 
> we tried to introduce people to CBOR and COSE in Appendix A. 
> Considering the positive outcome from the CFRG Crypto Panel, I assume 
> the protocol is sufficient readable for review. Please let us know if 
> you have further issues reading it.
>
> I tend to agree with others that lossless data compression could 
> result in some savings, with some give and take re encoding rules (see 
> also [2]). Even if one finds a magic compression bullet at zero 
> incremental cost, though, the more important question is what problem 
> one solves and/or whether one solves the right problem. {As an aside, 
> 802.15.4 (which is the MAC with the 127-byte payload limit mentioned) 
> does not easily allow mixed secured/unsecured communications (but I do 
> not think it is useful to have a side-discussion on that detail right 
> now).}
>
> Some things cannot be compressed, like e.g. nonces, they can only be 
> omitted by removing them at design time. Compression algorithms in 
> themselves also add to the footprint. The approach of OSCORE and EDHOC 
> has been to elide redundant information and define a compact format 
> from the start. Do you think a lossless data compression performs better?
>
> The other question I have is whether it would be more important to 
> hide the identity of the joining node in a network enrollment scenario 
> than to hide the network manager's identity, or the other way around.
>
> There are different options to embed EDHOC in CoAP, the first request 
> could be message_1 and the last response just an empty payload. Or the 
> first request can be a trigger and message_1 carried in the first 
> response.
>
> Hope that helps,
>
> Göran
>
> From [1], Section 1.1:
>
> 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.
>
>     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
>     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).
>
>     U Party V | C_U, X_U, ALG_1, UAD_1, R_Sig(U;...) |
>     message_2 | | | | S_U, AEAD(K_3; ID_CRED_U, s_Sig(U; CRED_U,
>     aad_3), PAD_3) |
>     ID_CRED_V, s_Sig(V; CRED_V, aad_2), UAD_2)| |
>         From: Jim Schaad<[email-masked]>  <mailto:[email-masked]>
>
>         To: John Mattsson<[email-masked]>  <mailto:[email-masked]>,"[email-masked]"  <mailto:[email-masked]>  <[email-masked]>  <mailto:[email-masked]>,"[email-masked]"  <mailto:[email-masked]>  <[email-masked]>  <mailto:[email-masked]>
>
>         Cc: 'Benjamin Kaduk'<[email-masked]>  <mailto:[email-masked]>,"[email-masked]"  <mailto:[email-masked]>  <[email-masked]>  <mailto:[email-masked]>
>
>             From: Ace<[email-masked]>  <mailto:[email-masked]>  On Behalf Of John Mattsson
>
>             To:[email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>
>             Cc: Benjamin Kaduk<[email-masked]>  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>
>             From: Benjamin Kaduk<[email-masked]>  <mailto:[email-masked]>
>
>             To: John Mattsson<[email-masked]>  <mailto:[email-masked]>
>
>             Cc:"[email-masked]"  <mailto:[email-masked]>  <[email-masked]>  <mailto:[email-masked]>,"[email-masked]"  <mailto:[email-masked]>
>
>             <[email-masked]>  <mailto:[email-masked]>
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik
>
> email:[email-masked]  <mailto:[email-masked]>  | Skype: rstruik

---

From: Rene Struik <[email-masked]>
Date: Fri, 15 Mar 2019 10:27:53 -0400

Hi Goran:

As you recall, I suggested to look at some details of 6TiSCH enrollment 
(see my message of March 4, 2019 [1]). During the SecDispatch interim of 
March 5, 2019, this was provided as one use case scenario [2] and 
reiterated in your email of yesterday, March 14, 2019 [3]. Nevertheless, 
details on how this could be realized in practice are still missing.

I had another look at the 6TiSCH minimal security draft [1] (now in 2nd 
WGLC) and the "zero-touch" write-up [5] -- which you both referenced in 
your email [3] of yesterday.

To my understanding, the intention with 6TiSCH is to reuse the protocol 
flows of [4] to implement a public-key based enrollment scheme in the 
future. This seems to be what [5] aims for, if I try and read in between 
the [still unwritten] lines, and the impression I got from some people. 
 From looking at the protocol details, though, I do not understand how 
this can be done in practice. This begs the question what I am missing 
here.

Hence, my question of March 4th on details of use case scenarios still 
stands. In fact, I do not see how one could implement EDHOC on top of 
[4], even if one only uses symmetric-key only variant of EDHOC.

If you could shed some light on this, this would help. Or, should we 
simply abandon that use case as being unrealistic at this point?

Finally, your email [1] suggests "reports of massive breaches with PSK 
provisioning systems". If so, I would strongly suggest having another 
look at [4] and commenting on this.

Ref:
[1] Details on Use Case Scenarios, email RS of March 4, 2019. See 
https://mailarchive.ietf.org/arch/msg/ace/On0iIFAb_OWeBqLjlryi1rBHwhk
[2] Slides on EDHOC during SecDispatch meeting of March 5, 2019. See 
https://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
[3] Pitch for EDHOC, email Goran Selander of March 14, 2019. See 
https://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
[4] draft-ietf-6tisch-minimal-security-09
[5] draft-ietf-6tisch-dtsecurity-zerotouch-join-03

On 3/5/2019 9:05 AM, Rene Struik wrote:
> computations and where all byte-counts could possibly fit within 
> frames (see my message on "protocol flows" of October 31, 2018 and 
> John Mattson's response hereto of Feb 19, 2019).
> <<RS
>
>> I would like to understand somewhat better how the scheme suggested 
>> in [1] could help in facilitating fast network enrollment and network 
>> formation.
>>
>> 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);
>>
>> 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 
>> 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).}
>>
>> themselves also add to the footprint. The approach of OSCORE and 
>> EDHOC has been to elide redundant information and define a compact 
>> format from the start. Do you think a lossless data compression 
>> performs better?
>>
>> 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.
>>
>> could be message_1 and the last response just an empty payload. Or 
>> the first request can be a trigger and message_1 carried in the first 
>> response.
>>
>> Hope that helps,
>>
>> Göran
>>
>> From [1], Section 1.1:
>>
>> 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.
>>
>>     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).
>>
>>     capabilities of devices (since now one does not need to build-in
>>     a worst-case 2 x "key computation back-off" for least capable
>>                      ��     00

---

From: Göran Selander <[email-masked]>
Date: Mon, 18 Mar 2019 10:08:21 +0000

Hi Rene,

Sorry for slow response to your mails.

From: Rene Struik <[email-masked]<mailto:[email-masked]>>
Date: Friday, 15 March 2019 at 15:28
To: Göran Selander <[email-masked]<mailto:[email-masked]>>, John Mattsson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, 'Benjamin Kaduk' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

Hi Goran:

As you recall, I suggested to look at some details of 6TiSCH enrollment (see my message of March 4, 2019 [1]). During the SecDispatch interim of March 5, 2019, this was provided as one use case scenario [2] and reiterated in your email of yesterday, March 14, 2019 [3]. Nevertheless, details on how this could be realized in practice are still missing.

I had another look at the 6TiSCH minimal security draft [1] (now in 2nd WGLC) and the "zero-touch" write-up [5] -- which you both referenced in your email [3] of yesterday.

To my understanding, the intention with 6TiSCH is to reuse the protocol flows of [4] to implement a public-key based enrollment scheme in the future. This seems to be what [5] aims for, if I try and read in between the [still unwritten] lines, and the impression I got from some people. From looking at the protocol details, though, I do not understand how this can be done in practice. This begs the question what I am missing here.

Hence, my question of March 4th on details of use case scenarios still stands. In fact, I do not see how one could implement EDHOC on top of [4], even if one only uses symmetric-key only variant of EDHOC.

If you could shed some light on this, this would help. Or, should we simply abandon that use case as being unrealistic at this point?

6TiSCH minimal security [4] specifies how a Pledge joining a new network communicates using CoAP with the JRC via a Join Proxy and over additional hops. The proxy operations in the Join Proxy incurs certain overhead in the communication between Proxy and JRC. The exact procedure for the zero-touch is not yet defined, but it is expected to reuse features of the Join Proxy in the minimal security setting. The benchmark in [2] is based on this setting but replacing the OSCORE protection of CoAP with the AKE protocol messages carried over CoAP. Is it more clear now?

Finally, your email [1] suggests "reports of massive breaches with PSK provisioning systems". If so, I would strongly suggest having another look at [4] and commenting on this.

I’m not sure exactly what you want me to comment on. Clearly there are weakness with PSK based systems w/o PFS. But PSK w/o PFS is still used for various reasons, including inability to deploy better security. This inability may be real due to performance limitations or only perceived, for example due to unawareness of intermediary provisioning schemes between PSK and certificates, but in any case PSK w/o PFS is clearly a better alternative than no security at all. One purpose of the work we discuss here is to lower the threshold for PFS.

You mentioned in a previous mail other limitations in the multi-hop setting besides message sizes, and that is indeed true - this is just one benchmark. Is there some specific characteristic you want to highlight in this context?

Göran

Ref:
[1] Details on Use Case Scenarios, email RS of March 4, 2019. Seehttps://mailarchive.ietf.org/arch/msg/ace/On0iIFAb_OWeBqLjlryi1rBHwhk
[2] Slides on EDHOC during SecDispatch meeting of March 5, 2019. Seehttps://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
[3] Pitch for EDHOC, email Goran Selander of March 14, 2019. Seehttps://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
[4] draft-ietf-6tisch-minimal-security-09
[5] draft-ietf-6tisch-dtsecurity-zerotouch-join-03

---

From: Rene Struik <[email-masked]>
Date: Mon, 18 Mar 2019 10:15:29 -0400

Hi Goran:

Unfortunately, it is not clear at all. Details matter: one cannot simply 
wave a magic wand ("not yet defined, but is expected to", etc, etc.).

I am not a big believer in protocol design by email exchange. Security 
protocol design is hard, as is also evidenced by the document history of 
[1], where the initial document was produced in Sep 2016, adopted as WG 
document in Nov 2016, relabeled as another WG document sprout in Sep 
2017 ... and now it is March 2019. Doesn't protocol design start on a 
white board, where one has an initial idea and then systematically work 
through issues, revisits assumptions, etc., rather than produce 
documents and then write the rationale after the fact?

I do not understand the current flurry of emails to push a particular 
design through: why not first coming up with a design requirements 
document that goes further than "byte-count" arguments?

One can do more analysis in the prelude to Montreal, but this is only 
meaningful if one does not cast things in concrete first and then ask 
for feedback, with some external "clients" (including the 6tisch use 
case that I questioned) as motivation. I do understand the motivation to 
claim a stake, but if intention is to reach a billion+ devices, I think 
the bar should be really high.

Ref: 
[1]https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/

[excerpt of what you wrote below]
6TiSCH minimal security [4] specifies how a Pledge joining a new network 
communicates using CoAP with the JRC via a Join Proxy and over 
additional hops. The proxy operations in the Join Proxy incurs certain 
overhead in the communication between Proxy and JRC. The exact procedure 
for the zero-touch is not yet defined, but it is expected to reuse 
features of the Join Proxy in the minimal security setting. The 
benchmark in [2] is based on this setting but replacing the OSCORE 
protection of CoAP with the AKE protocol messages carried over CoAP. *Is 
it more clear now?*

On 3/18/2019 6:08 AM, Göran Selander wrote:
> *From: *Rene Struik <[email-masked] <mailto:[email-masked]>>
> *Date: *Friday, 15 March 2019 at 15:28
> *To: *Göran Selander <[email-masked] 
> <mailto:[email-masked]>>, John Mattsson 
> <[email-masked] <mailto:[email-masked]>>
> *Cc: *"[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>, 'Benjamin Kaduk' 
> <[email-masked] <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC 
> standardization
>
> Hi Goran:
>
> As you recall, I suggested to look at some details of 6TiSCH 
> enrollment (see my message of March 4, 2019 [1]). During the 
> SecDispatch interim of March 5, 2019, this was provided as one use 
> case scenario [2] and reiterated in your email of yesterday, March 14, 
> 2019 [3]. Nevertheless, details on how this could be realized in 
> practice are still missing.
>
> I had another look at the 6TiSCH minimal security draft [1] (now in 
> 2nd WGLC) and the "zero-touch" write-up [5] -- which you both 
> referenced in your email [3] of yesterday.
>
> To my understanding, the intention with 6TiSCH is to reuse the 
> protocol flows of [4] to implement a public-key based enrollment 
> scheme in the future. This seems to be what [5] aims for, if I try and 
> read in between the [still unwritten] lines, and the impression I got 
> from some people. From looking at the protocol details, though, I do 
> not understand how this can be done in practice. This begs the 
> question what I am missing here.
>
> 6TiSCH minimal security [4] specifies how a Pledge joining a new 
> network communicates using CoAP with the JRC via a Join Proxy and over 
> additional hops. The proxy operations in the Join Proxy incurs certain 
> overhead in the communication between Proxy and JRC. The exact 
> procedure for the zero-touch is not yet defined, but it is expected to 
> reuse features of the Join Proxy in the minimal security setting. The 
> benchmark in [2] is based on this setting but replacing the OSCORE 
> protection of CoAP with the AKE protocol messages carried over 
> CoAP. Is it more clear now?
>
> I’m not sure exactly what you want me to comment on. Clearly there are 
> weakness with PSK based systems w/o PFS. But PSK w/o PFS is still used 
> for various reasons, including inability to deploy better security. 
> This inability may be real due to performance limitations or only 
> perceived, for example due to unawareness of intermediary provisioning 
> schemes between PSK and certificates, but in any case PSK w/o PFS is 
> clearly a better alternative than no security at all. One purpose of 
> the work we discuss here is to lower the threshold for PFS.
>
> You mentioned in a previous mail other limitations in the multi-hop 
> setting besides message sizes, and that is indeed true - this is just 
> one benchmark. Is there some specific characteristic you want to 
> highlight in this context?
>
> [1] Details on Use Case Scenarios, email RS of March 4, 2019. 
> Seehttps://mailarchive.ietf.org/arch/msg/ace/On0iIFAb_OWeBqLjlryi1rBHwhk
>
> [2] Slides on EDHOC during SecDispatch meeting of March 5, 2019. 
> Seehttps://datatracker.ietf.org/meeting/interim-2019-secdispatch-01/materials/slides-interim-2019-secdispatch-01-sessa-edhoc.pdf
>
> [3] Pitch for EDHOC, email Goran Selander of March 14, 2019. 
> Seehttps://mailarchive.ietf.org/arch/msg/secdispatch/vNR7nT20fsvYjYXhAPjOpLjZGCU
>

---

From: Göran Selander <[email-masked]>
Date: Tue, 19 Mar 2019 07:55:25 +0000

Hi Rene,

There are two things which has a bearing on the topic we try to progress here:

1. assessing that a certain benchmark is relevant for a particular OSCORE deployment, and
2. assessing how well a solution performs with respect to the benchmark.

I made an attempt to explain one instance of item 1 – people can look up for themselves in [arch] or [0-touch] the protocol flow, the endpoints for the AKE (the Pledge and the JRC) and the role of the proxy (as in the Minimal Security protocol). This information is sufficient for defining the benchmark we are discussing here.

But at the end of the day, it is the users of OSCORE that should evaluate item 1, in this case the 6tisch WG. And this is what happened at the interim when a person active in 6tisch presented the quantification of the benchmark. The discussion about status of 6tisch drafts or potential new design requirement documents is probably better to have on the 6tisch mailing list than on these lists.

Göran

[arch] draft-ietf-6tisch-architecture-20
[0-touch] draft-ietf-6tisch-dtsecurity-zerotouch-join-03, section 2.4-2.5

From: Rene Struik <[email-masked]>
Date: Monday, 18 March 2019 at 15:15
To: Göran Selander <[email-masked]>, John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 'Benjamin Kaduk' <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ace] (details on use case scenario?) Re: [Lwip] EDHOC standardization

Hi Goran:

Unfortunately, it is not clear at all. Details matter: one cannot simply wave a magic wand ("not yet defined, but is expected to", etc, etc.).

I am not a big believer in protocol design by email exchange. Security protocol design is hard, as is also evidenced by the document history of [1], where the initial document was produced in Sep 2016, adopted as WG document in Nov 2016, relabeled as another WG document sprout in Sep 2017 ... and now it is March 2019. Doesn't protocol design start on a white board, where one has an initial idea and then systematically work through issues, revisits assumptions, etc., rather than produce documents and then write the rationale after the fact?

I do not understand the current flurry of emails to push a particular design through: why not first coming up with a design requirements document that goes further than "byte-count" arguments?

One can do more analysis in the prelude to Montreal, but this is only meaningful if one does not cast things in concrete first and then ask for feedback, with some external "clients" (including the 6tisch use case that I questioned) as motivation. I do understand the motivation to claim a stake, but if intention is to reach a billion+ devices, I think the bar should be really high.

Ref: [1] https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/

Hi Goran:

Göran

Ref:

--