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

[Vincent Roca <[e-mail]>]

Hello Miguel,

Sorry for the delay in answering your email. Otherwise I've replied below
and removed items where we agree.


>> 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).
> 
> Effort was made to lower the barrier of endpoints, so that conference-unaware participants were able to join and still have some basic chat functionality. If possible, we would like to keep this feature.
> 
> I see a couple of immediate possible solutions:
> 
> 1) We forbid conference-unaware participants to join the chat room, for example, by accepting the session to a virtual chat room where the only participants is the MSRP switch itself, which sends a message indicating that the client does not support the required features, and disconnects it. This forbids conference-unaware participants joining the chat room, and it is not desirable.
> 
> 2) We force the MSRP switch to send one or more messages to conference-unaware participants, indicating that this is a chat room, their client does not support all the features, we send the roster as text, and indicate that all messages will be further distributed to the whole chat room. Basically, we tell the user (and not its software) that this is a chat room.
> 
> If 2 is acceptable, I will go for it.

I think that 2) is fine, but I'm not an expert, I don't understand the protocol, and I don't
want you to introduce new features at this stage of the process if there are risks of
breaking anything. My comment was an open one.


>> ** 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?
> 
> A participant can control if TLS is used between his endpoint and the MSRP switch. But this participant cannot control if the MSRP switch uses TLS to deliver messages to the rest of the participant. This is because each pair of endpoint-MSRPswitch session is independent of each other, so, it is possible for the chat room to have a mixture of secure and non-secure MSRP session.
> 
> It is possible for an MSRP switch to have a local policy enforcing that TLS will be required for sending/receiving MSRP messages. Since this does not affect interoperability, we haven't mentioned anything, but if you guys feel more comfortable indicating this fact, we can always add a paragraph.

So it seems to be a intrinsic limitation that directly derives from this endpoint-MSRP
independency. You can probably explain this in the section. I can understand that
a protocol has limitations derived for design choices.
Otherwise your proposal is fine in the sense it can help in some situations where
this policy is acceptable.


>> ** 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.
> 
> 
> Yes, the selection of a nickname guaranties that a nickname is unique in the chat room. This is described in Section 7.1:
> 
>   The reservation of a nickname can also fail if the value of the
>   Use-Nickname header field of the NICKNAME request is a reserved word
>   (not to be used as a nickname by any user) or that particular value
>   is already in use by another user.  In this case the MSRP switch MUST
>   answer the NICKNAME request with a 425 response code.
> 
> That paragraph you quoted is just implicitly referring to the paragraph that I just quoted.

Okay. I suggest you add a reference to section 7.1 in that case.


>> 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).
> 
> We can add such paragraph. However, there has been some e-mail discussion on the topic, in conjunction with the internationalization of characters in nicknames. I will point you to a couple of interesting e-mails.
> 
> Peter Saint-Andre mention here that avoiding confusable nicknames should be optional:
> http://www.ietf.org/mail-archive/web/simple/current/msg09894.html
> 
> And in this other e-mail, Peter indicates the confusion that different (but still similar) characters can create
> http://www.ietf.org/mail-archive/web/simple/current/msg09887.html
> 
> I believe it is hard, if not impossible, to fight the latter.

So I suggest a small sentence summarizing this to remind implementers
that there is still a risk, even if nicknames are different.


>> ** 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?
> 
> If TLS is used for delivering MSRP messages, then this attack should not be possible.

Yes but it's perhaps worth mentioning it (it was the goal of my comment).


>> What about faked messages sent by an
>> attacker to the MSRP?
> 
> TLS will also prevent this attack. If TLS is used to transport MSRP messages, then an attacker could not impersonate a participant and inject false messages.

Same answer. 


>> Can a participant use some integrity service?
>> This is not discussed.
> 
> Here the solution should either be TLS or S/MIME.
> 
> For all the threats, remember that this draft builds on MSRP. Therefore, the security considerations of RFC 4975 apply. TLS and S/MIME is discussed in there, and they apply to this draft.

I must confess I haven't looked at RFC4975. So, if this is discussed there,
it's just sufficient to refer to the RFC.


>> 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.
> 
> Can you please elaborate what else on top of RFC 4975 we need to discuss? Are you referring to indicating that it is RECOMMENDED that the MSRP switch only accepts TLS-protected MSRP sessions or is it something else?

No, see just above.

Cheers,

   Vincent