From jhildebr@cisco.com Tue May 22 08:49:33 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F2E21F8628 for ; Tue, 22 May 2012 08:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlkVt0jbxtBv for ; Tue, 22 May 2012 08:49:33 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id F2A0821F85F6 for ; Tue, 22 May 2012 08:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=683; q=dns/txt; s=iport; t=1337701773; x=1338911373; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=cgQOwroEi/D7usVm8TlsGb+X10/0y72HKijt3NGWmik=; b=OUDCuS3DupP5R187BhOrqbOW9/VTTKSLflVuduFVAYRbd4BckUruLy+9 DTE/EbS7ni8gzoOAMCMneYC0VNTjmVmOKV0kcZzHhdVFTF5csIHObIul8 Sc85qcasNz0hlb8SAsCxMW651cKIsrdEaxMDbymnI1viNZQwBK9xKvtne o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMHAOaYu0+tJXHA/2dsb2JhbABEtBACgQeCFQEBAQMBEgEnAgFOAQiBHQEBBAESGweHZwWZeKAPkEQDiEKMWY4MgWSDCA X-IronPort-AV: E=Sophos;i="4.75,637,1330905600"; d="scan'208";a="85530547" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 22 May 2012 15:49:32 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q4MFnWOo004119; Tue, 22 May 2012 15:49:32 GMT Received: from xmb-rcd-313.cisco.com ([72.163.63.28]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 May 2012 10:49:31 -0500 Received: from 64.101.74.200 ([64.101.74.200]) by XMB-RCD-313.cisco.com ([72.163.63.28]) with Microsoft Exchange Server HTTP-DAV ; Tue, 22 May 2012 15:49:32 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 22 May 2012 09:49:30 -0600 From: Joe Hildebrand To: XMPP Standards , Message-ID: Thread-Topic: [Standards] XEP-0170: compression after dialback Thread-Index: Ac04MnloWHTiGrA1+0yWNqPDkmjKBQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 May 2012 15:49:32.0031 (UTC) FILETIME=[7A9E08F0:01CD3832] Subject: Re: [xmpp] [Standards] XEP-0170: compression after dialback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:49:33 -0000 On 5/22/12 9:23 AM, "Philipp Hancke" wrote: >> Designing something to replace dialback seems like "fun". Getting >> everyone to implement and deploy it seems even more fun. > > The xmppwg chairs will surely agree when you propose that! Well, that's something for xmpp@ietf.org. As-chair: if we come up with a solution that fixes this compression problem, makes dialback better, allows for better security going forward (including the delegated trust problem), and still does multiplexing, we'd be more open than you expect. I feel like we're already chartered for that work, and haven't made much progress on it. -- Joe Hildebrand From stpeter@stpeter.im Tue May 22 10:04:26 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B4F21F864D for ; Tue, 22 May 2012 10:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7wLc1Fcdv6z for ; Tue, 22 May 2012 10:04:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 91E4F21F8648 for ; Tue, 22 May 2012 10:04:25 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 06E524005A; Tue, 22 May 2012 11:20:27 -0600 (MDT) Message-ID: <4FBBC718.5030507@stpeter.im> Date: Tue, 22 May 2012 11:04:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: XMPP Standards References: <4FBBA5B8.2070100@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Philipp Hancke , XMPP Working Group Subject: Re: [xmpp] [Standards] XEP-0170: compression after dialback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 17:04:26 -0000 On 5/22/12 9:23 AM, Philipp Hancke wrote: > On Tue, 22 May 2012, Peter Saint-Andre wrote: > >> On 5/21/12 7:22 AM, Matthew Wild wrote: >>> On 21 May 2012 09:08, Philipp Hancke wrote: >>>> The argument of keeping the negotiation of stream features in one place >>>> mentioned in my mail about 0198 applies to this, too. >>>> (the root cause of both problems is the inability of dialback to >>>> renegotiate >>>> stream features after authenti... err... whatever, but i don't >>>> see any way how we could change that. >>>> >>> >>> Yes, Prosody had this issue come up with both compression and 198 >>> recently. >> >> What are the costs and benefits of doing compression before dialback? > > cost: you're more vulnerable to "certain denial of service attacks" -- > I'd note that you might already be vulnerable by offering/using TLS > compression to a peer that you can't authenticate. Good point. > benefits: stream compression is negotiated in one place (). > Additionally, compression doesn't break multiplexing. > >>> I have to say it's pushing me over to the >>> we-need-to-deprecate-dialback camp... solving it in our code for each >>> individual case is possible, but hacky at best. >> >> Designing something to replace dialback seems like "fun". Getting >> everyone to implement and deploy it seems even more fun. > > The xmppwg chairs will surely agree when you propose that! > >>> Even if we keep the same authenti...thingy around, at least we should >>> have something more integrated into our normal feature negotiation. >>> like SASL is. >> >> We had discussions long ago about defining a SASL mechanism for >> dialback. That would slot in rather nicely, no? > > The stream-restart model doesn't work with multiplexing. I don't think we'd need to restart the stream after each new domain is added. But let's add "multiplexing doesn't force a stream restart" to the requirements and figure out a way to make that happen. Peter -- Peter Saint-Andre https://stpeter.im/ From fippo@mail.symlynx.com Tue May 22 13:42:38 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812B321F8681 for ; Tue, 22 May 2012 13:42:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nze2H-+xav5j for ; Tue, 22 May 2012 13:42:37 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id C37EE21F8680 for ; Tue, 22 May 2012 13:42:35 -0700 (PDT) Received: from [192.168.2.100] (p5B2175B1.dip.t-dialin.net [91.33.117.177]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4MKgWWo017753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 May 2012 22:42:34 +0200 Message-ID: <4FBBFA34.5050506@mail.symlynx.com> Date: Tue, 22 May 2012 22:42:28 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: XMPP Extension Discussion List References: <4FBBA5B8.2070100@stpeter.im> <4FBBC718.5030507@stpeter.im> In-Reply-To: <4FBBC718.5030507@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] [Standards] XEP-0170: compression after dialback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 20:42:38 -0000 mostly xsf-land but since this touches multiplexing... Am 22.05.2012 19:04, schrieb Peter Saint-Andre: > On 5/22/12 9:23 AM, Philipp Hancke wrote: >> On Tue, 22 May 2012, Peter Saint-Andre wrote: >> >>> On 5/21/12 7:22 AM, Matthew Wild wrote: >>>> On 21 May 2012 09:08, Philipp Hancke wrote: >>>>> The argument of keeping the negotiation of stream features in one place >>>>> mentioned in my mail about 0198 applies to this, too. >>>>> (the root cause of both problems is the inability of dialback to >>>>> renegotiate >>>>> stream features after authenti... err... whatever, but i don't >>>>> see any way how we could change that. >>>>> >>>> >>>> Yes, Prosody had this issue come up with both compression and 198 >>>> recently. >>> >>> What are the costs and benefits of doing compression before dialback? >> >> cost: you're more vulnerable to "certain denial of service attacks" -- >> I'd note that you might already be vulnerable by offering/using TLS >> compression to a peer that you can't authenticate. > > Good point. Pandoras box actually... XEP 0138 might need restrictions similar to those described in the security considerations of RFC 3749. I'd like to avoid that if possible by retaining the assumption that the peer is authenticated. [snip] > I don't think we'd need to restart the stream after each new domain is > added. But let's add "multiplexing doesn't force a stream restart" to > the requirements and figure out a way to make that happen. There is a solution for the compression issue (and sm likewise, bidi is already doing that) which seems quite easy and pragmatic: Compression is only offered together with TLS and if the peer certificate is trusted (for some definition thereof) -- the same conditions when SASL EXTERNAL is offered. That way initiating server can choose between sasl or dialback (which the receiving server might/should implement as a d-w-d variant). pro: works with multiplexing and retains the current security properties of xep-0138. Additionally, that still enables the receiving server to use the (authenticated) peer name to selectively offer/deny certain features based on black/whitelists. cons: you don't get compression if you neither implement tls compression nor pay for a trusted certificate. Requires some minor changes to xeps 0138/0170/0198 afaics. I'll see if I can do some testing whether any of those changes would cause backward compability issues. From stpeter@stpeter.im Tue May 22 14:06:28 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23A21F861B for ; Tue, 22 May 2012 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcGzwALK7EOm for ; Tue, 22 May 2012 14:06:27 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3662521F8603 for ; Tue, 22 May 2012 14:06:27 -0700 (PDT) Received: from [64.101.72.115] (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6633940067; Tue, 22 May 2012 15:22:29 -0600 (MDT) Message-ID: <4FBBFFD0.7030301@stpeter.im> Date: Tue, 22 May 2012 15:06:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: XMPP Standards References: <4FBBA5B8.2070100@stpeter.im> <4FBBC718.5030507@stpeter.im> <4FBBFA34.5050506@mail.symlynx.com> In-Reply-To: <4FBBFA34.5050506@mail.symlynx.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] [Standards] XEP-0170: compression after dialback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 21:06:28 -0000 On 5/22/12 2:42 PM, Philipp Hancke wrote: > mostly xsf-land but since this touches multiplexing... > Am 22.05.2012 19:04, schrieb Peter Saint-Andre: >> On 5/22/12 9:23 AM, Philipp Hancke wrote: >>> On Tue, 22 May 2012, Peter Saint-Andre wrote: >>> >>>> On 5/21/12 7:22 AM, Matthew Wild wrote: >>>>> On 21 May 2012 09:08, Philipp Hancke >>>>> wrote: >>>>>> The argument of keeping the negotiation of stream features in one >>>>>> place >>>>>> mentioned in my mail about 0198 applies to this, too. >>>>>> (the root cause of both problems is the inability of dialback to >>>>>> renegotiate >>>>>> stream features after authenti... err... whatever, but i don't >>>>>> see any way how we could change that. >>>>>> >>>>> >>>>> Yes, Prosody had this issue come up with both compression and 198 >>>>> recently. >>>> >>>> What are the costs and benefits of doing compression before dialback? >>> >>> cost: you're more vulnerable to "certain denial of service attacks" -- >>> I'd note that you might already be vulnerable by offering/using TLS >>> compression to a peer that you can't authenticate. >> >> Good point. > > Pandoras box actually... XEP 0138 might need restrictions similar to > those described in the security considerations of RFC 3749. I'd like to > avoid that if possible by retaining the assumption that the peer is > authenticated. It seems to me that the security considerations in RFC 3749 (or at least some of them) apply even if the peer is authenticated. > [snip] >> I don't think we'd need to restart the stream after each new domain is >> added. But let's add "multiplexing doesn't force a stream restart" to >> the requirements and figure out a way to make that happen. > > In the dialback world, yes. In the world of dialback-bis via SASL (or whatever), we'd make that explicit. Or just use dialback syntax for the sake of backward compatibility. > There is a solution for the compression issue (and sm likewise, bidi is > already doing that) which seems quite easy and pragmatic: > > Compression is only offered together with TLS and if the peer > certificate is trusted (for some definition thereof) -- the same > conditions when SASL EXTERNAL is offered. When you say "compression is only offered together with TLS", do you mean that only TLS compression is offered, or that stream compression (XEP-0138) is offered only if TLS is in use? > That way initiating server can choose between sasl or dialback (which > the receiving server might/should implement as a d-w-d variant). If I understand you, that means (for s2s streams) you can do either (1) TLS + SASL EXTERNAL + TLS-compression or (2) dialback + stream compression. > pro: works with multiplexing and retains the current security properties > of xep-0138. Additionally, that still enables the receiving server to > use the (authenticated) peer name to selectively offer/deny certain > features based on black/whitelists. > > cons: you don't get compression if you neither implement tls compression > nor pay for a trusted certificate. I'll have to think about this for a while. > Requires some minor changes to xeps 0138/0170/0198 afaics. I'll see if I > can do some testing whether any of those changes would cause backward > compability issues. Testing is good. Let us know what you discover. :) Peter -- Peter Saint-Andre https://stpeter.im/ From fippo@mail.symlynx.com Tue May 22 14:30:24 2012 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F6521F869F for ; Tue, 22 May 2012 14:30:24 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogv4+iSGMEJv for ; Tue, 22 May 2012 14:30:23 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id C7EE721F864D for ; Tue, 22 May 2012 14:30:21 -0700 (PDT) Received: from [192.168.2.100] (p5B2175B1.dip.t-dialin.net [91.33.117.177]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q4MLUJOF018642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 May 2012 23:30:21 +0200 Message-ID: <4FBC0567.1050805@mail.symlynx.com> Date: Tue, 22 May 2012 23:30:15 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] [Standards] XEP-0170: compression after dialback X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 21:30:24 -0000 Hi Joe, >>> Designing something to replace dialback seems like "fun". Getting >>> everyone to implement and deploy it seems even more fun. >> >> The xmppwg chairs will surely agree when you propose that! > > Well, that's something for xmpp@ietf.org. > > As-chair: if we come up with a solution that fixes this compression problem, > makes dialback better, allows for better security going forward (including > the delegated trust problem), and still does multiplexing, we'd be more open > than you expect. Anything I could come up with ends up reinventing dialback (the I feel like we're already chartered for that work, and > haven't made much progress on it. I think that this is mostly a problem of sitting down and writing the specification (and I still have some pending changes to xep-220 that I really need to write down and submit). The building blocks such as dialback and d-w-d have already been specified (the latter only as a blog post) and implemented. I'm quite interested in DANE and have most of the code ready to implement it.