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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 03 November 2010 12:13 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 E3FA43A6A9D; Wed, 3 Nov 2010 05:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level:
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 jdltAmnKmbBY; Wed, 3 Nov 2010 05:13:40 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 585293A6825; Wed, 3 Nov 2010 05:13:40 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E3C940D1E; Wed, 3 Nov 2010 06:22:26 -0600 (MDT)
Message-ID: <4CD151F7.6060809@stpeter.im>
Date: Wed, 03 Nov 2010 06:13:43 -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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>
In-Reply-To: <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>
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="------------ms020301000600030603070603"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@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: Wed, 03 Nov 2010 12:13:42 -0000

On 11/2/10 6:14 PM, Kurt Zeilenga wrote:
> 
> On Nov 2, 2010, at 3: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!).
> 
> I think you are considering the issue under a different assumptions
> than I.  I am assuming the user has clicked through any and all
> warnings they were faced with.  I am assuming the client did not well
> implement handling all cases.
> 
> For instance, if the user clicked said "connect anyways" to a
> certificate verification/subject check warning, a decent client would
> still warn if it previously used SCRAM-SHA1-PLUS and now is only
> getting SCRAM-SHA1 or just PLAIN, and warning about downgrade
> possibilities with transition-needed.  But far too often clients, not
> surprisingly, will assume that "connect anyways" means that TLS is
> good for purposes (e.g., server has been authenticated by the user by
> means outside the clients control) instead of "good enough for use
> with mechanisms that provide mutual authentication".  Of course, what
> the user meant was "just connect, damn it".
> 
> Our application protocol security designs are far too reliant on
> users making non-trival decisions, and far too complex for client
> developers to well implement.  (Such issues are certainly not limited
> to XMPP.)   We ought to design our protocols to avoid having to ask
> the user to make non-trival decisions, and simplify things the client
> developers as much possible (such as by ensuring key protocol bits
> are adequately protected from various attacks, instead of "TLS will
> save us").  And to make matters worse, we tend to repeat 'bad
> designs' (The transition-needed error in protocols has been a problem
> since introduced, as it never been protected by the SASL exchange.)
> 
>> Furthermore, I think that any client sophisticated enough to
>> support <transition-needed/> is going to be sophisticated enough to
>> support SCRAM-based mechanisms,
> 
> I disagree here.  A client developer is likely to implement
> transition-needed without at all thinking about the implications of
> whether "connect anyways" means "good enough for mechanism which
> provides server authentication and channel bindings" or simply "good
> enough for anything the server might ask us to do".  And, of course,
> the user just meant "I don't care about this" (but that doesn't mean
> the server operator does care).
> 
> Note that I don't mean to blame the user or the client developer
> here, I mean to blame the protocol designers for pushing these
> problems upon them.
> 
>> 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.
> 
> And if it notices an issue, what, prompt the user again?
> 
>> Another check: don't use <transition-needed/> more than once with
>> any given XMPP service (once is enough!).
> 
> Once is enough?  I don't think so.
> 
>> And never send the plaintext password over an unprotected stream.
> 
> Ah, some will take "unprotected" to mean its okay to send the
> password over a stream so long as it has data integrity and data
> confidentiality protection.
> 
> That isn't enough.  One ought not send a plaintext password without
> server authentication (preferably that's bound to the protected
> stream end-point).  If the user may have intended to rely on SCRAM
> for server authentication, then just having TLS without any server
> authentication is not good enough.
> 
>> So IMHO we have a number of protections in place
> 
> The only protections we have assumption that TLS is used with
> client's authentication of the server.  That's a hell of an
> assumption with todays use of TLS on the Internet.   Certainly
> <transition-protected/> is not protected in XMPP use without TLS but
> with SASL security layers.
> 
> Of course, we also rely on this assumption to prevent downgrade via
> mechanism advertisements.  We really ought to do something about that
> as well.
> 
>> 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.
> 
> Or again if they select SCRAM specific secrets and then realize they
> still need to support DIGEST-MD5. Or they decide to move to some
> other password based mechanism and its mechanism specific secret.
> 
> It's not '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.
> 
> I rather have it done in a well-protected XMPP channel.   I don't
> consider the use transition-needed and TLS*+PLAIN as generally well
> protected.
> 
> (* TLS as often implemented and used on the Internet, e.g., without
> authentication).
> 
>> 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.
> 
> Of course.

You make a compelling argument. I wish you had made that argument months
ago, but it is compelling. Indeed, it leads in the direction of two
consensus calls within the XMPP WG:

(a) to remove the <transition-needed/> SASL error condition

(b) to remove TLS plus SASL PLAIN as MTI for confidentiality and
authentication

Ideally, both of those changes would be accompanied by additional
security-related text, and in case (b) an interoperability note.

Peter

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