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

Kurt Zeilenga <Kurt.Zeilenga@Isode.COM> Tue, 02 November 2010 14:13 UTC

Return-Path: <Kurt.Zeilenga@Isode.COM>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57A9D3A687F; Tue, 2 Nov 2010 07:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -100.799
X-Spam-Status: No, score=-100.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AGjrTAMje9Gq; Tue, 2 Nov 2010 07:13:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1BF843A69C5; Tue, 2 Nov 2010 07:13:15 -0700 (PDT)
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 2 Nov 2010 14:13:18 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <>
Date: Tue, 02 Nov 2010 07:13:14 -0700
Message-Id: <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
References: <> <> <> <> <2761.1288645043.347835@puncture> <> <> <> <>
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: Tue, 02 Nov 2010 14:13:16 -0000

On Nov 2, 2010, at 5:12 AM, Peter Saint-Andre wrote:

> On 11/2/10 5:20 AM, Yaron Sheffer wrote:
>> I'm OK with this text, including (sigh) PLAIN.
> If it's any consolation, I'm sighing along with you. :)
> Two points:
> 1. Eventually, we should be able to drop PLAIN in a future revision of
> the MTI technologies spec that we'll pull out of 3920bis in 1+ years.

Good luck with that.  The arguments used now for its inclusion is likely to be repeated and, again, win.

Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it does offer good interoperability, it does good enough security for today's, and more importantly, tomorrow's Internet.

I think we actually should be mandating a SCRAM-*-PLUS mechanism, because channeling bindings are really needed due to 'user click through' of TLS warnings, downgrade attack warnings, etc..   I do suspect that it will take time for this mechanism to be come ubiquitous, but I fear that without a MUST, it will never become ubiquitous.   But I do suspect well have multiple independently developed implementations of SCRAM-*-PLUS in XMPP within a few months of publication of this revision of XMPP.

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 ?).

> Peter
> -- 
> Peter Saint-Andre
> _______________________________________________
> xmpp mailing list