Draft: draft-ietf-lake-edhoc

Commentary: 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 Based on this work I commented on HPKE which then 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 . 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 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  's comment in COSE about failure from kid with int , My initial proposal was to make padding support for both sending and receiving optional .  commented on the PR and wanted mandatory support on the receiving side .  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 and to not increase code size . I agree with  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 ? 
 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  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 do n't think mandatory support when recieving is strictly necesary , but might be a good approach anyway . 
 tl;dr : Thanks , the commit at 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  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 : 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 did n't find any good word to substitute for . I did n't like " ignore " or similar as that action seemed to indicate " do nothing " . So now it says : 
 This has been merged . Closing
Paragraph (version A):
Decrypt CIPHERTEXT_2, see asym-msg2-proc.
Paragraph (version B):
Decrypt CIPHERTEXT_2, see asym-msg2-proc, and discard padding, if
present.
Paragraph (version A):
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
in asym-msg3-proc.
Paragraph (version B):
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
in asym-msg3-proc.  Discard padding, if present.
Paragraph (version A):
EAD_4 - protected external authorization data, see AD.
Paragraph (version B):
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.
Paragraph (version A):
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
in asym-msg4-proc.
Paragraph (version B):
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
in asym-msg4-proc.  Discard padding, if present.
Paragraph (version B):
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.
Paragraph (version B):
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'.