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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 01 November 2010 20:27 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 508B13A69A7; Mon, 1 Nov 2010 13:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.233
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gT9dkr6SpaVV; Mon, 1 Nov 2010 13:27:04 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4422E3A681E; Mon, 1 Nov 2010 13:27:04 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77B8740D1E; Mon, 1 Nov 2010 14:35:37 -0600 (MDT)
Message-ID: <4CCF2298.9030302@stpeter.im>
Date: Mon, 01 Nov 2010 14:27:04 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Florian Zeitz <florob@babelmonkeys.de>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>
In-Reply-To: <4CCF04D3.6020504@babelmonkeys.de>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
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: secdir@ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, draft-ietf-xmpp-3920bis.all@tools.ietf.org
Subject: Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=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

-- 
Peter Saint-Andre
https://stpeter.im/