Change:
-
URL Hi all, Following our previous analysis of the draft 12 and 14, we have now updated our models w.r.t. draft 17, making a full pass over both the protocol changes as well as the security considerations mentioned through out the draft. Overall, there is a last security claim that is slightly wrong from a theoretical point of view, but in practice does not bear consequences. We detail it bellow. Otherwise, our automated analysis was not able to find any other weakness, so we hope that with respect to state of the art analysis techniques, the protocol is in a pretty good shape. It concerns the following point, page 42: "Changes in message1 and message2 (except PAD2) are detected when verifying SignatureorMAC2. " This claim in fact dependson the security level of the signature scheme used. Assume that we have a signature scheme such that given "Sign(m,sk)", the signature of message m with secret key sk, there exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid signature for the same message m under sk. This is nota violation of the classical assumption over signatures (EUFCMA), and with such a signature scheme, an attacker could then change the content of message_2, by xoring the signature part with the constant c, and this change would not be detectedafter verifying the signature, and would only be caught on a message 4 or key confirmation. This is only a theoretical attack, relying on the difference between the classical cryptographic assumption EUF-CMA, a signature authenticates only the underlying message, while underthe stronger SUF-CMAassumption, a signature authenticates both the underlying message and the signature itself.Noneof the concrete signature scheme currently standardized appears to bemalleable under xor. We report it for thoroughness, but are uncertain whether the sentence should be changedor not. Best, Charlie Jacomme, Elise Klein,Steve KremerandMaïwenn Racouchot.
I think this would be caught when verifying CIPHERTEXT_3
The PR looks fine to me! When mentioning message 4 or key confirmation, I was specifying when the change would be detected on the initiator side, but the responder would indeed detect it when verifying CIPHERTEXT_3. Hi all, Following our previous analysis of the draft 12 and 14, we have now updated our models w.r.t. draft 17, making a full pass over both the protocol changes as well as the security considerations mentioned through out the draft. Overall, there is a last security claim that is slightly wrong from a theoretical point of view, but in practice does not bear consequences. We detail it bellow. Otherwise, our automated analysis was not able to find any other weakness, so we hope that with respect to state of the art analysis techniques, the protocol is in a pretty good shape. It concerns the following point, page 42: "Changes in message1 and message2 (except PAD2) are detected when verifying SignatureorMAC2. " This claim in fact dependson the security level of the signature scheme used. Assume that we have a signature scheme such that given "Sign(m,sk)", the signature of message m with secret key sk, there exists a constant "c" such that "Sign(m,sk) XOR c" is also a valid signature for the same message m under sk. This is nota violation of the classical assumption over signatures (EUFCMA), and with such a signature scheme, an attacker could then change the content of message_2, by xoring the signature part with the constant c, and this change would not be detectedafter verifying the signature, and would only be caught on a message 4 or key confirmation. This is only a theoretical attack, relying on the difference between the classical cryptographic assumption EUF-CMA, a signature authenticates only the underlying message, while underthe stronger SUF-CMAassumption, a signature authenticates both the underlying message and the signature itself.Noneof the concrete signature scheme currently standardized appears to bemalleable under xor. We report it for thoroughness, but are uncertain whether the sentence should be changedor not. Best, Charlie Jacomme, Elise Klein,Steve KremerandMaïwenn Racouchot.

Discussion:
EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and <del> message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </del> <ins> message_2 (except PAD_2 and Signature_or_MAC_2 when the signature scheme is not strongly unforgeable) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2, not strongly unforgeable Signature_or_MAC_2, and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as