Encrypting C_R

[emanjon]

@marco-tiloca-sics Do you have any opinions on the position of C_R inside the ciphertext?

[charlie-j]

Just say this PR after sending a mail on the ML, but some comments on this:

Hi all,

Seeing this a bit late, but note that this implies to change the TH_2 computation:

TH_2 contains C_R, and TH_2 is used to compute KEYSTREAM_2, itself finally used to encrypt the content of message PLAINTEXT_2.

So, if we put C_R in the PLAINTEXT_2, it needs to be dropped from TH_2, and then added to TH_3.

As a side a node, including C_R in the plaintext will also imply that the construction from https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-19#name-long-plaintext_2 will also need to be used more frequently, which is debatable whether it is a good thing.

Best,

Charlie

[emanjon]

Thanks @charlie-j Thanks for the input. I removed C_R from TH_2. It is already included in TH_3.

We have not decided to do this. But I want to have a PR ready in case we do. Seems quite likely as the security AD is pressing for encryption.

[emanjon]

If we encrypt. @marco-tiloca-sics would like to have C_R first in the plaintext

[marco-tiloca-sics]

If we encrypt. @marco-tiloca-sics would like to have C_R first in the plaintext

Yes, that's in order to be kind with strictly sequential parsers that can find C_R at the beginning of PLAINTEXT_2, i.e., as soon as possible.

[marco-tiloca-sics]

For what is worth and also related to the previous comment on seeing C_R as soon as possible, encrypting C_R has a side effect on the accuracy of error messages sent by the Initiator after processing message_2.

In general, it is a good thing for the Initiator to gain knowledge of C_R as soon as possible. In the old design with C_R not encrypted, that's basically the case as soon as the Initiator parses a well-formed message_2.

This means that, right after that, any error message sent by the Initiator can be prepended by C_R, thus allowing the Responder to retrieve the exact EDHOC session to abort.

In the new design, there is a wider sequence of steps that the Initiator has to take (up until and including the decryption of PLAINTEXT_2), before it can gain knowledge of C_R and thus proceed as above. If an error occur before then, it is of course still possible to send an error message to the right Responder peer, but without a prepended C_R. Hence, the Responder would not know which exact EDHOC session it should abort (unless this Responder has only one ongoing session with the Initiator sending the error message).

To be clear, I understand the rationale about encrypting C_R in message_2 and support it. At the same time, it is good to also elaborate on such side effects.

[chrysn]

The error handling aspect doesn't seem all that bad to me. In the typical scenario with a client as initiator, it's the client that has to act on the error anyway (eg. by sending different EAD1 or whatever else can be done in that situation). In the reverse direction with the server as Initiator, the client can still send M2 easily (because C_I is unencrypted), and on error processing M2, M3 reaches the client on the return channel without explicit use of C_R.

[gselander]

About the side note by @charlie-j on increased size of PLAINTEXT_2 and the need to use the Long PLAINTEXT_2 mechanism more frequently: I don't think this is a major drawback since the cut-off is larger than 8 kB and the size of C_R typically much smaller.

[gselander]

As there is WG consensus to encrypt C_R https://mailarchive.ietf.org/arch/msg/lake/W9tEMIhGT_i5SzbjrR9BNy_Biqs/ we plan to merge this PR soon to make the draft ready for last call. Further comments are still welcome, also after merge.