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

Florian Zeitz <> Mon, 01 November 2010 18:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9E32428C0E5; Mon, 1 Nov 2010 11:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WkYpnJDRo5Cs; Mon, 1 Nov 2010 11:20:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 621D328C0E0; Mon, 1 Nov 2010 11:20:11 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <>) id 1PCyzJ-0004My-N6; Mon, 01 Nov 2010 19:20:09 +0100
Message-ID: <>
Date: Mon, 01 Nov 2010 19:20:03 +0100
From: Florian Zeitz <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Cc:,, XMPP <>,
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 18:20:12 -0000

On 01.11.2010 10:25, Yaron Sheffer wrote:
> Hi Peter,
> Responding to the last part. Thanks for a constructive discussion.
>     Yaron

>>> - 15: if we insist on PLAIN, I would expect a security-mti-auth-order
>>> feature, where the proposals are ordered right (i.e. with PLAIN at the
>>> end).
>> 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:
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 PLAIN
shall only be used as a "last resort".

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 ;) ).

Florian Zeitz