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

["Miguel A. Garcia" <[e-mail]>]

Hi Vincent:

Thanks for your comments, please see my inline answers.

On 11/09/2012 16:14, Vincent Roca wrote:
> 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), ..."
>
>

Perfect.


> ** 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."

Excellent, paragraph added.

>
>
> 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.

Well, the problem is that having a MUST, SHOULD, or MAY to hyperspace has 
the same effect.

My point is that if we have a clear and precise mechanism to mandate, we 
should mandate it. But not having a clear mechanism means that the change 
of a MAY for a SHOULD or a MUST has no effect in live deployments.

BR,

       Miguel


>
>
> Cheers,
>
>     Vincent
>

-- 
Miguel A. Garcia
[phone]
Ericsson Spain