Change:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.

Discussion:
CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher over the following plaintext: <del> PLAINTEXT_2 = ( ? PAD, ID_CRED_R / bstr / -24..23, </del> <ins> PLAINTEXT_2 = ( ? PAD_2, ID_CRED_R / bstr / -24..23, </ins> Signature_or_MAC_2, ? EAD_2 ) If ID_CRED_R contains a single 'kid' parameter, i.e.,

is conveyed in the plaintext, represented as described in bstr-repr. <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del> <ins> PAD_2 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext Compute KEYSTREAM_2 as in expand, where plaintext_length is the

prepended C_I, see coap). Decrypt CIPHERTEXT_2, see asym-msg2-proc, and, if present, discard <del> padding. </del> <ins> the padding PAD_2. </ins> Make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing.

K_3 and IV_3 are defined in <del> PLAINTEXT_3 = ( ? PAD, ID_CRED_I / bstr / -24..23, </del> <ins> PLAINTEXT_3 = ( ? PAD_3, ID_CRED_I / bstr / -24..23, </ins> Signature_or_MAC_3, ? EAD_3 ) If ID_CRED_I contains a single 'kid' parameter, i.e.,

is conveyed in the plaintext, represented as described in bstr-repr. <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del> <ins> PAD_3 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0.

Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg3-proc.  Discard padding, if present. </del> <ins> in asym-msg3-proc.  Discard the padding PAD_3, if present. </ins> Make ID_CRED_I and (if present) EAD_3 available to the application for authentication- and EAD processing.

K_4 and IV_4 are defined in <del> PLAINTEXT_4 = ( ? PAD, ? EAD_4 ) </del> <ins> PLAINTEXT_4 = ( ? PAD_4, ? EAD_4 ) </ins> <del> PAD = 1* "true" (see CBOR) is padding that may be used to </del> <ins> PAD_4 = 1* "true" (see CBOR) is padding that may be used to </ins> hide the length of the unpadded plaintext. EAD_4 - external authorization data, see AD.

Decrypt and verify the COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I-D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm in the selected cipher suite, and the parameters defined <del> in asym-msg4-proc.  Discard padding, if present. </del> <ins> in asym-msg4-proc.  Discard the padding PAD_4, if present. </ins> Make (if present) EAD_4 available to the application for EAD processing.