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

Vincent Roca <vincent.roca@inria.fr> Tue, 11 September 2012 14:14 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7C4F721F8807; Tue, 11 Sep 2012 07:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.249
X-Spam-Status: No, score=-110.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8eWn4P6t5vTl; Tue, 11 Sep 2012 07:14:37 -0700 (PDT)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr []) by ietfa.amsl.com (Postfix) with ESMTP id 8607321F87BF; Tue, 11 Sep 2012 07:14:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.80,405,1344204000"; d="scan'208";a="155352745"
Received: from geve.inrialpes.fr ([]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 11 Sep 2012 16:14:34 +0200
From: Vincent Roca <vincent.roca@inria.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Tue, 11 Sep 2012 16:14:34 +0200
Message-Id: <50F825B5-5FDA-4F28-BDE2-7A77B6FF87AF@inria.fr>
To: IESG IESG <iesg@ietf.org>, draft-ietf-simple-chat.all@tools.ietf.org, secdir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Subject: [secdir] Secdir review of draft-ietf-simple-chat-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Sep 2012 14:14:37 -0000


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


  "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:


  "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

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.