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

Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Wed, 03 November 2010 00:14 UTC

Return-Path: <Kurt.Zeilenga@Isode.COM>
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 84A2F3A6A51; Tue, 2 Nov 2010 17:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.149
X-Spam-Level:
X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 M91h49kW1CSP; Tue, 2 Nov 2010 17:14:19 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F094C3A6A50; Tue, 2 Nov 2010 17:14:18 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id <TNCpXQAEeWm5@rufus.isode.com>; Wed, 3 Nov 2010 00:14:23 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD08E62.3060202@stpeter.im>
Date: Tue, 02 Nov 2010 17:14:19 -0700
Message-Id: <03C37501-30DB-4C80-8358-DD853EF59F1A@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>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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 00:14:20 -0000

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.

-- Kurt