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

Peter Saint-Andre <> Wed, 03 November 2010 12:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E3FA43A6A9D; Wed, 3 Nov 2010 05:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.524
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jdltAmnKmbBY; Wed, 3 Nov 2010 05:13:40 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 585293A6825; Wed, 3 Nov 2010 05:13:40 -0700 (PDT)
Received: from squire.local ( []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 2E3C940D1E; Wed, 3 Nov 2010 06:22:26 -0600 (MDT)
Message-ID: <>
Date: Wed, 03 Nov 2010 06:13:43 -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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <> <> <> <> <2761.1288645043.347835@puncture> <> <> <> <> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <> <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=
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: "" <>, The IESG <>, XMPP Working Group <>, Security Area Directorate <>
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: 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

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


Peter Saint-Andre