Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17

Ben Campbell <> Tue, 02 November 2010 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E10FC3A68C2; Tue, 2 Nov 2010 15:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rx2bc0q3ee9e; Tue, 2 Nov 2010 15:29:35 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f03:267::2]) by (Postfix) with ESMTP id F17EB3A6774; Tue, 2 Nov 2010 15:29:34 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.3/8.14.3) with ESMTP id oA2MTbRB010857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Nov 2010 17:29:38 -0500 (CDT) (envelope-from
References: <> <> <> <> <2761.1288645043.347835@puncture> <> <> <> <> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <>
Message-Id: <>
From: Ben Campbell <>
To: Peter Saint-Andre <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (7B500)
Mime-Version: 1.0 (iPad Mail 7B500)
Date: Tue, 02 Nov 2010 17:29:36 -0500
Received-SPF: pass ( is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <>, "" <>, Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>, XMPP Working Group <>, The IESG <>
Subject: Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
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, 02 Nov 2010 22:29:37 -0000

(as XMPP chair)

On Nov 2, 2010, at 5:19 PM, Peter Saint-Andre <> wrote:

> On 11/2/10 3:11 PM, Kurt Zeilenga wrote:
>> I think the question can simple as simple as "Should
>> <transition-needed/> be removed?".  I am fine with the question being
>> viewed as "too late" to ask.
> I don't think that folks in the WG would cry if the feature were
> removed, given that:
> 1. It would be used rarely.
> 2. No one has implemented it (AFAIK).
> 3. The text provides many warnings about it.
> 4. It supposedly opens up the possibility of downgrade attacks.
> However, I still fail to see how <transition-needed/> is more evil than
> using SASL, at least if TLS is negotiated first (an attacker could just
> advertise the PLAIN mechanism over the TLS-protected stream, and if an
> attacker has so much control over the server that it can launch attacks
> after TLS has been negotiated then the client is in deep trouble anyway!).
> Furthermore, I think that any client sophisticated enough to support
> <transition-needed/> is going to be sophisticated enough to support
> SCRAM-based mechanisms, which means it can perform a further check to
> make sure that the server really is offering upgraded security
> mechanisms (likely, upgrading from DIGEST-MD5 to SCRAM-SHA-1) before
> sending the password in plaintext over the TLS-encrypted stream. Another
> check: don't use <transition-needed/> more than once with any given XMPP
> service (once is enough!). And never send the plaintext password over an
> unprotected stream. So IMHO we have a number of protections in place and
> that we can safely use the <transition-needed/> feature if we feel that
> we really need it. The question is: do we really need it? We do want to
> encourage folks to migrate from DIGEST-MD5 (lots of interoperability
> issues) to SCRAM, and as part of that upgrade process XMPP services
> might need to collect the plaintext password just once. I'd rather have
> it done over the XMPP channel than, say, via an HTTPS web page (more
> phishing possibilities), but opinions might differ. Feedback from our
> security reviewer and the Security ADs would be especially helpful.
> All that having been said, if we're going to remove the feature then I
> think we need to make sure that the WG has consensus to do so. I leave
> that up to the chairs.

I concur that we need WG consensus to remove this. We can assume we had consensus for the feature to be there in the first place, since it was in the doc as pubreq'd.

Certainly the are room for changes due to post WG review without taking everything back to the WG. This seems to me to border on too big a change for that. It's no big deal to query the work group on it, if we see the need.

> Peter
> -- 
> Peter Saint-Andre