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

Matthew Wild <mwild1@gmail.com> Wed, 03 November 2010 18:10 UTC

Return-Path: <mwild1@gmail.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 BD52228C121; Wed, 3 Nov 2010 11:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 bHWwqktewGeK; Wed, 3 Nov 2010 11:10:40 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D72CE28C117; Wed, 3 Nov 2010 11:10:38 -0700 (PDT)
Received: by gxk7 with SMTP id 7so728579gxk.31 for <multiple recipients>; Wed, 03 Nov 2010 11:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sY2Nejy210Koa51egLao/sHWXiDCvKPCSuktyLwQCLs=; b=fPtidEEIkcj8Uhs6b+OEnfYsPaNL0t7nSpzd5yf1+LyDUQU6Pk5AXZ+3yGXRpDEnLD yTy8foONDFaFwdHgDpqh0pSQC+iDxJIMMPrHcTs7SUI3rux2AAOT+xcTy+01E4OYrrbt bG9mnMQT7WB4w6qTcGeDiWAFnM22TnZNwgb40=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=apvA/Fx1u+1ncvP3uM9p0t3IcwhDx3chyk3btv4fi/oBY7QcZrw2+CfgWoux9FmcwJ KLYm4fHzlew/p2vJDHU9huJo7D5J0hNKNc+HVDFBTXxyDGKz0tF/HHEfgxvkMD5P/XFR ZlK63xeAfS0vo8oGQybD0B3yrmS8QmupG02uE=
Received: by 10.42.21.17 with SMTP id i17mr13861637icb.263.1288807845597; Wed, 03 Nov 2010 11:10:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.166.84 with HTTP; Wed, 3 Nov 2010 11:10:25 -0700 (PDT)
In-Reply-To: <4CD19C81.9050509@stpeter.im>
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> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM> <4CD151F7.6060809@stpeter.im> <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM> <4CD19C81.9050509@stpeter.im>
From: Matthew Wild <mwild1@gmail.com>
Date: Wed, 03 Nov 2010 18:10:25 +0000
Message-ID: <AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Kurt Zeilenga <Kurt.Zeilenga@isode.com>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@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 18:10:43 -0000

On 3 November 2010 17:31, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>

>      as described under Section 13.7.2.1 (however, the lack of channel
>      binding in the PLAIN mechanism implies that even authenticated TLS
>      cannot fully protect the SASL negotiation and subsequent
>      communications when PLAIN is used).
>

I'm no expert on this, but is this text technically true? I thought
channel binding would only be beneficial where there is not full TLS
authentication.

I'm not going to weigh in on the to-MTI/to-not-MTI issue... it's not
going to affect anything either way. There are deployment scenarios
where PLAIN is necessary, and as far as I'm aware it is quite safe
with full TLS verification/authentication. I think Kurt is mainly
arguing that in practice TLS is rarely fully verified. However this is
a deployment issue, and has no bearing on the protocol - though were
we to MTI for interop reasons we should of course strongly stress the
importance of TLS being fully verified when using PLAIN.

Regards,
Matthew