Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
Peter Saint-Andre <stpeter@stpeter.im> Wed, 03 November 2010 12:13 UTC
Return-Path: <stpeter@stpeter.im>
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 E3FA43A6A9D; Wed, 3 Nov 2010 05:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdltAmnKmbBY; Wed, 3 Nov 2010 05:13:40 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 585293A6825; Wed, 3 Nov 2010 05:13:40 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E3C940D1E; Wed, 3 Nov 2010 06:22:26 -0600 (MDT)
Message-ID: <4CD151F7.6060809@stpeter.im>
Date: Wed, 03 Nov 2010 06:13:43 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
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>
In-Reply-To: <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
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: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@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 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 authentication Ideally, both of those changes would be accompanied by additional security-related text, and in case (b) an interoperability note. Peter -- Peter Saint-Andre https://stpeter.im/
- [secdir] SecDir review of draft-ietf-xmpp-3920bis… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Florian Zeitz
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Jeffrey Hutzelman
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Matthew Wild
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Philipp Hancke
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre