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

Peter Saint-Andre <> Mon, 01 November 2010 20:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 508B13A69A7; Mon, 1 Nov 2010 13:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.233
X-Spam-Status: No, score=-101.233 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gT9dkr6SpaVV; Mon, 1 Nov 2010 13:27:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4422E3A681E; Mon, 1 Nov 2010 13:27:04 -0700 (PDT)
Received: from squire.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 77B8740D1E; Mon, 1 Nov 2010 14:35:37 -0600 (MDT)
Message-ID: <>
Date: Mon, 01 Nov 2010 14:27:04 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Florian Zeitz <>
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
OpenPGP: url=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms080703010400030906010709"
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 20:27:05 -0000

On 11/1/10 12:20 PM, Florian Zeitz wrote:
> On 01.11.2010 10:25, Yaron Sheffer wrote:
>>>> - 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".

I think that's what we were trying to say in the text, but we didn't do
a good job of it.

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

I had forgotten about that use case, so thanks for the reminder.

Sometime in the next 24-48 hours I'll propose rewritten text about MTI
technologies, including TLS + SASL PLAIN. However it requires careful
crafting and unfortunately I don't have time to do that right now.


Peter Saint-Andre