Hi Rene,

These are interesting ideas. As you say, EDHOC is currently optimized for a 
minimum number of messages and bytes. Spreading out the bytes and computations 
could be beneficial in some applications. EDHOC is currently based on SIGMA-I. 
The four-message variant would be based on SIGMA-R with basically the same 
security properties. The difference would be that SIGMA-I protects the 
initiator identity against active attackers and the non-initiator identity 
against passive attackers. SIGMA-R does the opposite. I think protection models 
are needed in practice, but could also be solved by letting the initiator 
telling the other party to start SIGMA-I.

Party U                                                       Party V
|              C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U            |
+------------------------------------------------------------------>|
|                             message_1                             |
|                                                                   |
|                           C_U, C_V, X_V                           |
|<------------------------------------------------------------------+
|                             message_2                             |
|                                                                   |
|          C_V, AE(K_3; ID_CRED_U, Sig(U; CRED_U, aad_3) )          |
+------------------------------------------------------------------>|
|                             message_3                             |
|                                                                   |
|          C_U, AE(K_4; ID_CRED_V, Sig(V; CRED_V, aad_4) )          |
|<------------------------------------------------------------------+
|                             message_4                             |

I get the following message sizes for EDHOC when I apply SIGMA-R to
version -11 of EDHOC.

========================================================================
Flight                                #1      #2     #3     #4     Total
------------------------------------------------------------------------
DTLS 1.3 RPK + ECDHE                 150     373    213              736
DTLS 1.3 PSK + ECDHE                 187     190     57              434
DTLS 1.3 PSK                         137     150     57              344
------------------------------------------------------------------------
EDHOC RPK + ECDHE (SIGMA-I)           39     120     85              244
EDHOC RPK + ECDHE (SIGMA-R)           39      37     85     84       245
EDHOC PSK + ECDHE                     44      46     11              101
========================================================================

Regarding computations, I guess the main difference when it comes to 
asymmetrical crypto computations would be that Party V can compute a shared 
secret in between flight #2 and flight #3. Or are the any additional benefits?

SIGMA-I:

Party U                                                       Party V
                                                                    
generate a key pair
+-------------------------------#1--------------------------------->|
                          generate a key pair (can be done before #1)
                                              compute a shared secret
                                                                 sign
|<------------------------------#2----------------------------------+
compute a shared secret
verify
sign
+-------------------------------#3--------------------------------->|
                                                               verify

SIGMA-R:

Party U                                                       Party V
                                                                    
generate a key pair
+-------------------------------#1--------------------------------->|
                          generate a key pair (can be done before #1)
              compute a shared secret (can be done between #2 and #3)
|<------------------------------#2----------------------------------+
compute a shared secret
sign
+-------------------------------#3--------------------------------->|
                                                               verify
                                                                 sign
|<------------------------------#4----------------------------------+
verify

The optimization to split up the ECDSA Signature (R, S) and send R in the 
beginning is interesting, but as far as I understand, this only works for ECDSA 
and there is no similar trick for Ed25519 as both R and S depends on the 
message M.

SIGMA-I:

Party U                                                       Party V
|           C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, R_U          |
+------------------------------------------------------------------>|
|                             message_1                             |
|                                                                   |
|          C_U, C_V, X_V, AE(K_2; ID_CRED_V, R_U, S_U )             |
|<------------------------------------------------------------------+
|                             message_2                             |
|                                                                   |
|                  C_V, AE(K_3; ID_CRED_U, S_V )                    |
+------------------------------------------------------------------>|
|                             message_3                             |

SIGMA-R:

Party U                                                       Party V
|             C_U, CIPHER_SUITEs_U, CIPHER_SUITE_U, X_U, R_U        |
+------------------------------------------------------------------>|
|                             message_1                             |
|                                                                   |
|                        C_U, C_V, X_V, R_V                         |
|<------------------------------------------------------------------+
|                             message_2                             |
|                                                                   |
|                     C_V, AE(K_3; ID_CRED_U, S_U)                  |
+------------------------------------------------------------------>|
|                             message_3                             |
|                                                                   |
|                    C_U, AE(K_4; ID_CRED_V, S_V )                  |
|<------------------------------------------------------------------+
|                             message_4                             |


======================================================================================
Flight                                              #1      #2     #3     #4    
 Total
--------------------------------------------------------------------------------------
DTLS 1.3 RPK + ECDHE                               150     373    213           
   736
DTLS 1.3 PSK + ECDHE                               187     190     57           
   434
DTLS 1.3 PSK                                       137     150     57           
   344
--------------------------------------------------------------------------------------
EDHOC RPK + ECDHE (SIGMA-I)                         39     120     85           
   244
EDHOC RPK + ECDHE (SIGMA-R)                         39      37     85     84    
   245
EDHOC RPK + ECDHE (SIGMA-I)(ECDSA split S and R)    71     120     53           
   244
EDHOC RPK + ECDHE (SIGMA-R)(ECDSA split S and R)    71      69     53     52    
   245
EDHOC PSK + ECDHE                                   44      46     11           
   101
======================================================================================

I think these are interesting discussion topics. I will make an issue about 
them on GitHub.

Cheers,
John

Rene Stuik <rstruik....@gmail.com>; 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

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

Reply via email to