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

Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Tue, 02 November 2010 19:03 UTC

Return-Path: <Kurt.Zeilenga@Isode.COM>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E05D03A6A07; Tue, 2 Nov 2010 12:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pg4uDaYCc9q4; Tue, 2 Nov 2010 12:03:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CEF823A69D8; Tue, 2 Nov 2010 12:03:35 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 2 Nov 2010 19:03:39 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <>
Date: Tue, 02 Nov 2010 12:03:31 -0700
Message-Id: <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM>
References: <> <> <> <> <2761.1288645043.347835@puncture> <> <> <> <> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@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: "" <>, 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: Tue, 02 Nov 2010 19:03:37 -0000

On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:

>> I suspect I'm in the rough on both points.  Oh well.
>>> 2. The technology that the XMPP community uses for account
>>> registration (XEP-0077) could benefit from an update, or even a
>>> replacement, and when that work is completed I'd like to include a
>>> method by which a client could register a key or cert with the
>>> server, thus smoothing the path toward password-less
>>> authentication. IMHO that will be the best approach in the longer
>>> term, instead of continually tweaking the password-based methods.
>>> But that's a topic for another time...
>> I also think transition-needed needs to be deprecated in favor of
>> transition within the bound channel (e.g., today via XEP 77, tomorrow
>> ?).
> I'm not sure exactly what "transition within the bound channel" is, but
> it sounds worthy of discussion when we work on 3920ter.

The problem with transition-needed is that the error is sent outside the bound channel.

By "within the bound channel", I mean a transitioning method, including any necessary signaling, would be performed inside the bound channel, that is, within the new <stream:stream/> protected by the SASL exchange.

> At this point I
> don't think the XMPP community has a great deal of experience with, or
> even understanding of, channel binding, so it's difficult for us to make
> strong recommendations that depend on channel binding.

It would be same issue of doing transition outside of a SASL negotiated security layer.  It's prone to attack.  And the fix is the same.

-- Kurt