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

"Miguel A. Garcia" <> Mon, 17 September 2012 14:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A49421F842D; Mon, 17 Sep 2012 07:17:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.256
X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cExr3axgyYHJ; Mon, 17 Sep 2012 07:17:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D8DF121F8437; Mon, 17 Sep 2012 07:17:54 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-6b-505731115769
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 2F.6E.25676.11137505; Mon, 17 Sep 2012 16:17:53 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Mon, 17 Sep 2012 16:17:53 +0200
Message-ID: <>
Date: Mon, 17 Sep 2012 16:17:51 +0200
From: "Miguel A. Garcia" <>
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Vincent Roca <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM+Jvra6gYXiAwZv1ihbNa18wWcz4M5HZ 4sPChywWPav6WRxYPJYs+cnkMenFIRaPL5c/swUwR3HZpKTmZJalFunbJXBlLLq9na1gq1jF pubyBsZlgl2MnBwSAiYSC450MELYYhIX7q1n62Lk4hASOMUosWT2N3YIZw2jRN/VW0AZDg5e AW2J3s+6IA0sAqoSz3bdZwGx2QTMJVo3bmQHsUUFgiXObdzGBmLzCghKnJz5BKxGREBD4u7D 18wgM5kFFjBKfHw9jxFkpjBQ8/KLkiA1QgLWEpv/tIMdxClgI7Hr+FpmEJtZwFbiwpzrLBC2 vMT2t3OYIeo1JSbfXMo8gVFwFpJ1s5C0zELSsoCReRWjcG5iZk56uZFealFmcnFxfp5eceom RmAYH9zyW3UH451zIocYpTlYlMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOHnN kdpvlhZLFmef0LL2NLz+ZLqtv8ChmVGKqyUTfQ9oXDdJ28M5c3XzsczNziy8lkLV2e3bJ3RY HfzKZx0/P1bvs9a9fRUdQY8n8thePrIiKIchPd2kN2hd5ItzU6ULGXZFdTJsEjHccJI76ume XDHrooanprfVXBt3lWk6yweZVC82SNZUYinOSDTUYi4qTgQA0Dr96zECAAA=
Cc: "" <>, IESG IESG <>, "" <>
Subject: Re: [secdir] Secdir review of draft-ietf-simple-chat-16
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Sep 2012 14:17:56 -0000

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), ..."


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



> Cheers,
>     Vincent

Miguel A. Garcia
Ericsson Spain