Last Call Review of draft-ietf-simple-chat-
review-ietf-simple-chat-secdir-lc-roca-2012-04-11-00

• Status
• Email expansions
• History

• Versions
• 00

Review
review-ietf-simple-chat-secdir-lc-roca-2012-04-11

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

General:
   
The authors, in section 11, discuss several simple security issues.
However I have the feeling that there aren't enough details on how to
avoid/mitigate them. Additionally, I'm not sure the section provides a
comprehensive analysis of security aspects. What about intelligent,
more elaborate attacks? 


Details for section 11 "Security considerations"
---------------------------------------------------------------

** The second paragraph explains several situations where a message can
be sent to several recipients without the sender knowing. It's a good
point to identify this problem, but I'd like to know how it can be
avoided (if possible). 
   
** It is said:
   "It's up to the policy of the MSRP
   switch if the messages are forwarded to the other participant's in
   the chat room using TLS [RFC5246] transport."
   
I'm surprised to see that a participant has no way to enforce a secure
end-to-end connection. At a minimum, can the participant know the
situation in order to take a decision? 
   
** It is said:
   "To avoid takeovers the MSRP switch MUST make sure that a nickname is
   unique inside a chat room."
   
Do you mean the protocol does not guaranty by design that a nickname is
unique at some point of time in a chat room? If this is the case it's
clearly a flaw that should be addressed within the protocol description,
not in the security considerations section.

Another remark: it's not sufficient to guaranty the uniqueness of the
nickname. Phishing attacks show us that two close URLs can mislead a
user, even if the URLs differ by at least one character. It would be 
wiser to recommend that nicknames be significantly different (the MSRP
can probably check the distance between a proposed nickname and those
already registered in the chat session).

** last sentence:
The following sentence is a bit strange and unclear:
   "If a nickname can be reserved if it previously has been used by another
   participant in the chat room, is up to the policy of the chat room."
I suggest:
   
NEW:
  It is up to the policy of the chat room to determine if a nickname that
  has been previously used by another participant of the chat room can
  be reserved or not.

** General:
Several threats are missing in this document. In particular, 
what about attacks where some traffic is intercepted and modified
on-the-fly by the attacker? What about faked messages sent by an
attacker to the MSRP? Can a participant use some integrity service? 
This is not discussed.
              
I'd like to see guidelines on how a participant or MSRP administrator
can define a secure mode of operation. If not possible, I'd like to
see a detailed discussion of existing risks.


Cheers,

    Vincent