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

Dave Cridland <> Mon, 01 November 2010 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5173F3A6A87; Mon, 1 Nov 2010 13:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h3xSuhOuJ7hs; Mon, 1 Nov 2010 13:57:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 00C163A6A7C; Mon, 1 Nov 2010 13:57:26 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id AE5AB11680F3; Mon, 1 Nov 2010 20:57:27 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s3EOk5vaL05W; Mon, 1 Nov 2010 20:57:23 +0000 (GMT)
Received: from puncture (unknown []) by (Postfix) with ESMTPA id 55DD511680CA; Mon, 1 Nov 2010 20:57:23 +0000 (GMT)
References: <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Message-Id: <2761.1288645043.347835@puncture>
Date: Mon, 01 Nov 2010 20:57:23 +0000
From: Dave Cridland <>
To: Florian Zeitz <>, Yaron Sheffer <>, Security Area Directorate <>, The IESG <>, XMPP Working Group <>, "" <>, Peter Saint-Andre <>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
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: Mon, 01 Nov 2010 20:57:48 -0000

On Mon Nov  1 18:20:03 2010, Florian Zeitz wrote:
> >> I think it's better to remove TLS plus SASL PLAIN from the list  
> of
> >> mandatory-to-implement technologies.
> >>
> > OK.
> >
> FWIW, I'm not entirely content with that for two reasons:

I'll scrap yours, and add a third.

> a) Even if TLS+SASL PLAIN is not MTI people still will and do  
> implement
> it. I think it would therefore make sense to still specify that  
> shall only be used as a "last resort".
I think SASL PLAIN should be specifying this. There's nothing special  
in XMPP which makes PLAIN a poor choice.

> b) (which is my bigger concern) As strange as that may sound, we  
> need
> PLAIN in order to upgrade to a new mechanism. I though this was also
> explicit in 3920bis, but I can't find it right now.
> Consider a case where a server only stores the MD5 hash of the  
> password.
> This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
> different representation is needed.
> The common way for the server to upgrade is to once offer only  
> PLAIN as
> a mechanism. If that is not possible (clients can choose not to  
> support
> PLAIN) some deployments might be stuck with DIGEST MD5...
> We could mandate that PLAIN is only MTI for clients (servers would
> implement it when they need to), but that would allow for the same
> down-grade attacks that are already possible now (i.e. hopefully  
> none ;) ).

You're thinking of transition-needed, which was IIRC removed from the  
bis drafts.

It's pretty scary itself, as it provides an easy path to a downgrade  

But here's another compelling (in my view) reason to keep PLAIN,  
quoted from the opening lines of RFC 4616:

   Clear-text, multiple-use passwords are simple, interoperate with
   almost all existing operating system authentication databases

In particular, where we use an Active Directory, or other third-party  
LDAP directory, we more or less have to drop down to only offering  
PLAIN. (With AD we can also offer GSSAPI sometimes, but this isn't an  
ideal choice for an MTI, and with any LDAP directory we could provide  
SCRAM secrets to some extent).

Requiring clients and servers to be capable of using PLAIN, whilst  
advising (and providing) better alternatives to cover other cases,  
seems to be the best choice for interoperability.

Dave Cridland - -
  - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade