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

Peter Saint-Andre <> Tue, 26 October 2010 04:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA8843A684C; Mon, 25 Oct 2010 21:08:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.567
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ur5i4Xl4xTBd; Mon, 25 Oct 2010 21:08:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 526F73A683A; Mon, 25 Oct 2010 21:08:25 -0700 (PDT)
Received: from squire.local ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 788FA40D1E; Mon, 25 Oct 2010 22:18:06 -0600 (MDT)
Message-ID: <>
Date: Mon, 25 Oct 2010 22:10:09 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Richard L. Barnes" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
OpenPGP: url=
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:,, XMPP <>,
Subject: Re: [secdir] SECDIR review of draft-ietf-xmpp-3921bis-15.txt
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 Saint-Andre