[secdir] Secdir review of draft-ietf-simple-chat-16

[Vincent Roca <[e-mail]>]

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.


Since we already exchanged emails during the secdir review of version
-14 of this document, I'll be brief.


** It is said:

  "If a participant wants to avoid eavesdropping, the participant's MSRP
   client can send the messages over a TLS [RFC5246] transport
   connection, as allowed by MSRP.  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."

A participant cannot prevent eavesdropping if he does not control
the end-to-end use of TLS. Additionally, as discussed previously,
there are other benefits in the use of TLS, like preventing faked packet
injection, or on-the-fly corruption of messages. So I suggest to clarify a
bit:

NEW:

  "If a participant wants to avoid security concerns on the path between
   himself and the MSRP switch (e.g., eavesdropping, faked packet injection
   or packet corruption), ..."


** About attacks with close but different nicknames:
I see that a new paragraph has been added to section 7.1 to discuss
this issue. That's excellent. However the security section does not
provide any pointer to this discussion, nor does it mention the problem.
The only aspect discussed is the reuse of nicknames which is a different
(but important) topic. So I suggest to add a paragraph:

NEW:

  "Section 7.1.discusses the problem of similar but different
   nicknames (e.g., thanks to the use of similar characters),
   and chat rooms MAY provide a mechanism to mitigate confusable
   nicknames."


BTW, current I-D says that a chat room **MAY** provide such a mechanism.
Should we change it for SHOULD? Said differently, is there a good reason
for a chat room not to perform such verifications? If the answer is yes,
then we can keep MAY.


Cheers,

   Vincent