Draft: draft-ietf-lake-edhoc

Commentary: Further security considerations about how message content is protected against manipulation . Perhaps something like this : " Manipulations of message1 may not be detected at reception since there is no MAC but , since  is included in TH2 , if I and R disagree on message1 then subsequent PRKs and MACs will be different . Manipulations of other messages are detected at reception through the MACs , except for manipulation of the encrypted padding of message2 , since PAD2 is not integrity protected . " 
 I made a PR for this 
 I merged to prepare for submission on -15 . is just a simple clarification . 
 The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity . An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity . In turn , it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled . To judge if this is an issue in practice , the following question should be answered : Are there scenarios where an identity is shared between an initiator and a receiver , but the initiator identity should still be protected ? One could maybe think about the case where multiple initiators and receivers are on the same server , sometimes sharing public keys and using distinct ports , but it is expected that the initiators identities are still protected . Possible actions : mention privacy loss due to the selfie attack mitigation . update the selfie attack mitigation , by mentioning that initiators should conclude the exchange as usual , but can check at the end whether they are talking to themselves or not . remove the selfie attack mitigation . Classical selfie attacks are when there is a pre - shared key between an initiator and a receiver , and the initiator will be talking to itself while it believes to be talking to the receiver . When there are only public keys , as in EDHOC , it is unclear to me if what is currently called in the draft is indeed a selfie attack . An initiator talking to itself knows it and does not believe to be talking to some other identity . As such this is why it could be possible to either remove the mention of selfie attacks in the draft , or update it . 
 I and R are expected to stop the exchange it they receive any identity they do not want to talk to . This likely includes their own identity . Good point that this leaks information . I think that should be , but I do n't see that the own identity is special . Classical selfie attacks are when there is a pre - shared key between an initiator and a receiver , and the initiator will be talking to itself while it believes to be talking to the receiver . When there are only public keys , as in EDHOC , it is unclear to me if what is currently called in the draft is indeed a selfie attack . The selfie attack mitigation is intended for Trust On First Use ( TOFU ) use cases , where there is no authentication in the initial setup . I do n't think an initiator talking to itself in a TOFU use case would not know it except if they checked R 's public key . Do you some better suggestion than " Selfie attack " . I agree that it is not perfect . " Selfie attacks " has in older papers been called reflection attacks , but the term reflection attacks has also been used for very different attacks . One option is to not give the attack any name and instead just describe the attack . 
 I think I like to not give any name , as it does not perfectly match the classical definition . Here , the property which is violated is " If an EDHOC exchange is completed , two distinct identities / computers / agents were active " . Which is different to violating the authentication of the protocol as is the case in classical selfie attacks . Good point . So what we are talking about in this issue is a slightly different privacy leak , which happens when the set of parties you are willing to talk to is equal to all responders minus yourself . To be more concrete , let me try to put it in a kind of drafty formal description that could replace the existing formulation . First the existing formulation : Now a possible replacement : 
 Thanks for the input ! This issue is related to the TOFU use case which is still to be detailed ( Appendix D.5 ) . We probably should wait with the update until we have progressed that . 
 Relates to 
 I made PR for this issue . This is also related to PR and PR . The suggested text in is largely based on the suggested text above but I made some changes . I did not think this fitted well with the rest of the draft . The sentence was also not really needed . This is only true in the case where the set of identifiers is a small finite set . In the general case the set of identifiers the Initiator is not willing to communicate with is infinite . I suggest to add the following recommendation for TOFU To not leak any long - term identifiers , it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange . 
 I merged the PR to master . Keeping the issue open for a while .
Paragraph (version B):
EDHOC messages might change in transit due to a noisy channel or
through modification by an attacker.  Changes in message_1 and
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.