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

Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Wed, 03 November 2010 15:02 UTC

Return-Path: <Kurt.Zeilenga@Isode.COM>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A10373A6AC5; Wed, 3 Nov 2010 08:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.342
X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bx5c3JBFHp2o; Wed, 3 Nov 2010 08:02:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 676D828C0DF; Wed, 3 Nov 2010 08:02:20 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 3 Nov 2010 15:02:26 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <>
Date: Wed, 03 Nov 2010 08:02:22 -0700
Message-Id: <F7E7C266-C802-4487-8A0F-DE930EBB2098@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> <>
To: Peter Saint-Andre <>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: Security Area Directorate <>, The IESG <>, XMPP Working Group <>, "" <>
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 15:02:21 -0000

On Nov 3, 2010, at 5:13 AM, Peter Saint-Andre wrote:
> 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.

First, I note that (b) is a no-op in practice.  Implementations are going to support SASL PLAIN regardless.  Hell, we could even MUST NOT it and folks would still implement it.  It's simply too damn necessary for integration with 'legacy' password stores.  (I still rather we not MTI PLAIN.)

Second, (a) only removes one of two significant downgrade attack vectors, the other vector being the mechanisms advertisement and its handling.  (I still rather we remove it.)

While we can well craft our security warnings and considerations and guidance on how to use unauthenticated v. authenticated TLS and hope that client developers get it right.  Basically that text would say "use authenticated TLS" to protect against downgrade attack.  That sounds great but I doubt its going to have much effect (though I think it still should be said).  Clients are still going to offer user's security check bypasses and users are going to continue to take those bypasses.

Also as I noted previously, these problems are not unique to XMPP.  Instead of slowing down the publication of XMPP, it might be better to spin a more general effort to explore ways to address security issues due to general assumption that TLS will be used with server authentication when it is often used without server authentication, and more generally, explore ways to address the "user click through" problem (that is, how to secure protocols such that bypasses are less needed).

Lastly, please note that I don't consider this issue 'critical' at this point.  It's not going to be critical until such attacks are far more common place.  The best way to currently mitigate such attacks is to restrict the set of usable mechanisms to those immune to the attack.  (For enterprises which provide 'client builds' to their users, they can do this for their users as part of those builds.  But, in general, this requires user configuration and hence prone to failure.)

-- Kurt