Re: [secdir] SECDIR review of draft-ietf-xmpp-3921bis-15.txt

Peter Saint-Andre <stpeter@stpeter.im> Tue, 26 October 2010 04:08 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8843A684C; Mon, 25 Oct 2010 21:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.567
X-Spam-Level:
X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur5i4Xl4xTBd; Mon, 25 Oct 2010 21:08:25 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 526F73A683A; Mon, 25 Oct 2010 21:08:25 -0700 (PDT)
Received: from squire.local (dsl-179-124.dynamic-dsl.frii.net [216.17.179.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 788FA40D1E; Mon, 25 Oct 2010 22:18:06 -0600 (MDT)
Message-ID: <4CC654A1.7020502@stpeter.im>
Date: Mon, 25 Oct 2010 22:10:09 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <4CC63813.5070101@bbn.com>
In-Reply-To: <4CC63813.5070101@bbn.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms010703080903010906020308"
X-Mailman-Approved-At: Tue, 26 Oct 2010 18:28:17 -0700
Cc: draft-ietf-xmpp-3921bis@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-3921bis-15.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 26 Oct 2010 04:08:26 -0000

Thanks for the review. One comment inline.

On 10/25/10 8:08 PM, Richard L. Barnes wrote:
> 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.
> 
> This document describes an instant-messaging and presence system based
> on the core system of exchanging XML stanzas described in RFC 3920 and
> draft-ietf-xmpp-3920bis.  As the document rightly notes, the underlying
> transport protocol addresses most of the security considerations for
> this document, and that document seems to have a thorough discussion of
> security considerations (although I have not done a thorough review). In
> general, I think that the security considerations in this document
> adequately describe the additional risks posed by the instant-messaging-
> and presence-specific parts of the protocol (beyond those of the base
> protocol), and corresponding mitigations.
> 
> One thing that might merit clarification: The overriding
> application-layer security concern here is the proper routing of
> presence and instant messaging stanzas through the XMPP system.
> (Underlying communications security concerns are addressed by the core
> spec.)  For the most part, these concerns with requirements on servers
> to act in certain ways on behalf of the user.  It could be helpful to
> the reader to re-state some of the communications patterns from Section
> 13.1 of draft-ietf-xmpp-3920bis and comment on the particular roles that
> the entities play in the context of instant messaging and presence
> (e.g., routing unicast <message> stanzas, fan-out of broadcast presence
> messages).

Although in general I'm not a fan of repeating material that is already
covered by a referenced specification, I agree that it might be
appropriate to provide a reminder about the underlying architecture of
XMPP and its implications for the security of various IM-related and
presence-related interactions. I'll reply again once I have investigated
the best location for such a reminder and have formulated proposed text.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/