Original text:
CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher. <del> plaintext = ( ID_CRED_R / bstr / int, Signature_or_MAC_2, ? EAD_2 ) </del>  If ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 : kid_R }, then only the byte string or integer kid_R is conveyed in the plaintext encoded accordingly as bstr or int.  Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length of the plaintext. by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see coap). <del> Decrypt CIPHERTEXT_2, see asym-msg2-proc. </del>  Pass EAD_2 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 ) </del>  If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or integer kid_I is conveyed in the plaintext encoded accordingly as bstr or int.  CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Encode message_3 as a CBOR data item as specified in asym- 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. </del>  Pass EAD_3 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm <del> P = ( ? EAD_4 ) </del>  <del> EAD_4 - protected external authorization data, see AD. </del>  CIPHERTEXT_4 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-msg4-proc. </del>  Pass EAD_4 to the security application. Implementations MAY support EAD.  For many constrained IoT devices it is problematic to support several crypto primitives.  Existing devices can be expected to support either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256, for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat- model-guidance.  8.7. EDHOC itself does not provide countermeasures against Denial-of-

Reviewer comments:
NAME NAME Can we merge this?
Yes, the latest updates look good.
The confidentiality protection in EDHOC does not conceal the length of the identifiers IDCREDI and IDCREDR. We should maybe add OPTIONAL padding for deployments wanting to give eavesdroppers less information regarding the length of these identifiers. This could quite easily be achieved by allowign 0 or more simple values (e.g. true) in the beginning of the plaintexts.
Having optional padding is getting quite common. It was part of ESP (but not IKEv2 as far as I know) where it is called traffic flow confidentiality. It is part of the TLS 1.3 record layer. I recently wrote a paper about identity padding URL Based on this work I commented on HPKE which then added guidance on padding.
ESP can pad out to 254 bytes, but not more. IKEv2 has the same format for the encrypted payload, and can do the same, but can also pad within using empty blocks. Nobody does that, AFAIK.
I made a PR. URL The document definitly need to information on that the length of identities can be leaked and that this can be mitigated by e.g., chosing fixed length identifier for all the Initiators. I think OPTIONAL padding should be added for use cases like certificates. I am not sure it will be used very much, but if feels like a feature a security protocol is expected to have.
Based on Carsten's comment in COSE about failure from kid with int, My initial proposal was to make padding support for both sending and receiving optional. Marco commented on the PR and wanted mandatory support on the receiving side. Marco commented during the interim that he also wanted mandatory support on the sending side. Before I update the PR, I think this should be discussed a bit more. There has earlier been comments from NAME and NAME to not increase code size. I agree with Marco that mandatory to support for receiver makes sense. I am not sure about mandatory support for sender. My understanding that code for adding and removing padding would be different pieces of code.
I proposed: For the receiver, mandatory to support, since a padded message might legitimately come at any time. For the sender, optional to use, on a per-message basis. If the sender is surely never going to pad an outgoing message, no need for it to support padding as a sender at all, of course.

For the sender, optional to use I think the important question is if it is mandatory to implement.
Currently the spec says "Padding is OPTIONAL to support." We proposed in the interim ”OPTIONAL to support when sending MANDATORY to support when received" What is the preferred text?
NAME The optional to use per message is already in the PR I think as "may be used". Reading "For the sender, optional to use, on a per-message basis. If the sender is surely never going to pad an outgoing message, no need for it to support padding as a sender at all, of course." It seem like you agree with the suggestion proposed at the interim. We understood it as you proposed changes. The "may be used" could be changes to "optional...." if that is better.
I updated the PR based on the suggestion from Marco and Göran. I also align the text with the other text in the section. New suggested text is As discussed with kid of type int, I don't think mandatory support when recieving is strictly necesary, but might be a good approach anyway.
tl;dr : Thanks, the commit at URL looks good :-) Yes and that's fine, but that's when describing the message processing from the point of view of the sender. The comment referred to Section 7 "Mandatory-to-Implement Compliance Requirements", for which the new text in PR used to say "OPTIONAL to support". The proposed change was to limit that to the sender side (consistent with the above), but mandatory to the recipient side, to ensure it's able to parse the padding if that was included. I think that "may be used" is also fine in those sections about message processing from the point-of-view of the sender.
Seems like we agree on the high level stuff. Me and Göran spotted that "remove" and "discard" might be the wrong words. The requirement should be on being able to parse. Göran will improve the text. After that we are likely ready to merge
I made another commit: 4ee9fc02 MTI section now says: Also some editorials. A difficulty to express what length is hidden since "plaintext" is defined as plain text + padding. This lead to the wording "unpadded plaintext": I kept "discard" in the other parts because I didn't find any good word to substitute for. I didn't like "ignore" or similar as that action seemed to indicate "do nothing". So now it says:
This has been merged. Closing

Revised text:
CIPHERTEXT_2 is calculated by using the Expand function as a binary additive stream cipher.  <ins> plaintext = ( ? PAD, ID_CRED_R / bstr / int, Signature_or_MAC_2, ? EAD_2 ) </ins> If ID_CRED_R contains a single 'kid' parameter, i.e., ID_CRED_R = { 4 : kid_R }, then only the byte string or integer kid_R is conveyed in the plaintext encoded accordingly as bstr or int. <ins> PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext </ins> Compute KEYSTREAM_2 = EDHOC-KDF( PRK_2e, TH_2, "KEYSTREAM_2", h'', plaintext_length ), where plaintext_length is the length of the plaintext. by the transport (e.g., the CoAP Token, the 5-tuple, or the prepended C_I, see coap).  <ins> Decrypt CIPHERTEXT_2, see asym-msg2-proc, and discard padding, if present. </ins> Pass EAD_2 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm  <ins> P = ( ? PAD, ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 ) </ins> If ID_CRED_I contains a single 'kid' parameter, i.e., ID_CRED_I = { 4 : kid_I }, only the byte string or integer kid_I is conveyed in the plaintext encoded accordingly as bstr or int. <ins> PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext </ins> CIPHERTEXT_3 is the 'ciphertext' of COSE_Encrypt0. Encode message_3 as a CBOR data item as specified in asym- 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  <ins> in asym-msg3-proc.  Discard padding, if present. </ins> Pass EAD_3 to the security application. iv_length - length of the initialization vector of the EDHOC AEAD algorithm  <ins> P = ( ? PAD, ? EAD_4 ) </ins>  <ins> EAD_4 - protected external authorization data, see AD.  PAD = 1*true is padding that may be used to hide the length of the unpadded plaintext. </ins> CIPHERTEXT_4 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  <ins> in asym-msg4-proc.  Discard padding, if present. </ins> Pass EAD_4 to the security application. Implementations MAY support EAD. <ins> Implementations MAY support padding of plaintext when sending messages.  Implementations MUST support padding of plaintext when receiving messages, i.e. MUST be able to parse padded messages. </ins> For many constrained IoT devices it is problematic to support several crypto primitives.  Existing devices can be expected to support either ECDSA or EdDSA.  Cipher suites 0 (AES-CCM-16-64-128, SHA-256, for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat- model-guidance. <ins> Information regarding the lengths of ID_CRED_I, ID_CRED_R, EAD_2, EAD_3, and EAD_4 are leaked to an passive attacker.  Many COSE header parameters have variable length.  To mitigate an attacker from differentiating endpoints with identifiers of different length, and implementation may e.g., only use fix length identifiers like 'kid' of length 1 for the Responders.  Alternatively padding may be used to hide the length of e.g., certificates by value in 'x5chain' or 'c5c'. </ins> 8.7. EDHOC itself does not provide countermeasures against Denial-of-