From ben@nostrum.com Tue Feb 4 11:24:03 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D717C1A01EF for ; Tue, 4 Feb 2014 11:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwBUT843sdJv for ; Tue, 4 Feb 2014 11:24:01 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE991A01EE for ; Tue, 4 Feb 2014 11:24:01 -0800 (PST) Received: from [172.20.10.7] (mobile-166-147-068-230.mycingular.net [166.147.68.230]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s14JNuUv042230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Feb 2014 13:23:58 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: <3E197582-9715-4FE9-AA4A-322FDC18F301@nostrum.com> Date: Tue, 4 Feb 2014 13:23:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0ADA8BBE-900E-4239-B3B6-6F83B0D2D9E3@nostrum.com> References: <3E197582-9715-4FE9-AA4A-322FDC18F301@nostrum.com> To: XMPP Group X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 166.147.68.230 is authenticated by a trusted mechanism) Subject: Re: [xmpp] Consensus Call on Adoption of POSH X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 19:24:03 -0000 (As chair) We've had a number of statements of support for adoption, and no = significant objections. Therefore please consider draft-miller-posh-03 = to be adopted as a work group item. Please keep in mind that adoption = does not mean the draft is complete or correct--everything in it is = still fair game for debate. Matt, please resubmit as draft-ietf-xmpp-* at your convenience. Thanks! Ben. On Jan 6, 2014, at 4:07 PM, Ben Campbell wrote: >=20 > (as chair) >=20 > Hi, >=20 > The XMPP working group has a chartered work item for enabling = multi-domain hosting and server connection sharing. >=20 > Matt has been working on POSH for a while now, as an enabler for that = work. POSH is not currently expected to get its own working group, and = no other working group is chartered for that work. Several people have = proposed that, while POSH may have general applicability, XMPP is the = group that needs it, and therefore XMPP should adopt it. It is further = proposed that, we would try to keep it reasonably general, but would = focus on XMPP related requirements. >=20 > Should we adopt https://datatracker.ietf.org/doc/draft-miller-posh/ as = a working group item in support of the aforementioned chartered work? = Keep in mind that acceptance does not mean the work group thinks the = draft is absolutely correct or complete. It merely means that we think = that the draft is a good start towards the milestone. >=20 > Please send your opinions to the XMPP working group by Jan 20. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From internet-drafts@ietf.org Tue Feb 4 12:18:27 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87431A0187; Tue, 4 Feb 2014 12:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tje5bI4lkUJy; Tue, 4 Feb 2014 12:18:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBADE1A016D; Tue, 4 Feb 2014 12:18:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204201824.8629.71632.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 12:18:24 -0800 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-posh-00.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 20:18:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : PKIX over Secure HTTP (POSH) Authors : Matthew Miller Peter Saint-Andre Filename : draft-ietf-xmpp-posh-00.txt Pages : 16 Date : 2014-02-04 Abstract: Experience has shown that it is extremely difficult to deploy proper PKIX certificates for TLS in multi-tenanted environments, since certification authorities will not issue certificates for hosted domains to hosting services, hosted domains do not want hosting services to hold their private keys, and hosting services wish to avoid liability for holding those keys. As a result, domains hosted in multi-tenanted environments often deploy non-HTTP applications such as email and instant messaging using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in obvious security implications. This document defines two methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. The first method enables the TLS client associated with a user agent or peer application server to obtain the end-entity certificate of a hosted domain over secure HTTP as an alternative to standard PKIX techniques. The second method enables a hosted domain to securely delegate a non-HTTP application to a hosting service using redirects provided by HTTPS itself or by a pointer in a file served over HTTPS at the hosted domain. While this approach is developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association prooftype, it can be applied to any non-HTTP application protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-posh-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue Feb 4 12:23:09 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D241A01E2; Tue, 4 Feb 2014 12:23:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgu-rVKKdAlk; Tue, 4 Feb 2014 12:23:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AD41A016D; Tue, 4 Feb 2014 12:23:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> Date: Tue, 04 Feb 2014 12:23:06 -0800 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 20:23:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP) Authors : Peter Saint-Andre Matthew Miller Filename : draft-ietf-xmpp-dna-05.txt Pages : 16 Date : 2014-02-04 Abstract: This document improves the security of the Extensible Messaging and Presence Protocol (XMPP) in two ways. First, it specifies how "prooftypes" can establish a strong association between a domain name and an XML stream. Second, it describes how to securely delegate a source domain to a derived domain, which is especially important in virtual hosting environments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-dna-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mamille2@cisco.com Tue Feb 4 12:25:13 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A3D1A01CB for ; Tue, 4 Feb 2014 12:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.015 X-Spam-Level: X-Spam-Status: No, score=-9.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bexeLTKu3BD5 for ; Tue, 4 Feb 2014 12:25:11 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id B080B1A016D for ; Tue, 4 Feb 2014 12:25:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3637; q=dns/txt; s=iport; t=1391545511; x=1392755111; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=IfNr5kJm7zOfXiATqOljAoCvvR9sxCitSVSR0ZpdYtg=; b=GBFTfhMQ8xewflZBXPuxlHqwr8PykBzr+6dLXX3B+y4JYOZls9a4DZRt TFdfeUwQLZkHw9NqKDIK228teEvIuWNEsy7PetBEeSFCKDZ1ua2UPYgGK GYu8M/rzR94tqRm50jbv6HQGSdDbQITUxvlXfCj0vT4maHCvT+hDLtsAN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgJAGZL8VKtJV2b/2dsb2JhbABPAQmDDDhXqB+VeyRrFnSCHQgBAQEEAQEBawoBEAsYCRYPCQMCAQIBFTATAQMCAgEBBYVtgg8NzgcXjhMGAQoBHTMHgn6BOgSJETiOYoEyiy+FQINNIIExOQ X-IronPort-AV: E=Sophos;i="4.95,781,1384300800"; d="scan'208";a="17926170" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 04 Feb 2014 20:25:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s14KPA4a008398 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Feb 2014 20:25:10 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Feb 2014 14:25:10 -0600 Message-ID: <52F14CA6.3070009@cisco.com> Date: Tue, 4 Feb 2014 13:25:10 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 CC: XMPP Group References: <20140204201824.8629.71632.idtracker@ietfa.amsl.com> In-Reply-To: <20140204201824.8629.71632.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.76] Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-posh-00.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 20:25:13 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 This is draft-miller-posh-03 with the authors and references updated. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 2/4/14, 1:18 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Extensible Messaging > and Presence Protocol Working Group of the IETF. > > Title : PKIX over Secure HTTP (POSH) Authors : > Matthew Miller Peter Saint-Andre Filename : > draft-ietf-xmpp-posh-00.txt Pages : 16 Date : > 2014-02-04 > > Abstract: Experience has shown that it is extremely difficult to > deploy proper PKIX certificates for TLS in multi-tenanted > environments, since certification authorities will not issue > certificates for hosted domains to hosting services, hosted domains > do not want hosting services to hold their private keys, and > hosting services wish to avoid liability for holding those keys. > As a result, domains hosted in multi-tenanted environments often > deploy non-HTTP applications such as email and instant messaging > using certificates that identify the hosting service, not the > hosted domain. Such deployments force end users and peer services > to accept a certificate with an improper identifier, resulting in > obvious security implications. This document defines two methods > that make it easier to deploy certificates for proper server > identity checking in non-HTTP application protocols. The first > method enables the TLS client associated with a user agent or peer > application server to obtain the end-entity certificate of a hosted > domain over secure HTTP as an alternative to standard PKIX > techniques. The second method enables a hosted domain to securely > delegate a non-HTTP application to a hosting service using > redirects provided by HTTPS itself or by a pointer in a file served > over HTTPS at the hosted domain. While this approach is developed > for use in the Extensible Messaging and Presence Protocol (XMPP) as > a Domain Name Association prooftype, it can be applied to any > non-HTTP application protocol. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-posh/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-posh-00 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ I-D-Announce > mailing list I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft > directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS8UylAAoJEDWi+S0W7cO15J0IAJpopoRkkOAwVgz3aMM0StUX 0Kw7UXEnqr4xswX1QfM4bQsqoqhJdHxDyJ4tnA0mnjkyTm/h3sjiy2p0DQWDmEHc lmeCFzHHOCENdRZAn2dO0kzdoLtEWbY6k9pAhVUJpaYgu1EFLJEbHw+PDW1dqVJk UDRzWFwNEfWDqQ88aPEz40ev1h07n4Eos/kxohLSPgpjlWN4GfnxX/mpRpoACwwO QInFXs1Cy7xJAFnWT56DzNDwLpXtY0E4uZony4MaXH3h09tEZ0sz/ETRSBydZAy8 IsJlHGhwzuc5IeRoBaiGCiWaE6bNpw7SG3YoPThnBzQC+ybAp5kMvGG5NPKnzOw= =p1d1 -----END PGP SIGNATURE----- From mamille2@cisco.com Tue Feb 4 12:26:20 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760BE1A0187 for ; Tue, 4 Feb 2014 12:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.015 X-Spam-Level: X-Spam-Status: No, score=-9.015 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCKFhKki1QKp for ; Tue, 4 Feb 2014 12:26:19 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 148481A016D for ; Tue, 4 Feb 2014 12:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2450; q=dns/txt; s=iport; t=1391545579; x=1392755179; h=message-id:date:from:mime-version:cc:subject:references: in-reply-to:content-transfer-encoding; bh=Z1XvOSaYYeTmfStUFUoKDwnwnwiog+2/upgRllm5MhA=; b=irVJdDGux0utBOgadmCUJRbdb7T2Dj8x0O2JBy26n7YE1MDqfj1FqOK+ 0dxGplaccUgltwjA4DefXdExuugn6FH1FrmuV3ALbZKk8Q/wUSQuYW7la Mpm9cKzPflFhVS2mnAGW9ezLZv0uphoTJm+TKWEjzlYk4yCOpfo/awArs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMJAKtL8VKtJV2a/2dsb2JhbABZgww4UQa+GiRrFnSCHQgBAQEEAQEBawoBEAsYCRYPCQMCAQIBFTATAQUCAQEFhW2CDwgFzgcXjkIzB4J+gToEiRE4jmKBMpBvg02CCg X-IronPort-AV: E=Sophos;i="4.95,781,1384300800"; d="scan'208";a="17931743" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-7.cisco.com with ESMTP; 04 Feb 2014 20:26:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s14KQIIp031023 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Feb 2014 20:26:18 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Feb 2014 14:26:18 -0600 Message-ID: <52F14CE9.9060108@cisco.com> Date: Tue, 4 Feb 2014 13:26:17 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 CC: References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> In-Reply-To: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.76] Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 20:26:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Updated references and authors. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On 2/4/14, 1:23 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Extensible Messaging > and Presence Protocol Working Group of the IETF. > > Title : Domain Name Associations (DNA) in the Extensible > Messaging and Presence Protocol (XMPP) Authors : Peter > Saint-Andre Matthew Miller Filename : > draft-ietf-xmpp-dna-05.txt Pages : 16 Date : > 2014-02-04 > > Abstract: This document improves the security of the Extensible > Messaging and Presence Protocol (XMPP) in two ways. First, it > specifies how "prooftypes" can establish a strong association > between a domain name and an XML stream. Second, it describes how > to securely delegate a source domain to a derived domain, which is > especially important in virtual hosting environments. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-dna-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-05 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ xmpp mailing list > xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS8UzpAAoJEDWi+S0W7cO1IEoH/3bQrv/qfliMvqx52nphnQsT gjE1UCKkFfUwrQK2IS9T4L++RkfAvyTqBdhFly1UaFsNA8y0e9SWkGXfqnxLRSC2 rdU8R3sND9TK7OiFnv0/It3JNx0bsUhikBX8kG4slvKma5AUrMS1um7CD40Nq1ek 50Jt88Qe6TQKXMg35k6ahGPlrRw9fvMFBQMBYo5fetp9Ju36AHOHFe4OGisUg7Fg +qBjF6nY3yzDevhvbe/lP6h91YAnm8itrg7mwGsSpXZuKAlqVFz6HNboOjCDLAlV Glb3r14GIWoH8wxK94JinIN1n/7FltCWUMv/0DA/bKmgEgrKIZq4NHIch8axKqs= =QEOX -----END PGP SIGNATURE----- From k.i.smith@gmail.com Thu Feb 6 03:26:33 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CC41A03A5 for ; Thu, 6 Feb 2014 03:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOi2Ua6CXbaf for ; Thu, 6 Feb 2014 03:26:32 -0800 (PST) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id CC4541A00E3 for ; Thu, 6 Feb 2014 03:26:31 -0800 (PST) Received: by mail-vb0-f50.google.com with SMTP id w8so1300807vbj.37 for ; Thu, 06 Feb 2014 03:26:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:date:message-id:subject:from:to :content-type; bh=UkGs6I1QssOIUh7VuHZjoBsUbmquAVeyZlvIdsLAizQ=; b=S1N+DrUD8VnOgqN5me1sMFjxF6KNquVbZa6Mm/eLhN98qVuTQ9OZriBHEvRoeyb3PR pCR2hY6SW9EmCaHzvMJ4L6CxnWcJI9mWJ2sum88JokwNv1H+6raiO/nAYyjIRn1W1MCg hHf42UFUb3MHcUYkMKflPpBI6OrB/8jKcdy/vrrbkvu7iBqLvYbhGuDOa4FvDbXbdIwj mpuIqqUDzXB4/eJYTSjWmleaJy8drdU1aWbu1ocVLWgp5VQJ1cZL6EjvIUu8oJOzVXAF 51dPubFp8mbX4KnMSeZlyc6zce8R29T+3i5gzIia2+dL3tWU901obSOSpiMvkG9sgIFJ Nsdw== MIME-Version: 1.0 X-Received: by 10.52.61.168 with SMTP id q8mr50189vdr.40.1391685990586; Thu, 06 Feb 2014 03:26:30 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.52.245.134 with HTTP; Thu, 6 Feb 2014 03:26:30 -0800 (PST) Date: Thu, 6 Feb 2014 11:26:30 +0000 X-Google-Sender-Auth: Hp6XHdyUkrJUNCi_uZBpmQE4Qpg Message-ID: From: Kevin Smith To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1 Subject: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 11:26:33 -0000 Hi folks, Discussion in the XSF and at the recent XMPP Summit has shown that there are widespread issues with handling of iq responses in XMPP software. This is probably something we need to consider handling. The basis of this is that many libraries/clients a) Only check the id of an iq error/result, not the sender, to check it matches one they've sent (Very Wrong) b) Use predictably generated ids for stanzas (ill-advised, but not strictly wrong) c) Use known resource strings (bad, but not strictly wrong) In conjunction, this leads to various obvious attacks with differing levels of severity, but for the sake of enumerating some, with some good fortune with timing against a vulnerable client you can: Fake contacts', or even their own, vcards; fake their roster so they think people have 'unfriended' them, or that they have already added someone unknown; deny capabilities discovery; make them think their server doesn't have a MUC service; and the list goes on and on. We certainly need to call this out explicitly in 3920ter, We might want to publish something in the interim. /K From jhildebr@cisco.com Thu Feb 6 13:58:50 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CA11A044D for ; Thu, 6 Feb 2014 13:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kNkGwUzsF5p for ; Thu, 6 Feb 2014 13:58:48 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC361A044C for ; Thu, 6 Feb 2014 13:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1797; q=dns/txt; s=iport; t=1391723927; x=1392933527; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pH1JY0HDIIJmL4rK/1Qa79MMZtyRWLhSonUoGuDSnvM=; b=O4k9U//+rxN7eOC2dRmw9N7snb5XKitp1QmzITXPu5VVpqgZyAlJRp/k 4/R8ViDcckNAhuJupQ7g4MpcikrWLet7tHf9nHYsHzSskiJomKlcoC0YT f4rcmKYREgoAz5G6q/7MP9ngziZsKbC9ft4fgJosNOUjvc0gS0LkZOL9x Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFADYE9FKtJV2Z/2dsb2JhbABZgww4V753gQ8WdIImAQEEAQEBNzQbAgEINhAnCyUCBAESG4dqDc0HEwSPAYQ4BJgrkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,796,1384300800"; d="scan'208";a="18583106" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 06 Feb 2014 21:58:47 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16Lwlvp017967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 21:58:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 15:58:46 -0600 From: "Joe Hildebrand (jhildebr)" To: "kevin@kismith.co.uk" , XMPP Working Group Thread-Topic: [xmpp] IQ Handling vulnerabilities Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEA Date: Thu, 6 Feb 2014 21:58:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.232.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <5BD492AD7A714F4BB034AB21BB2ACC6C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 21:58:50 -0000 (as individual) I think this is a very important issue. I'm worried about the security impact, and I think we need to give good guidance. (as co-chair) Who else thinks we need to work on this? Can we start with an individual I-D that lays out the problem and solution? That would allow us to make good decisions about what the next step would be. Kev, that might be pretty quick for you to write... On 2/6/14 3:26 AM, "Kevin Smith" wrote: >Hi folks, > Discussion in the XSF and at the recent XMPP Summit has shown that >there are widespread issues with handling of iq responses in XMPP >software. This is probably something we need to consider handling. > >The basis of this is that many libraries/clients >a) Only check the id of an iq error/result, not the sender, to check >it matches one they've sent (Very Wrong) >b) Use predictably generated ids for stanzas (ill-advised, but not >strictly wrong) >c) Use known resource strings (bad, but not strictly wrong) > >In conjunction, this leads to various obvious attacks with differing >levels of severity, but for the sake of enumerating some, with some >good fortune with timing against a vulnerable client you can: Fake >contacts', or even their own, vcards; fake their roster so they think >people have 'unfriended' them, or that they have already added someone >unknown; deny capabilities discovery; make them think their server >doesn't have a MUC service; and the list goes on and on. > >We certainly need to call this out explicitly in 3920ter, We might >want to publish something in the interim. > >/K >_______________________________________________ >xmpp mailing list >xmpp@ietf.org >https://www.ietf.org/mailman/listinfo/xmpp > --=20 Joe Hildebrand From fippo@goodadvice.pages.de Thu Feb 6 14:07:08 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3D81A03D4 for ; Thu, 6 Feb 2014 14:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtJwEA5wmlxG for ; Thu, 6 Feb 2014 14:07:05 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id A8DAF1A0427 for ; Thu, 6 Feb 2014 14:07:04 -0800 (PST) Received: from [192.168.2.101] (p54970268.dip0.t-ipconnect.de [84.151.2.104]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s16M71pu020811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 6 Feb 2014 23:07:03 +0100 Message-ID: <52F4077E.4010607@goodadvice.pages.de> Date: Thu, 06 Feb 2014 23:06:54 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: xmpp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 22:07:08 -0000 Am 06.02.2014 12:26, schrieb Kevin Smith: > Hi folks, > Discussion in the XSF and at the recent XMPP Summit has shown that > there are widespread issues with handling of iq responses in XMPP > software. This is probably something we need to consider handling. This is something the WG should do. > The basis of this is that many libraries/clients > a) Only check the id of an iq error/result, not the sender, to check > it matches one they've sent (Very Wrong) Well, http://xmpp.org/rfcs/rfc6120.html#stanzas-semantics-iq says the interaction is tracked by the requesting entity through use of the 'id' attribute. That's easy to to get wrong :-/ > b) Use predictably generated ids for stanzas (ill-advised, but not > strictly wrong) We need to fix the advice given in http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-id From mamille2@cisco.com Thu Feb 6 14:14:28 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970ED1A0504 for ; Thu, 6 Feb 2014 14:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9A-FNzfemiR for ; Thu, 6 Feb 2014 14:14:26 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 69E151A0467 for ; Thu, 6 Feb 2014 14:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1391724864; x=1392934464; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=zLOi/VCV3Tp5MIFlBv2cN8cQh+BjwpFqTqlmts7hV0M=; b=BvrkhUe4H8zCyl9ciG7okkSgg+YjjuCjMQsod7U5F4WLVF8ezp8ZnxfK wGV46Vvkyl0Zyvo4EAkpYKgcOYwvqdVLE/wAs7x+2H8qgjyo2XNugVBX3 X9jV1pKxcjBfM1APiHEWtSy/RAGb9ESP7LnxnNrjPhl19FlMQBGEAy6SC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAL4I9FKtJXG9/2dsb2JhbABZgww4V75uCYEPFnSCJQEBAQQBAQFrChELGAkWDwkDAgECARUWGgYBDAYCAQEXh2oNzREXjkc6hDgEiRE4jmKSIYNNggo X-IronPort-AV: E=Sophos;i="4.95,796,1384300800"; d="scan'208";a="18589473" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-2.cisco.com with ESMTP; 06 Feb 2014 22:14:24 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16MENUs028032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 22:14:23 GMT Received: from excelsior.local (10.89.10.147) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Feb 2014 16:14:23 -0600 Message-ID: <52F4093E.8000704@cisco.com> Date: Thu, 6 Feb 2014 15:14:22 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Joe Hildebrand (jhildebr)" , Kevin Smith , XMPP Working Group References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.89.10.147] Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 22:14:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/6/14, 2:58 PM, Joe Hildebrand (jhildebr) wrote: > (as individual) > > I think this is a very important issue. I'm worried about the > security impact, and I think we need to give good guidance. > > (as co-chair) > > Who else thinks we need to work on this? > > Can we start with an individual I-D that lays out the problem and > solution? That would allow us to make good decisions about what > the next step would be. Kev, that might be pretty quick for you to > write... > > > > On 2/6/14 3:26 AM, "Kevin Smith" wrote: > >> Hi folks, Discussion in the XSF and at the recent XMPP Summit has >> shown that there are widespread issues with handling of iq >> responses in XMPP software. This is probably something we need to >> consider handling. >> >> The basis of this is that many libraries/clients a) Only check >> the id of an iq error/result, not the sender, to check it matches >> one they've sent (Very Wrong) b) Use predictably generated ids >> for stanzas (ill-advised, but not strictly wrong) c) Use known >> resource strings (bad, but not strictly wrong) >> >> In conjunction, this leads to various obvious attacks with >> differing levels of severity, but for the sake of enumerating >> some, with some good fortune with timing against a vulnerable >> client you can: Fake contacts', or even their own, vcards; fake >> their roster so they think people have 'unfriended' them, or that >> they have already added someone unknown; deny capabilities >> discovery; make them think their server doesn't have a MUC >> service; and the list goes on and on. >> >> We certainly need to call this out explicitly in 3920ter, We >> might want to publish something in the interim. >> >> /K _______________________________________________ xmpp mailing >> list xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp >> > > I agree this is an important issue that needs to be addressed. I think someone submitting an I-D is a fine starting point. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJS9Ak+AAoJEDWi+S0W7cO17IgH/2XbPvHedoSvsOY0L/LEcvu6 cfeDRy7ErMMgp+Evb6UTSCETNm20WYTUEsYGVigUV02HsV5GhJFswtrr+vk5hG3n uF94GmTCRSTTbn0CIbCfgwq5bDJrtRbi0DkpzPP1ZD7t1QZaFjhi39t6XjGc3u9d hkKvG/XS2bB/C+71X9jYEeReEMZdUc/bXgwTCTzD84GVVMIK0QisfJBQw6o6blXI 03FzvSn8qwZiQ3YBhrPNndKflFv0uRU4mOO9N/SYXpJjtMmqu2i6wA1v5rvct3H9 EnoMz03GZ0xxZDo07aBqHjCivAji9AKZ+Dpgw+sBM6H2X8OIdONM0L823qIEuTI= =2sJN -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Feb 6 14:30:28 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4551A0467 for ; Thu, 6 Feb 2014 14:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chYrLxOVpzIw for ; Thu, 6 Feb 2014 14:30:26 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C87741A03C4 for ; Thu, 6 Feb 2014 14:30:26 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A79D94010C; Thu, 6 Feb 2014 15:30:24 -0700 (MST) Message-ID: <52F40CFE.5000303@stpeter.im> Date: Thu, 06 Feb 2014 15:30:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Philipp Hancke , xmpp@ietf.org References: <52F4077E.4010607@goodadvice.pages.de> In-Reply-To: <52F4077E.4010607@goodadvice.pages.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 22:30:28 -0000 On 2/6/14, 3:06 PM, Philipp Hancke wrote: > Am 06.02.2014 12:26, schrieb Kevin Smith: >> Hi folks, >> Discussion in the XSF and at the recent XMPP Summit has shown that >> there are widespread issues with handling of iq responses in XMPP >> software. This is probably something we need to consider handling. > > This is something the WG should do. Agreed. >> The basis of this is that many libraries/clients >> a) Only check the id of an iq error/result, not the sender, to check >> it matches one they've sent (Very Wrong) > > Well, http://xmpp.org/rfcs/rfc6120.html#stanzas-semantics-iq says > the interaction is tracked by the requesting entity through use > of the 'id' attribute. > That's easy to to get wrong :-/ I'd say that the text there is descriptive, not prescriptive. The new I-D (to update 6120 and then be incorporated into 6120bis) would define acceptable behavior from a security point of view. >> b) Use predictably generated ids for stanzas (ill-advised, but not >> strictly wrong) > > We need to fix the advice given in > http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-id Yes, that too - probably we'd want to say that 'id' values ought to be random (e.g., UUIDs). Who's volunteering to write this up? Maybe Thijs? Peter -- Peter Saint-Andre https://stpeter.im/ From ben@nostrum.com Thu Feb 6 15:22:25 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6E11A0511 for ; Thu, 6 Feb 2014 15:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX3wgO__g9gq for ; Thu, 6 Feb 2014 15:22:25 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E03E01A0426 for ; Thu, 6 Feb 2014 15:22:24 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s16NM9hE075480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Feb 2014 17:22:10 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: Date: Thu, 6 Feb 2014 17:22:09 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> References: To: Joe Hildebrand X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 23:22:26 -0000 On Feb 6, 2014, at 3:58 PM, Joe Hildebrand (jhildebr) = wrote: > (as co-chair) >=20 > Who else thinks we need to work on this? >=20 > Can we start with an individual I-D that lays out the problem and > solution? That would allow us to make good decisions about what the = next > step would be. Kev, that might be pretty quick for you to write... (As the other co-chair) I think an individual I-D is the right way to go here, even if it just = lays out the problem. (But solutions are also good!) Thanks! Ben.= From thijs@xnyhps.nl Fri Feb 7 02:47:09 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F111A020B for ; Fri, 7 Feb 2014 02:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.535] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw3qGZs5AvW0 for ; Fri, 7 Feb 2014 02:47:07 -0800 (PST) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 6968A1A0033 for ; Fri, 7 Feb 2014 02:47:07 -0800 (PST) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 6D78E20AE8; Fri, 7 Feb 2014 11:46:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1391770017; bh=xGShtPzAHB15O3jTybPxwGA9J2HhYF8gVPay1THR6iY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=j9+aPmQJUd3IGNYhC9tTTkq2cJSfoQQV3zCNl02r0NX0MwAEDI1As75i618xb4fiC PEsejTyB5ZK92TJHqEL1T+H41CkaWG7KfxDLz71MoKhZ8h5fR0yp/xgt6+fyXGaY+K 3/4xVQcP0qgSwmpq4j9n2byYyewvIXk168M9ffZ4= Content-Type: multipart/signed; boundary="Apple-Mail=_5745AD70-9C7B-4CCE-9539-679BED716C1B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thijs Alkemade In-Reply-To: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> Date: Fri, 7 Feb 2014 11:46:55 +0100 Message-Id: <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1827) Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 10:47:09 -0000 --Apple-Mail=_5745AD70-9C7B-4CCE-9539-679BED716C1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 6 feb. 2014, at 23:30, Peter Saint-Andre wrote: >>> b) Use predictably generated ids for stanzas (ill-advised, but not >>> strictly wrong) >>=20 >> We need to fix the advice given in >> http://xmpp.org/rfcs/rfc6120.html#stanzas-attributes-id >=20 > Yes, that too - probably we'd want to say that 'id' values ought to be = random (e.g., UUIDs). Well, actually... The property we really want from ids is that predicting the next one(s) = given some historic ones is hard. That is not a guarantee UUIDs give by = definition. The time based UUIDs (version 1) obviously don't have this property, but = also randomly generated UUIDs (version 4) may be generated with any PRNG, = even linear congruential ones. In fact, the Security Considerations of RFC = 4122 cover this: Do not assume that UUIDs are hard to guess; they should not be used as security capabilities (identifiers whose mere possession grants access), for example. A predictable random number source will exacerbate the situation. I'm afraid that suggesting to use UUIDs will cause people to still not = check the 'from' attribute, but to assume their UUIDs are impossible to = predict by others. I think it would be better advise to grab 8 or 16 bytes from a = CSPRNG and hex-encode/base64-encode/SHA1-hash that. > Who's volunteering to write this up? Maybe Thijs? Yes, I would be willing to do this. Thijs --Apple-Mail=_5745AD70-9C7B-4CCE-9539-679BED716C1B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS9LmfAAoJELRGwhIrI4PEsUcP/3mK7BH+O79tBmPgGd6MaGLN MIYP10OPWaQ3zG0HMiY4BcXEyo+Gg1bNVVe+rejRmwNJs+P730S6wCsYx6LfYFUS EAHanceM9nvlhXNkA4PcLj/uSDs9nNwNuayPSezdPAWL4cTD74X51Qa+8s/lglGo KFdoYMogDz4E63Vl5e2e8J0+4jUwkKjrdz44/X3DvcGc4yavZqeZPo6Y7BI23RGF /Fr2nbakmj3bVj3LSd9lHIvtaJ9FlzUpqNKtbDEVA4WcoCkf04/joO/uPWKhkjAn p/oytrY1P88QuJSkJfHbQrk54U6wCZJkkhB8W5nsJZFKNuBAKsycxZSDWdp2ZZ+1 kqVi3yefIBGonKjx0fEIOWB47pN4Mw6GBs45wth+pvzAAA4kywpB1LbeaTUSATYO 7C34DGPYf+4GNeURBx0bkQmpknxbvMumRuouJNGSJ5+9oT2WAyXUmuItZMFCnjU5 j2CVWXqmpj1GaBncGIMvOZP10U2dsyh8kUjPZCAh8v8d8TpEgEvPSRHTzU0afsNy h8cpxwFXU8q6hycJJNzOL1KaCGxdHFRR4Y2lSNqEkmN/shght9IcQO8hBzN+lL6X Gh2qEHIx1L0TIhiK2q8O8Hf0VyUijTfGvPclP91tKy3D65B+01VJ1lPRgS8GjjcI hZpbWZ+vimGuf2/aQc9e =ZCDv -----END PGP SIGNATURE----- --Apple-Mail=_5745AD70-9C7B-4CCE-9539-679BED716C1B-- From holler@ahsoftware.de Fri Feb 7 03:23:37 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4D31A0369 for ; Fri, 7 Feb 2014 03:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6hQ0K1NtVqu for ; Fri, 7 Feb 2014 03:23:35 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 84F011A0033 for ; Fri, 7 Feb 2014 03:23:35 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 39A34423C2A6; Fri, 7 Feb 2014 12:23:34 +0100 (CET) Received: from eiche.ahsoftware (p57B23F62.dip0.t-ipconnect.de [87.178.63.98]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 33756423C256 for ; Fri, 7 Feb 2014 12:23:33 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 54BF980378; Fri, 7 Feb 2014 12:23:31 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id 4977C7FA6C for ; Fri, 7 Feb 2014 11:23:25 +0000 (UTC) Message-ID: <52F4C22C.6080305@ahsoftware.de> Date: Fri, 07 Feb 2014 12:23:24 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 11:23:37 -0000 Am 06.02.2014 12:26, schrieb Kevin Smith: > Hi folks, > Discussion in the XSF and at the recent XMPP Summit has shown that > there are widespread issues with handling of iq responses in XMPP > software. This is probably something we need to consider handling. > > The basis of this is that many libraries/clients > a) Only check the id of an iq error/result, not the sender, to check > it matches one they've sent (Very Wrong) > b) Use predictably generated ids for stanzas (ill-advised, but not > strictly wrong) > c) Use known resource strings (bad, but not strictly wrong) Just to make it clear, the real problem here is neither the IDs nor the resources, but not checking the sender of the reply. If the sender would be checked, random IDs would only protect against sniffing/injecting packets into a stream or against malicious servers. The first (sniffing/injecting) is already protected by using encryption and the second (malicious servers) doesn't make much sense at all, because a client has to trust it's server. One of the reasons why clients don't check the sender part seems to be that it wasn't clear what the sender of a reply is, if the IQ query was without an explicit 'to' attribute. A simple rule for clients could be to check that the JID of IQ replies where the origin should be the connected server is either the JID of the server (no node, no resource) or the received bare JID (stripping a possible resource) is the bare JID of the client. Regards, Alexander Holler From k.i.smith@gmail.com Fri Feb 7 04:21:11 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F611A1DBE for ; Fri, 7 Feb 2014 04:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k2dPyOh8qy7 for ; Fri, 7 Feb 2014 04:21:10 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D4A571A0398 for ; Fri, 7 Feb 2014 04:21:09 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ld13so2592127vcb.32 for ; Fri, 07 Feb 2014 04:21:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WrKpSsDeq82WFJD8T+uKqe3NdNRlOlwPSZhoaZ/WyHM=; b=TXXi8AterrX370oYxJlHtYX7sOzXjwcFEYvGV3QgkApH6yNt+vT2KUmqc+48rWVwbu widsduqsj5jCzAxjOhBuewE1dEcRtd+pBch8KW4xhucexXpsKVL89r5vHYFwsUUFkC9c nHvK6dZ8rjzODN5hQQKzuTuzGofgxdbmSOLjyrQyRS+U5tYYv+u1J+XiBUIA9y14Hca4 1JWZF7QIri4teMeXSRK+2eTZiqtkJI6JOL8Gq0/gWfeYZiBSa3uexcHRY2BUxInlvkKL sq1uOUcDNJNgm0z2kvPjLqf4hnAz3EYlcs6on9onBnjcC84a7M7TyWzq1barXBdVfOUd QtxA== MIME-Version: 1.0 X-Received: by 10.58.255.233 with SMTP id at9mr10423352ved.20.1391775669675; Fri, 07 Feb 2014 04:21:09 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.52.245.134 with HTTP; Fri, 7 Feb 2014 04:21:09 -0800 (PST) In-Reply-To: <52F4C22C.6080305@ahsoftware.de> References: <52F4C22C.6080305@ahsoftware.de> Date: Fri, 7 Feb 2014 12:21:09 +0000 X-Google-Sender-Auth: KviLIJFa7cgF6pA4z3JPNWpAyJU Message-ID: From: Kevin Smith To: Alexander Holler Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 12:21:11 -0000 On Fri, Feb 7, 2014 at 11:23 AM, Alexander Holler wrote: > Am 06.02.2014 12:26, schrieb Kevin Smith: >> >> Hi folks, >> >> Discussion in the XSF and at the recent XMPP Summit has shown that >> there are widespread issues with handling of iq responses in XMPP >> software. This is probably something we need to consider handling. >> >> The basis of this is that many libraries/clients >> a) Only check the id of an iq error/result, not the sender, to check >> it matches one they've sent (Very Wrong) >> b) Use predictably generated ids for stanzas (ill-advised, but not >> strictly wrong) >> c) Use known resource strings (bad, but not strictly wrong) > > > Just to make it clear, the real problem here is neither the IDs nor the > resources, but not checking the sender of the reply. There are three issues here. They have different severities, as I noted initially, and not checking the sender of a reply is the one that is completely and fundamentally broken. That doesn't preclude that the other two are also issues (which we may or may not decide need addressing right now - although I'm of the opinion that while writing a document explaining the issues, explaining all three would be worthwhile). The most egregious of the vulnerabilities involve having all three present. We've known the from checking to be an issue for at least three years (that's the first record I could easily find of discussing the problem), but how widespread that problem is is news. Using predictable ids and resources is well known. (There's an additional point to be made about checking the from of roster pushes, although I believe this to be a less widespread problem) > One of the reasons why clients don't check the sender part seems to be that > it wasn't clear what the sender of a reply is, if the IQ query was without > an explicit 'to' attribute. I'd assert that the correct handling is clear, just that it seems to go unnoticed for some reason - but why we're in the state of needing to say something about this seems less important than what we now say. > A simple rule for clients could be to check that the JID of IQ replies where > the origin should be the connected server is either the JID of the server > (no node, no resource) or the received bare JID (stripping a possible > resource) is the bare JID of the client. The rules here are clear. If a client sends a stanza without a 'to', the server is to handle it as if it was sent to the bare JID of the client's session. The server replying with the server JID is a bug. /K From k.i.smith@gmail.com Fri Feb 7 04:22:34 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53D1A1DE2 for ; Fri, 7 Feb 2014 04:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2EFNIlMixoC for ; Fri, 7 Feb 2014 04:22:33 -0800 (PST) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 17AFB1A0398 for ; Fri, 7 Feb 2014 04:22:32 -0800 (PST) Received: by mail-vc0-f175.google.com with SMTP id ij19so2553985vcb.34 for ; Fri, 07 Feb 2014 04:22:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=cPdd0Rn1lM1Zcf5oPCeyPGaakK4GWBKmafny2ChSGOY=; b=0hHeL1b2f3GeljanJH5PPAtfsP4N98FJoa4ML27PuAZKxe4mPz7UHaTa/444rN3vcY 0JVnbWK5EMacayJE1QreTQtKnMpCiRlYafzdYFopX43IwNZmGkgSIyXhbb1IrCZAeYlZ E7hlBxKMCPDH4Crqqnu9i+zB6R/4NyYj/pDBU/7T4JZwcSiupi07k5c3YS8LKp0aOe3D EN4U+Py8cRRaR5Y34k4MOnL/IIW4OykSG7HirpfCOygAiSR5J5IlEWYiDFUGEitVK/uf yPLwWWVxL38r5uQA55J6Q/kjYMoqm574gGPJ1nG1lUat/SLOsQjwnETFeOZcWOkw4U8t KZYg== MIME-Version: 1.0 X-Received: by 10.221.37.1 with SMTP id tc1mr281576vcb.32.1391775752881; Fri, 07 Feb 2014 04:22:32 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.52.245.134 with HTTP; Fri, 7 Feb 2014 04:22:32 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 12:22:32 +0000 X-Google-Sender-Auth: IdfZUkg0gwSs8KRpsuvqiL6ZyuQ Message-ID: From: Kevin Smith To: "Joe Hildebrand (jhildebr)" Content-Type: text/plain; charset=ISO-8859-1 Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 12:22:34 -0000 On Thu, Feb 6, 2014 at 9:58 PM, Joe Hildebrand (jhildebr) wrote: > Can we start with an individual I-D that lays out the problem and > solution? That would allow us to make good decisions about what the next > step would be. Kev, that might be pretty quick for you to write... I'm happy to do it, or happy for Thijs to. Will discuss out of band. /K From jhildebr@cisco.com Fri Feb 7 07:11:20 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 403531A8034 for ; Fri, 7 Feb 2014 07:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2t617BQ7XbP for ; Fri, 7 Feb 2014 07:11:15 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id F26831AC3DD for ; Fri, 7 Feb 2014 07:11:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=491; q=dns/txt; s=iport; t=1391785875; x=1392995475; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YjgupvkglwsdcUaq0i/pc6U//lir1nFbdN21bab83v4=; b=Kba7RVtLIk2Q62d0PXDdkoPscsS7gT9LDSq5VwCT0WwYvw8mtPB0bXTb +gfkQsrgZw0Fc8i/im19iSNrAmCfc0p9zKVJ9AnfHHSc/b7gqZ0VoBro/ +Jmn/FXtGskMz04AAm3gh7WY70LRwHSlSAKubdnDxrOP7IB+w+yvBju2Y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAFr39FKtJXG+/2dsb2JhbABZgwyBD7pmhAKBDhZ0giYBAQQ6PxACAQg2EDIlAgQBDQWIBcxsF459B4Q4AQOYK5Ihgy2CKg X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208";a="18740535" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-1.cisco.com with ESMTP; 07 Feb 2014 15:10:59 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s17FAxSB026404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 15:10:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 09:10:59 -0600 From: "Joe Hildebrand (jhildebr)" To: Thijs Alkemade , Ben Campbell Thread-Topic: [xmpp] IQ Handling vulnerabilities Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEAgACdaoCAAL9TgP//w6cA Date: Fri, 7 Feb 2014 15:10:58 +0000 Message-ID: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> In-Reply-To: <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.82.234] Content-Type: text/plain; charset="us-ascii" Content-ID: <2937D75C7167544696B938336C2B0611@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 15:11:21 -0000 On 2/7/14 2:46 AM, "Thijs Alkemade" wrote: >The property we really want from ids is that predicting the next one(s) >given >some historic ones is hard. (as individual) I agree with everything you said to this point. However, I think we need to strengthen this a little: we want to ensure predicting the next one(s) in *any* way is hard. Luckily using the from address also mitigates this need slightly for some of the use cases. --=20 Joe Hildebrand From dave@cridland.net Fri Feb 7 07:50:55 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B801AC7EF for ; Fri, 7 Feb 2014 07:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JX4oJXZStSC for ; Fri, 7 Feb 2014 07:50:54 -0800 (PST) Received: from mail-oa0-x234.google.com (mail-oa0-x234.google.com [IPv6:2607:f8b0:4003:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 27EF41AC497 for ; Fri, 7 Feb 2014 07:50:52 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id i4so4382167oah.39 for ; Fri, 07 Feb 2014 07:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I7tEC06xO+Mw4WMyE4C1m8p+v1gkzAfyfgF3p8E18uo=; b=HutpoTsj5wxOu/zXT2/kto5WmWZDHXaaqXXgejelr9IEbcRKT3jyV23Tx5enoq2LG8 1bt+k/iJD5ugDf1TiCB754dvRtg6V+nopynYnoiwAoGzKJn3eec6znSz5S40H4dicy3Y efIIHiiRx0oV1vNFkmQY8PkHYNnD0wocaNS04= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I7tEC06xO+Mw4WMyE4C1m8p+v1gkzAfyfgF3p8E18uo=; b=j4X9LEDYpYYn5mZbW+/8xiHLjX91zJv2KAL0tzxqgOOL7bbNK3OPIl0T/m8Sp69jwh MMzdLn9vBUZ3qD1vRXEVFdIC0GkL9Iuohjj76Bf1YK4RIVqq4BimKKyinjebjqTwiO2l T1dJVGfkhLL6faxOjVOz4I5gcb4OgE+88v+uuuqCAI/i4KZKebU8Ew9axPVg5xUFHlDe uXoti2f05rrnpv6RW6E2bBoATrVEErqw/A93xOZd409N6WQnJJkSXX5YSMzTPqqaVan/ cKka2XCiUvy8HBVOS31KgH5KUVWdKvIX/DkVeeOBwl5Ko+fmkWZ+csNZAiOBh8B2YvFd VhPg== X-Gm-Message-State: ALoCoQle/HgQz+uIC/Kkm2t6Y/I7o1OU64BNCQIST6aAADrouUnL6oy9c9NJbsDtbKeEVYTnoPs7 MIME-Version: 1.0 X-Received: by 10.182.157.114 with SMTP id wl18mr13380577obb.52.1391788251817; Fri, 07 Feb 2014 07:50:51 -0800 (PST) Received: by 10.60.55.138 with HTTP; Fri, 7 Feb 2014 07:50:51 -0800 (PST) In-Reply-To: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> Date: Fri, 7 Feb 2014 15:50:51 +0000 Message-ID: From: Dave Cridland To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=f46d041828305a3fe004f1d2f49e Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 15:50:56 -0000 --f46d041828305a3fe004f1d2f49e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > On 2/7/14 2:46 AM, "Thijs Alkemade" wrote: > > >The property we really want from ids is that predicting the next one(s) > >given > >some historic ones is hard. > > (as individual) > > I agree with everything you said to this point. However, I think we need > to strengthen this a little: we want to ensure predicting the next one(s) > in *any* way is hard. > > Luckily using the from address also mitigates this need slightly for some > of the use cases. > What are the attacks possible against an entity using predictable stanza ids, but which otherwise acts properly (ie, checks to/from on responses, etc)? I'm a bit confused - if an entity isn't checking the to/from of the responses, then sure there's a slew of attacks possible. If it *also* has predictable ids, then the attacks are easier - but they're the same attacks. Aren't they? I'm not saying that we shouldn't generally recommend unpredictable ids - it seems relatively simple and causes little harm - but cryptographically secure ones seems overkill, and I'm always nervous of imposing unneeded drains on the entropy store of a system. Also, I've mentioned this elsewhere, but I'll mention it here too: much of the XMPP community seems focussed on clients exhibiting this class of bug, and attacks against those clients. I strongly suspect that not all servers are immune to this, and the attacks on servers are likely to be just as fascinating. Dave. --f46d041828305a3fe004f1d2f49e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr) <= ;jhildebr@cisco.com= > wrote:
On 2/7/14 2:46 AM, "Thi= js Alkemade" <thijs@xnyhps.nl> wrote:

>The property we really want from ids is that predicting the next one(s)=
>given
>some historic ones is hard.

(as individual)

I agree with everything you said to this point. =A0However, I think we need=
to strengthen this a little: we want to ensure predicting the next one(s) in *any* way is hard.

Luckily using the from address also mitigates this need slightly for some of the use cases.


I'm not saying that we shouldn't generally reco= mmend unpredictable ids - it seems relatively simple and causes little harm= - but cryptographically secure ones seems overkill, and I'm always ner= vous of imposing unneeded drains on the entropy store of a system.

Also, I've mentioned this elsewhere, but I'll m= ention it here too: much of the XMPP community seems focussed on clients ex= hibiting this class of bug, and attacks against those clients. I strongly s= uspect that not all servers are immune to this, and the attacks on servers = are likely to be just as fascinating.

Dave.
--f46d041828305a3fe004f1d2f49e-- From k.i.smith@gmail.com Fri Feb 7 07:57:26 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88681ACC7E for ; Fri, 7 Feb 2014 07:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UveOlrRqbRc for ; Fri, 7 Feb 2014 07:57:24 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7A76E1AC497 for ; Fri, 7 Feb 2014 07:57:24 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id oz11so2852205veb.4 for ; Fri, 07 Feb 2014 07:57:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rjBJvTEPd0Q89Je66dsI22iVvGmRgTecHev3gtZja2k=; b=hbKIQsB7IDJ0XqvkgO/x0L2KYvcrVOCSm7nO9FNjzpfMWMvqP6ZO40UQIbM0UHhdku Ojn4cloaZQAeVXagS3e7Re5NU7SGmnqSFbemVp0qwNOruHDacWPzJTshvYefRM2cgaco Go8JG3pJltA54sbQHSSmXcsjLWwKnC4IQEMXy/u5WinXUEewUs1oXmg9u2oqsJStvNpj PWMoRZXUoAn2N+x2kioUOe7nF5ISOwqyFL5QQ0yeYf/hyEL3NmW2v7h7Py5v6nJaPyoM EMSIzFoLMvUDKYK+3nZfP00PadbGwDKFmAFinftuRYUlmCV6nZI3VcNtpKNOoVMcTVww cvSA== MIME-Version: 1.0 X-Received: by 10.58.181.230 with SMTP id dz6mr644908vec.35.1391788644243; Fri, 07 Feb 2014 07:57:24 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.52.245.134 with HTTP; Fri, 7 Feb 2014 07:57:24 -0800 (PST) In-Reply-To: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> Date: Fri, 7 Feb 2014 15:57:24 +0000 X-Google-Sender-Auth: HR4BxLGv1h8Cy4uo9CfSmJ-unac Message-ID: From: Kevin Smith To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 15:57:26 -0000 On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland wrote: > On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr) > wrote: >> >> On 2/7/14 2:46 AM, "Thijs Alkemade" wrote: >> >> >The property we really want from ids is that predicting the next one(s) >> >given >> >some historic ones is hard. >> >> (as individual) >> >> I agree with everything you said to this point. However, I think we need >> to strengthen this a little: we want to ensure predicting the next one(s) >> in *any* way is hard. >> >> Luckily using the from address also mitigates this need slightly for some >> of the use cases. > > > What are the attacks possible against an entity using predictable stanza > ids, but which otherwise acts properly (ie, checks to/from on responses, > etc)? > > I'm a bit confused - if an entity isn't checking the to/from of the > responses, then sure there's a slew of attacks possible. If it *also* has > predictable ids, then the attacks are easier - but they're the same attacks. > Aren't they? Yes and no. By far the biggest issue here is the stanza-faking one, and predictable ids are a part of what's needed to make the simplest attack, but aren't actually the broken bit. There are various unlikely (and arguably unimportant, I suppose) issues around being able to observe where in a stream a client is. As an incredibly contrived example, client A shows client B an id that means "You are the first person I'm sending a message to this session" and user A says to user B "I'm busy chatting to C in another window". > Also, I've mentioned this elsewhere, but I'll mention it here too: much of > the XMPP community seems focussed on clients exhibiting this class of bug, > and attacks against those clients. I strongly suspect that not all servers > are immune to this, and the attacks on servers are likely to be just as > fascinating. Yes, it's clear that the document needs to cover this. /K From jhildebr@cisco.com Fri Feb 7 08:13:20 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D6B1AC4B3 for ; Fri, 7 Feb 2014 08:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.035 X-Spam-Level: X-Spam-Status: No, score=-10.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEkvuCvunyeY for ; Fri, 7 Feb 2014 08:13:18 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEEA1A03E6 for ; Fri, 7 Feb 2014 08:13:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4894; q=dns/txt; s=iport; t=1391789598; x=1392999198; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7znhPWFi3bnBwufTiQszhvIuNHJVbcTaZtE0F6YLuLo=; b=EV4LQteWBQHtwVkq1uLJPFXjE3IIL+2FuQD/P2Q+nf9pkufN5kVYXWCA frLyqcG+2EC1CfICTGXPxrnamQYaACxGbDymwJ2WCNUX6otviJFoHdO3A JdkR2J0fJ2r93coapalVeukdVeGrg43oOh+wmB8rW1xm+ySzh2GRLiWri s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAB0F9VKtJXG9/2dsb2JhbABZgwy7dYQCgQ4WdIImAQEEeRACAQgEOwcyFBECBA4FFIdxzFAXjn0HgySBFASYK5Ihgy0 X-IronPort-AV: E=Sophos;i="4.95,801,1384300800"; d="scan'208,217";a="18757772" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 07 Feb 2014 16:13:17 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s17GDHos008660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Feb 2014 16:13:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Fri, 7 Feb 2014 10:13:17 -0600 From: "Joe Hildebrand (jhildebr)" To: Dave Cridland Thread-Topic: [xmpp] IQ Handling vulnerabilities Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEAgACdaoCAAL9TgP//w6cAgACRRID//6GvVw== Date: Fri, 7 Feb 2014 16:13:16 +0000 Message-ID: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CF1A492854B54A959A4B0EC572A3CDBDciscocom_" MIME-Version: 1.0 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:13:21 -0000 --_000_CF1A492854B54A959A4B0EC572A3CDBDciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have a couple of ludicrous s2s attacks on mind, but more important I thin= k is doing what Mobile/terse. DYAC. On Feb 7, 2014, at 7:50 AM, "Dave Cridland" > wrote: On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr) > wrote: On 2/7/14 2:46 AM, "Thijs Alkemade" > wrote: >The property we really want from ids is that predicting the next one(s) >given >some historic ones is hard. (as individual) I agree with everything you said to this point. However, I think we need to strengthen this a little: we want to ensure predicting the next one(s) in *any* way is hard. Luckily using the from address also mitigates this need slightly for some of the use cases. What are the attacks possible against an entity using predictable stanza id= s, but which otherwise acts properly (ie, checks to/from on responses, etc)= ? I'm a bit confused - if an entity isn't checking the to/from of the respons= es, then sure there's a slew of attacks possible. If it *also* has predicta= ble ids, then the attacks are easier - but they're the same attacks. Aren't= they? I'm not saying that we shouldn't generally recommend unpredictable ids - it= seems relatively simple and causes little harm - but cryptographically sec= ure ones seems overkill, and I'm always nervous of imposing unneeded drains= on the entropy store of a system. Also, I've mentioned this elsewhere, but I'll mention it here too: much of = the XMPP community seems focussed on clients exhibiting this class of bug, = and attacks against those clients. I strongly suspect that not all servers = are immune to this, and the attacks on servers are likely to be just as fas= cinating. Dave. --_000_CF1A492854B54A959A4B0EC572A3CDBDciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I have a couple of ludicrous s2s attacks on mind, but more important I= think is doing what 

Mobile/terse. DYAC. 
On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (= jhildebr) <jhildebr@cisco.com> wrote:
On 2/7/14 2:46 AM, "Thijs Alkemade" <thijs@xnyhps.nl> wrote:

>The property we really want from ids is that predicting the next one(s)=
>given
>some historic ones is hard.

(as individual)

I agree with everything you said to this point.  However, I think we n= eed
to strengthen this a little: we want to ensure predicting the next one(s) in *any* way is hard.

Luckily using the from address also mitigates this need slightly for some of the use cases.

What are the attacks possible against an entity using predictable stan= za ids, but which otherwise acts properly (ie, checks to/from on responses,= etc)?

I'm a bit confused - if an entity isn't checking the to/from of the re= sponses, then sure there's a slew of attacks possible. If it *also* has pre= dictable ids, then the attacks are easier - but they're the same attacks. A= ren't they?

I'm not saying that we shouldn't generally recommend unpredictable ids= - it seems relatively simple and causes little harm - but cryptographicall= y secure ones seems overkill, and I'm always nervous of imposing unneeded d= rains on the entropy store of a system.

Also, I've mentioned this elsewhere, but I'll mention it here too: muc= h of the XMPP community seems focussed on clients exhibiting this class of = bug, and attacks against those clients. I strongly suspect that not all ser= vers are immune to this, and the attacks on servers are likely to be just as fascinating.

Dave.
--_000_CF1A492854B54A959A4B0EC572A3CDBDciscocom_-- From waqas20@gmail.com Fri Feb 7 08:40:19 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFF21A0500 for ; Fri, 7 Feb 2014 08:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9t9iRpGJMxt for ; Fri, 7 Feb 2014 08:40:16 -0800 (PST) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC801A01B9 for ; Fri, 7 Feb 2014 08:40:15 -0800 (PST) Received: by mail-ve0-f176.google.com with SMTP id oz11so2904571veb.7 for ; Fri, 07 Feb 2014 08:40:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QYIppubNE75dK7uSXelw9jgvzoxKmGJa/9gEOJDbiZA=; b=XmzRNZuaErn0t0SBuEsp3w5i/aEC2HvssO3OUZBRPE8WkYOO6wvinzVrarfY08uUrj MwkWFvlDBWPexw5fO1U6h0b+fI5H2vHLSUZVwRBhnEvU/Ux7244vkaBrWvg+6jggoEWW Uky0/7RSABWrkE47+gazjNfDrJ1mn6Iyqj+EGA0lPvIssbVu3Uw0fgOhgBgMqkwqeOy7 Dg6hpPHRSKdKUKW+RAXQ6pMdw6ecwtutYi86cBM7KLhnNyXClyPMw3W7ywzK/21UakkO f/Hp3bFuOC6CNCBtmnOQ7kVnS2J6c6gmWLp7MiP/crd6ZpHe+L+X1K5HKGKd8C1ceTIg Yj/A== X-Received: by 10.220.164.80 with SMTP id d16mr10968586vcy.15.1391791215739; Fri, 07 Feb 2014 08:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.74.104 with HTTP; Fri, 7 Feb 2014 08:39:55 -0800 (PST) In-Reply-To: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> From: Waqas Hussain Date: Fri, 7 Feb 2014 11:39:55 -0500 Message-ID: To: Kevin Smith Content-Type: text/plain; charset=ISO-8859-1 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:40:19 -0000 On Fri, Feb 7, 2014 at 10:57 AM, Kevin Smith wrote: > On Fri, Feb 7, 2014 at 3:50 PM, Dave Cridland wrote: >> On Fri, Feb 7, 2014 at 3:10 PM, Joe Hildebrand (jhildebr) >> wrote: >>> >>> On 2/7/14 2:46 AM, "Thijs Alkemade" wrote: >>> >>> >The property we really want from ids is that predicting the next one(s) >>> >given >>> >some historic ones is hard. >>> >>> (as individual) >>> >>> I agree with everything you said to this point. However, I think we need >>> to strengthen this a little: we want to ensure predicting the next one(s) >>> in *any* way is hard. >>> >>> Luckily using the from address also mitigates this need slightly for some >>> of the use cases. >> >> >> What are the attacks possible against an entity using predictable stanza >> ids, but which otherwise acts properly (ie, checks to/from on responses, >> etc)? >> >> I'm a bit confused - if an entity isn't checking the to/from of the >> responses, then sure there's a slew of attacks possible. If it *also* has >> predictable ids, then the attacks are easier - but they're the same attacks. >> Aren't they? > > Yes and no. By far the biggest issue here is the stanza-faking one, > and predictable ids are a part of what's needed to make the simplest > attack, but aren't actually the broken bit. > > There are various unlikely (and arguably unimportant, I suppose) > issues around being able to observe where in a stream a client is. As > an incredibly contrived example, client A shows client B an id that > means "You are the first person I'm sending a message to this session" > and user A says to user B "I'm busy chatting to C in another window". > I'll note that cryptographically secure randomness comes with a cost. With many operating systems (e.g., Linux) generating tons of truly random IDs (/dev/random) will lead to a system constantly starved for entropy (and no, /dev/urandom is not cryptographically secure in Linux). If crypto-level randomness is not required, then your IDs are predictable. It's harder than incrementing counters, but not by much. If the problem here is that something simple like incrementing IDs leak state across remote JIDs, then a simple solution is to use a separate incrementing counter for separate remote JIDs. A CSPRNG is unnecessary and expensive. -- Waqas Hussain From holler@ahsoftware.de Sat Feb 8 04:06:50 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC6D1ADF6E for ; Sat, 8 Feb 2014 04:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kijL8F2Vq-9f for ; Sat, 8 Feb 2014 04:06:49 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD431ADF6B for ; Sat, 8 Feb 2014 04:06:49 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 38385423C2A6; Sat, 8 Feb 2014 13:06:48 +0100 (CET) Received: from eiche.ahsoftware (p57B230A6.dip0.t-ipconnect.de [87.178.48.166]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id BC1FF423C2A4 for ; Sat, 8 Feb 2014 13:06:33 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 5870180378; Sat, 8 Feb 2014 13:06:32 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id A08E57F897; Sat, 8 Feb 2014 12:06:29 +0000 (UTC) Message-ID: <52F61DC4.5010308@ahsoftware.de> Date: Sat, 08 Feb 2014 13:06:28 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: kevin@kismith.co.uk References: <52F4C22C.6080305@ahsoftware.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 12:06:51 -0000 Am 07.02.2014 13:21, schrieb Kevin Smith: > On Fri, Feb 7, 2014 at 11:23 AM, Alexander Holler wrote: >> A simple rule for clients could be to check that the JID of IQ replies where >> the origin should be the connected server is either the JID of the server >> (no node, no resource) or the received bare JID (stripping a possible >> resource) is the bare JID of the client. > > The rules here are clear. If a client sends a stanza without a 'to', > the server is to handle it as if it was sent to the bare JID of the > client's session. The server replying with the server JID is a bug. The rules are only clear for the current RFC 6120, but not for that obsolet RFC 3120, which I assume was the base for most available XMPP-servers (and many clients). Regards, Alexander Holler From holler@ahsoftware.de Sat Feb 8 04:24:17 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C4A1A028C for ; Sat, 8 Feb 2014 04:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.108 X-Spam-Level: ** X-Spam-Status: No, score=2.108 tagged_above=-999 required=5 tests=[HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7vPb3AD9KDM for ; Sat, 8 Feb 2014 04:24:15 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id A767F1A00ED for ; Sat, 8 Feb 2014 04:24:15 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 768DA423C2C6; Sat, 8 Feb 2014 13:17:20 +0100 (CET) Received: from eiche.ahsoftware (p57B230A6.dip0.t-ipconnect.de [87.178.48.166]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id E11CE423C2BA for ; Sat, 8 Feb 2014 13:17:19 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 49AB580378; Sat, 8 Feb 2014 13:17:19 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id A228A7F897; Sat, 8 Feb 2014 12:17:15 +0000 (UTC) Message-ID: <52F6204B.7050500@ahsoftware.de> Date: Sat, 08 Feb 2014 13:17:15 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: kevin@kismith.co.uk, Dave Cridland References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 12:24:17 -0000 Am 07.02.2014 16:57, schrieb Kevin Smith: > There are various unlikely (and arguably unimportant, I suppose) > issues around being able to observe where in a stream a client is. As > an incredibly contrived example, client A shows client B an id that > means "You are the first person I'm sending a message to this session" > and user A says to user B "I'm busy chatting to C in another window". I would call that information leaks but not vulnerabilities. So predictable IDs and resource names might lead to some information leaks, but not checking the from is a vulnerability. Regards, Alexader Holler From ben@nostrum.com Sat Feb 8 11:39:06 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 811F31A0564 for ; Sat, 8 Feb 2014 11:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_hLJ_5kwXQO for ; Sat, 8 Feb 2014 11:39:04 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C48881A0562 for ; Sat, 8 Feb 2014 11:39:04 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s18JcvZD077477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 8 Feb 2014 13:38:59 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: Date: Sat, 8 Feb 2014 13:38:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1E4BD173-7766-433F-ADC2-DF854298FEFD@nostrum.com> References: To: kevin@kismith.co.uk X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 19:39:06 -0000 (As Chair) Just a reminder that the draft deadline for IETF 89 is Feb 14. That's = coming up soon. The absence of a draft would not prevent us from discussing this issue = at the meeting, but the presence of a draft would help :-) Thanks! Ben. On Feb 7, 2014, at 6:22 AM, Kevin Smith wrote: > On Thu, Feb 6, 2014 at 9:58 PM, Joe Hildebrand (jhildebr) > wrote: >> Can we start with an individual I-D that lays out the problem and >> solution? That would allow us to make good decisions about what the = next >> step would be. Kev, that might be pretty quick for you to write... >=20 > I'm happy to do it, or happy for Thijs to. Will discuss out of band. >=20 > /K > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From thijs@xnyhps.nl Sun Feb 9 06:13:47 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E901A02A8 for ; Sun, 9 Feb 2014 06:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.446 X-Spam-Level: * X-Spam-Status: No, score=1.446 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjNBFkRGDnjT for ; Sun, 9 Feb 2014 06:13:45 -0800 (PST) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id B37C61A00F5 for ; Sun, 9 Feb 2014 06:13:44 -0800 (PST) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 73DB8201B7; Sun, 9 Feb 2014 15:13:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1391955218; bh=dn5g7xAupLHQTsmM2tu3cPOKisfQ63bUmPWCAht5T2k=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hGkrbmwGBOdIETUuKOrakxm+NlQ8hmMZqliRP5nAYQB1HZo7w9EKu5odO+0PWuWUx ax3xGX6GS6jPG32tvysdLttapoQr95/t4gIIwSDSeJt0f97kAhTrq6hRkDT6YYSQwL xBQnPsYm8wiWIzfv3WiUNduFSU/9RulSfR3uqebs= Content-Type: multipart/signed; boundary="Apple-Mail=_DF8E7BC4-A1AE-4221-94C1-2C874FB4471D"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thijs Alkemade In-Reply-To: Date: Sun, 9 Feb 2014 15:13:34 +0100 Message-Id: <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> To: Dave Cridland X-Mailer: Apple Mail (2.1827) Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 14:13:47 -0000 --Apple-Mail=_DF8E7BC4-A1AE-4221-94C1-2C874FB4471D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 7 feb. 2014, at 16:50, Dave Cridland wrote: > What are the attacks possible against an entity using predictable = stanza ids, but which otherwise acts properly (ie, checks to/from on = responses, etc)? >=20 > I'm a bit confused - if an entity isn't checking the to/from of the = responses, then sure there's a slew of attacks possible. If it *also* = has predictable ids, then the attacks are easier - but they're the same = attacks. Aren't they? The least far-fetched scenario I can think of: you're offering a file = transfer to someone's MUC room nick. The person disconnects, someone else takes = their nick and intercepts the file transfer by guessing the 'id' that was = used. This is also a scenario where a per-address counter will not protect you. = (Though a better fix is probably to cancel all pending queries to participants = when you see them disappear from the room...) > I'm not saying that we shouldn't generally recommend unpredictable ids = - it seems relatively simple and causes little harm - but = cryptographically secure ones seems overkill, and I'm always nervous of = imposing unneeded drains on the entropy store of a system. >=20 > Also, I've mentioned this elsewhere, but I'll mention it here too: = much of the XMPP community seems focussed on clients exhibiting this = class of bug, and attacks against those clients. I strongly suspect that = not all servers are immune to this, and the attacks on servers are = likely to be just as fascinating. I'm trying to think of a situation where the server sends a iq 'get' to = the client, but I don't really know any. A lot of iq 'set's, where the = server informs the client of something (and probably doesn't really care = whether that results in an 'error' or 'result'), but nothing where the server wants = to know something from the client. Could you give an example? Thijs --Apple-Mail=_DF8E7BC4-A1AE-4221-94C1-2C874FB4471D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS940PAAoJELRGwhIrI4PE9jAP/R56/hTL+YxFS76RODWuw7Mu 3QzhN193Aux+gGDK9ORBYWbfX3MX2wocVIOdm63GM4Ls94R+sEHJM8F+I1Me9Ajq FLnpXlJKO6if2FPAxWcnRPRVGCc5u4JPZPSMfZN/6BsVBg0FWBkPRKMk5ScGVGyz F8O70JQMo3VBu7x/YUc43iuwYTQuwoLZ61gDrw4ENamDHMk8zNPfQ0BfRIV5lct1 zPpui++Nt2ekXflS1N/aaNbFE2EETVYxFi8qi22IvfwjjYjc2KvZNHuuj54o1ghj QSK5HrhnGfcHjzfODZQmSHvtNBdKUoYtQn2va1raoXCbzsEw8Lym8h8/T7XYJO97 LPh5qy65BcV2U9KRTplnSrCs9djxAPulct1Bcmf6WgkROMFpM847fgnodDWtTK4l tcan78dKUkD0YHuW9RsYolS/3OxCWfdY/tExZGtBS6OFKRReJazJASQrGKFvn7NP g0fRX16+CYPPCdzV+46DZ2/yDTyV3jZPNBS+jRfXcn88h/PTC3YD4Uc1Lb/rTljV RqUgvKm0ZRk1mKXt8+BGtHVYDKMovxfqyMOCkkt7mUbxQWvKSA1jdgbNofKcTEik jbRTlGYU5+3mGkKJl77XH5uYLduQrmy4w6ZIV+LoKuPjOARj7HgJpPW2cDG1sYGm P0reAftGLJTXxiFwgiju =JbgC -----END PGP SIGNATURE----- --Apple-Mail=_DF8E7BC4-A1AE-4221-94C1-2C874FB4471D-- From waqas20@gmail.com Sun Feb 9 07:01:33 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E801A0325 for ; Sun, 9 Feb 2014 07:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhrdU9x-74bi for ; Sun, 9 Feb 2014 07:01:32 -0800 (PST) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 50B341A0320 for ; Sun, 9 Feb 2014 07:01:32 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id x14so3971908vbb.22 for ; Sun, 09 Feb 2014 07:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=m62Mu8BObcQdaizNNdnolPJ9SniVfpz2HMMgNvQ28oE=; b=PyAvq6TAxCDdM7zTZzoC5Ag4M9ynBOp29MC49N1InJhOlvIEJDd6AYh22lyzvnHWlL ksR5D7KT6pzinXvPBKEG7uL1ZmF8tWoJ6QHwB6I2Ro71WAfHD2fm+6oWOMacBZeTtQaF MIfH+lqJOWqU+FOD7UbKLtSNl+Nzar7gx0jn2Oaz6wXUuewrfuevJh8RRfdyYwIfZFGm 8Kq1swiev33ik923z5s1W8ukrTdMO+UF50RGFQcwN5knypn8Xs7WJWClm4lJ5EFkLo9J efUnTowOU8+XDbzFQouIE57C33snIuMJcPQfqBGyd+1/RMLeFO4dW9DvgPwHkTf57KlI EroA== X-Received: by 10.52.95.233 with SMTP id dn9mr16382833vdb.3.1391958092271; Sun, 09 Feb 2014 07:01:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.74.104 with HTTP; Sun, 9 Feb 2014 07:01:12 -0800 (PST) In-Reply-To: <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> From: Waqas Hussain Date: Sun, 9 Feb 2014 10:01:12 -0500 Message-ID: To: Thijs Alkemade Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 15:01:33 -0000 On Sun, Feb 9, 2014 at 9:13 AM, Thijs Alkemade wrote: > >> I'm not saying that we shouldn't generally recommend unpredictable ids -= it seems relatively simple and causes little harm - but cryptographically = secure ones seems overkill, and I'm always nervous of imposing unneeded dra= ins on the entropy store of a system. >> >> Also, I've mentioned this elsewhere, but I'll mention it here too: much = of the XMPP community seems focussed on clients exhibiting this class of bu= g, and attacks against those clients. I strongly suspect that not all serve= rs are immune to this, and the attacks on servers are likely to be just as = fascinating. > > I'm trying to think of a situation where the server sends a iq 'get' to t= he > client, but I don't really know any. A lot of iq 'set's, where the server > informs the client of something (and probably doesn't really care whether= that > results in an 'error' or 'result'), but nothing where the server wants to= know > something from the client. Could you give an example? > disco#info requests for PEP, though in this case Prosody happily uses a single constant id for all requests, only using the sender's JID and subscription status. MUC is another when it proxies IQ requests (vCards, private IQs), and for vCards Prosody encodes a bunch of information in the id for verification. A quick search through prosody-modules found implementations of XEP-0309: Service Directories and XEP-268: Incidents Handling listening for IQ results. -- Waqas Hussain From k.i.smith@gmail.com Sun Feb 9 08:56:27 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02161A0322 for ; Sun, 9 Feb 2014 08:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDhOIgNKVCCR for ; Sun, 9 Feb 2014 08:56:26 -0800 (PST) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id EDE361A01DA for ; Sun, 9 Feb 2014 08:56:25 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id cz12so4315239veb.12 for ; Sun, 09 Feb 2014 08:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=PBXGFcIYnOOY51ycS9zi9LZ8HMas9af/fpBSDRmwdxc=; b=Q7C9Gi+g0FjDwKh8XQIHd77WWpi3PSxkuPxCMGERi8CepggUafZIOUOhJVYPoiBapk lIvf4DOt1VG1WmhM8yzKL4Ga7aXOOpxRGF2zDkwbkiXw1exN82b8vWbVzEQf+QRYMQg4 oONEbcC/ULr6UB7LlR+oSWU/3J/edMKgD0WjYTA+dM+rNPHRmtQ3ciCn/MGZy7hofnAv 0nvYXpJ+8D8gBBqjbTN9RfeIMJK0BM+RI1wPL3PmVNiQsaWflgqxQsbYvuCGuHEXwu+k t8WN2xmVIS0/biGdMU0ddWHExPuqRQ3ATZhkaABftL8fxYFxlQnulcps1vGQxoET3wS9 XATA== MIME-Version: 1.0 X-Received: by 10.52.171.68 with SMTP id as4mr16817096vdc.0.1391964985831; Sun, 09 Feb 2014 08:56:25 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.52.245.134 with HTTP; Sun, 9 Feb 2014 08:56:25 -0800 (PST) In-Reply-To: <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> Date: Sun, 9 Feb 2014 16:56:25 +0000 X-Google-Sender-Auth: N4Yp5-A-_nkQsJk_KEDy12_EcMM Message-ID: From: Kevin Smith To: Thijs Alkemade Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 16:56:27 -0000 On Sun, Feb 9, 2014 at 2:13 PM, Thijs Alkemade wrote: > > On 7 feb. 2014, at 16:50, Dave Cridland wrote: > >> What are the attacks possible against an entity using predictable stanza= ids, but which otherwise acts properly (ie, checks to/from on responses, e= tc)? >> >> I'm a bit confused - if an entity isn't checking the to/from of the resp= onses, then sure there's a slew of attacks possible. If it *also* has predi= ctable ids, then the attacks are easier - but they're the same attacks. Are= n't they? > > The least far-fetched scenario I can think of: you're offering a file tra= nsfer > to someone's MUC room nick. The person disconnects, someone else takes th= eir > nick and intercepts the file transfer by guessing the 'id' that was used.= This > is also a scenario where a per-address counter will not protect you. (Tho= ugh a > better fix is probably to cancel all pending queries to participants when= you > see them disappear from the room...) > >> I'm not saying that we shouldn't generally recommend unpredictable ids -= it seems relatively simple and causes little harm - but cryptographically = secure ones seems overkill, and I'm always nervous of imposing unneeded dra= ins on the entropy store of a system. >> >> Also, I've mentioned this elsewhere, but I'll mention it here too: much = of the XMPP community seems focussed on clients exhibiting this class of bu= g, and attacks against those clients. I strongly suspect that not all serve= rs are immune to this, and the attacks on servers are likely to be just as = fascinating. > > I'm trying to think of a situation where the server sends a iq 'get' to t= he > client, but I don't really know any. A lot of iq 'set's, where the server > informs the client of something (and probably doesn't really care whether= that > results in an 'error' or 'result'), but nothing where the server wants to= know > something from the client. Could you give an example? There's a fun one where the server sends a ping to the client to check for inactivity. If another client can keep a dead session alive, that's quite interesting. /K From dave@cridland.net Sun Feb 9 11:30:59 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314751A0545 for ; Sun, 9 Feb 2014 11:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6auJZ2SGaur4 for ; Sun, 9 Feb 2014 11:30:57 -0800 (PST) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 721511A0443 for ; Sun, 9 Feb 2014 11:30:57 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i11so6555780oag.4 for ; Sun, 09 Feb 2014 11:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eYr2aQjz2lapQlqx3sdRUlUu5R5MTmCMqpjSB3YsTFQ=; b=VYyypO6JM33DMwBQHuQNcvhAkKaMkj1c4gHPLEk+MUqd0AhslpESeAFhfGAGktdkzj QZ121ra1PbCZjuDwQE7YH3LhOwqMyklDcDcaFeHYvTSPW7OLV/O76yrVs4GGoMWPRpw0 8NI3anbOnxP4eWR6DnLYVM1eRdOoWplwY8kIs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=eYr2aQjz2lapQlqx3sdRUlUu5R5MTmCMqpjSB3YsTFQ=; b=HviK5yv2SBOaIvUVugKR1C3haaWH6xOPnv8Ki7Rve6Ja9Fs67QkQk5z3Mi4yn+D8Rh 7NxE4uEmo+NxEVgD13rEpeM+8mprPAkV6EPlZ5nG3QKBQnOY7amtBgnKxqM84LONx9SM 0DmlDP71UmHDwuNCaQFYx5igGCaSxh9ZyMH08REfzhWwNmGt+vkfzc04+Qxqck6PZcoP VVJHVo27w+taIrFgDg5diucZXuLN0W32Is0hthBffyZVjQzo6iH2h6EGtnJAamYvNnUg j3xYIFIaTMQWpOpMWtsgjsFope3cYeuiLALqz+CpvrK4hLatp4l//me7aBlzkkl6kOtv eozg== X-Gm-Message-State: ALoCoQl6kPnkHeQ3QNpXg2d/llMgckqkSIUS6zZht0T78undDkWZeSJlbxFrhT5dFMezysTfM5nc MIME-Version: 1.0 X-Received: by 10.60.229.4 with SMTP id sm4mr23538667oec.9.1391974257270; Sun, 09 Feb 2014 11:30:57 -0800 (PST) Received: by 10.60.55.138 with HTTP; Sun, 9 Feb 2014 11:30:57 -0800 (PST) In-Reply-To: <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> Date: Sun, 9 Feb 2014 19:30:57 +0000 Message-ID: From: Dave Cridland To: Thijs Alkemade Content-Type: multipart/alternative; boundary=001a1136286025ef8704f1fe43a1 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 19:30:59 -0000 --001a1136286025ef8704f1fe43a1 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Feb 9, 2014 at 2:13 PM, Thijs Alkemade wrote: > > On 7 feb. 2014, at 16:50, Dave Cridland wrote: > > > What are the attacks possible against an entity using predictable stanza > ids, but which otherwise acts properly (ie, checks to/from on responses, > etc)? > > > > I'm a bit confused - if an entity isn't checking the to/from of the > responses, then sure there's a slew of attacks possible. If it *also* has > predictable ids, then the attacks are easier - but they're the same > attacks. Aren't they? > > The least far-fetched scenario I can think of: you're offering a file > transfer > to someone's MUC room nick. The person disconnects, someone else takes > their > nick and intercepts the file transfer by guessing the 'id' that was used. > This > is also a scenario where a per-address counter will not protect you. > (Though a > better fix is probably to cancel all pending queries to participants when > you > see them disappear from the room...) > > Ah! Nice one. FWIW, it's possible to hide a offline/online event by DOSsing the original server then spoofing it, which is hard work but practical given DNS spoofed dialback. Also, there's a bunch of MUC-replacement attacks, I suspect, that don't involve having to predict a stanza id. > > I'm not saying that we shouldn't generally recommend unpredictable ids - > it seems relatively simple and causes little harm - but cryptographically > secure ones seems overkill, and I'm always nervous of imposing unneeded > drains on the entropy store of a system. > > > > Also, I've mentioned this elsewhere, but I'll mention it here too: much > of the XMPP community seems focussed on clients exhibiting this class of > bug, and attacks against those clients. I strongly suspect that not all > servers are immune to this, and the attacks on servers are likely to be > just as fascinating. > > I'm trying to think of a situation where the server sends a iq 'get' to the > client, but I don't really know any. A lot of iq 'set's, where the server > informs the client of something (and probably doesn't really care whether > that > results in an 'error' or 'result'), but nothing where the server wants to > know > something from the client. Could you give an example? > > As Waqas says, there's a bunch of cases. It gets worse if the server is running optimization-related intercepts, such as disco caching, I suspect. I think there are interesting cases around an XMPP-level file-transfer proxy (for anti-virus, or SI/Jingle translation) for example. I'd hope Kev's example is way off, though - I suspect that servers ignore the XEP-0199 reply stanza and just look for activity on the socket. Dave. --001a1136286025ef8704f1fe43a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Sun, Feb 9, 2014 at 2:13 PM, Thijs Alkemade &l= t;thijs@xnyhps.nl&= gt; wrote:

On 7 feb. 2014, at 16:50, Dave Cridland <dave@cridland.net> wrote:

> What are the attacks possible against an entity using predictable stan= za ids, but which otherwise acts properly (ie, checks to/from on responses,= etc)?
>
> I'm a bit confused - if an entity isn't checking the to/from o= f the responses, then sure there's a slew of attacks possible. If it *a= lso* has predictable ids, then the attacks are easier - but they're the= same attacks. Aren't they?

The least far-fetched scenario I can think of: you're offering a = file transfer
to someone's MUC room nick. The person disconnects, someone else takes = their
nick and intercepts the file transfer by guessing the 'id' that was= used. This
is also a scenario where a per-address counter will not protect you. (Thoug= h a
better fix is probably to cancel all pending queries to participants when y= ou
see them disappear from the room...)


Ah! Nice one.

FWIW, it's possible to hide a offline/online eve= nt by DOSsing the original server then spoofing it, which is hard work but = practical given DNS spoofed dialback.

Also, there's a bunch of MUC-replacement attacks, I= suspect, that don't involve having to predict a stanza id.
= =A0
> I'm not saying that we shouldn't generally recommend unpredict= able ids - it seems relatively simple and causes little harm - but cryptogr= aphically secure ones seems overkill, and I'm always nervous of imposin= g unneeded drains on the entropy store of a system.
>
> Also, I've mentioned this elsewhere, but I'll mention it here = too: much of the XMPP community seems focussed on clients exhibiting this c= lass of bug, and attacks against those clients. I strongly suspect that not= all servers are immune to this, and the attacks on servers are likely to b= e just as fascinating.

I'm trying to think of a situation where the server sends a iq &#= 39;get' to the
client, but I don't really know any. A lot of iq 'set's, where = the server
informs the client of something (and probably doesn't really care wheth= er that
results in an 'error' or 'result'), but nothing where the s= erver wants to know
something from the client. Could you give an example?


As Waqas says, there's a bunch of cases. It gets= worse if the server is running optimization-related intercepts, such as di= sco caching, I suspect. I think there are interesting cases around an XMPP-= level file-transfer proxy (for anti-virus, or SI/Jingle translation) for ex= ample.

I'd hope Kev's example is way off, though - I s= uspect that servers ignore the XEP-0199 reply stanza and just look for acti= vity on the socket.

Dave.
--001a1136286025ef8704f1fe43a1-- From k.i.smith@gmail.com Sun Feb 9 14:04:38 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB521A0605 for ; Sun, 9 Feb 2014 14:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93QbA7pmay25 for ; Sun, 9 Feb 2014 14:04:37 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A322F1A04DC for ; Sun, 9 Feb 2014 14:04:37 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so4299011vcb.11 for ; Sun, 09 Feb 2014 14:04:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ugZONZ05nQS8V8xCpaioVTghsxA4pI8hhXzc/4TEEhc=; b=ftPe5td1ynsz+K80zMJA7jxQHS7zXK61r8DTkowLyIn1lHwlf4F4Op8jIAbJ5axix4 380PqCZaRbvDxos2zhx4X0mZEWYWmt+DUj81Ai3QdhZjiiQFevBN4RbSgnooYV/j7dIQ AJL6Vw932sh5sWYxFgRmaMQV4pK87NOWapxu6cUbls/xHsB/WgOsKoJOX4Pe9FUm6vwA q9qnV5Plg4XHKpIv5rAXxj6z/RGDK77IF1Z7DWkuaOjMIFLyTw72YgJuqssAquYrFKEk 7nq5V27/Tl2xecxNRetRUSU3LbzWeQK4hR1TMIBJn3UIEcpEiugcN8HBv1sF+/AcsheG 8epQ== MIME-Version: 1.0 X-Received: by 10.58.161.227 with SMTP id xv3mr623361veb.31.1391983477578; Sun, 09 Feb 2014 14:04:37 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.52.245.134 with HTTP; Sun, 9 Feb 2014 14:04:37 -0800 (PST) In-Reply-To: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> Date: Sun, 9 Feb 2014 22:04:37 +0000 X-Google-Sender-Auth: NZvjR-UmRDej9SwZowxXP8ZU1GM Message-ID: From: Kevin Smith To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Feb 2014 22:04:39 -0000 On Sun, Feb 9, 2014 at 7:30 PM, Dave Cridland wrote: > I'd hope Kev's example is way off, though - I suspect that servers ignore > the XEP-0199 reply stanza and just look for activity on the socket. I would hope so, too - but given some of the things we've seen on the client side in the last couple of weeks, I don't think it's unreasonable to suspect there might be servers with as severe problems. Whether we can find the vulnerabilities or not, though, doesn't reduce the need to document the issues, I think. /K From thijs@xnyhps.nl Mon Feb 10 04:12:44 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4541A05E0 for ; Mon, 10 Feb 2014 04:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvpuvm2NBw0w for ; Mon, 10 Feb 2014 04:12:43 -0800 (PST) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0DF1A080C for ; Mon, 10 Feb 2014 04:12:42 -0800 (PST) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 05C1E20A55; Mon, 10 Feb 2014 13:12:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1392034355; bh=4cxTbUTNC/P/vK4OqDRHFjgyEBswMcc4yO2T9V/h4bI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bC2fZYChnw1HsCdX5h6DLmja4DjkmA+kIiSmfvWGr3XbaQN67+BL3snj2vRWzg6w1 uluSMQl8C63QbZuCy85d1Tv6ATAHyxMaxmnKYAjZIpu8oghl1mU8FNpJDJ4s/eSpG3 /QNGMpuaeCnPXOKIk7gVqeL3wp7k9CF+Bc5hBTPY= Content-Type: multipart/signed; boundary="Apple-Mail=_52086BFC-825E-434A-B45B-E039D362D5E3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thijs Alkemade In-Reply-To: Date: Mon, 10 Feb 2014 13:12:27 +0100 Message-Id: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> To: kevin@kismith.co.uk X-Mailer: Apple Mail (2.1827) Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 12:12:44 -0000 --Apple-Mail=_52086BFC-825E-434A-B45B-E039D362D5E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 9 feb. 2014, at 23:04, Kevin Smith wrote: > On Sun, Feb 9, 2014 at 7:30 PM, Dave Cridland = wrote: >> I'd hope Kev's example is way off, though - I suspect that servers = ignore >> the XEP-0199 reply stanza and just look for activity on the socket. >=20 > I would hope so, too - but given some of the things we've seen on the > client side in the last couple of weeks, I don't think it's > unreasonable to suspect there might be servers with as severe > problems. Whether we can find the vulnerabilities or not, though, > doesn't reduce the need to document the issues, I think. >=20 > /K I=92ve submitted an I-D about this issue here, to help discussion at = IETF 89: http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/ Regards, Thijs --Apple-Mail=_52086BFC-825E-434A-B45B-E039D362D5E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS+MIrAAoJELRGwhIrI4PElKwP/1GeUVgS8ISsJ5FVW+UeyIpk a6oFuGE4ThmjQVU0jA1WPkj02hGHCO/sxJEd9Rw/9CwUYjfVLnCKvEtMPs8Pjnv7 QpoUwWNwQ5r4RSlsI5GaRsWGhYdrfDYr5x270XYYAAthcgrGKEgJS9WlMLSF45yu 1MWGCkji2fwh2eERBG8An8qReJ41G0AEn4aOOqQN95jCM/U9D+P31IEckGCfu7og PYj9eBizSgHA6Aunznm0HNogLnDNCC9dN8SVxvB4/bHDR4Df9khfpO/ws7ik3iUu JKsucJmrFH8shN6chegw2O7FRXEn51WhahmAWFlQ7oPewgVYDwGvduIUFWTE7/gw PEe7/s2+GUuN/QzW8c0GuMr8fO6cXTmwyAq7T2fsCm9NQHXVPCHLQJRua024c1O9 xYK+hlLXtZzjCDXYvQpgudB1Txzdff2ungbNAwlSi5GhJ9mffk0eFlaH9W+X/qkA RmWtpqhSOIUteEg6OtIVLpEbDFk7/KoZBtSbXihgp8D3Cfuv76lZt/8ivOK7hATD oSFM5ofFlN7dx2nC7Gt9IoJnJiU8tq111rXAU/ysUdIyPkEdSfxGh86R0Sw2KgYY FSPrS0uD7gh6uhwwGPZunkFE1WZbdx1ANAaa65nCB2a3VkEi0yFa2ZUozX6Hu1CI Djc8rN/AjbIBXY5d5ng6 =R5Lr -----END PGP SIGNATURE----- --Apple-Mail=_52086BFC-825E-434A-B45B-E039D362D5E3-- From ashley.ward@surevine.com Mon Feb 10 05:05:32 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB82C1A0831 for ; Mon, 10 Feb 2014 05:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkJopb_Y7GMu for ; Mon, 10 Feb 2014 05:05:31 -0800 (PST) Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by ietfa.amsl.com (Postfix) with ESMTP id DB1681A0033 for ; Mon, 10 Feb 2014 05:05:30 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so2526879wgh.2 for ; Mon, 10 Feb 2014 05:05:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=52rSTaPq3WDtycbDLg+0liWE5rjqqhy0aipGf1vD818=; b=D08Yoq9EEuFgbTSw1M87TR7KZ6LTlBm31EIQIxW3Nmks9Jn9anaL3CQXB55FhCLHl5 e8RebIWVXqpy8piN55dZ1zL+8Xy+DoZD06Sl6EOcwy1qNQJXAW8nEj8gDtJE7E5FjcSj UKgQC33eZ3lnW4V4keCYT9sDVBZcJWgysjrTLLA8ICDO/r4OW2CQlgL/Tt3PeUJociDD F2HSamxlLVvQksFKvSE5K8yaOOJ/tgDdT8XsHrmZhRmhraGyvJUz42Qij/0s1NYGjZLQ ZYVsAKAfdtEWZFy/DQq1Zoy1x6bfROd/VkeCjpBCvX6wzDl9WxnTAWgc/A4QAVcqvCVn AgMA== X-Gm-Message-State: ALoCoQnMjuBeXacL8ztCgpauWqZCgaxH/mtrPZao0CxJTfx3CTr0PtcSijDwyt4rUc1dM36k58ng X-Received: by 10.180.7.227 with SMTP id m3mr10211272wia.59.1392037530018; Mon, 10 Feb 2014 05:05:30 -0800 (PST) Received: from [10.0.0.11] (host86-129-24-95.range86-129.btcentralplus.com. [86.129.24.95]) by mx.google.com with ESMTPSA id 12sm35225870wjm.10.2014.02.10.05.05.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 05:05:28 -0800 (PST) From: Ashley Ward Content-Type: multipart/signed; boundary="Apple-Mail=_8113C84B-D761-4E05-9731-D8D3E21A6B86"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Mon, 10 Feb 2014 13:05:26 +0000 References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> To: XMPP Working Group In-Reply-To: X-Mailer: Apple Mail (2.1827) Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 13:05:33 -0000 --Apple-Mail=_8113C84B-D761-4E05-9731-D8D3E21A6B86 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 10 Feb 2014, at 12:12, Thijs Alkemade wrote: > I=92ve submitted an I-D about this issue here, to help discussion at = IETF 89: >=20 > http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/ Just wondering if it's possible to use a stronger section title than = =93Recommendations=94, or is that standard IETF I-D heading wording? =97 Ash= --Apple-Mail=_8113C84B-D761-4E05-9731-D8D3E21A6B86 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGUTCCBTmg AwIBAgIDB4u8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwOTExMTQ1NzExWhcNMTQwOTEzMDY1ODQyWjBnMRkwFwYDVQQNExBTQTJmOEtoalJZajFlMTcz MSEwHwYDVQQDDBhhc2hsZXkud2FyZEBzdXJldmluZS5jb20xJzAlBgkqhkiG9w0BCQEWGGFzaGxl eS53YXJkQHN1cmV2aW5lLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhrR088 72GtgQEkA7wVTAnJSq88pqQMh/6vm9yBPswKf9WGP7vvbELG9QVhrBT4xy3dfwiOi6pP8uLX8IXj AySoGy/c/NYCiRszaRb69Mtbg+SC21sAnHciSomaLOvQTvH4YOwaA8MYVsLGiXqM5bOnKPCnc12o R8pJsc8e2tnFYLarOfZU0Ls/FeSjG/WYYFCvWtey8BZ8UBSGtw8LMwdAy5GC0EnDN6bzrMsTncJj HcNQP/q5h7LEN8HJOX6gGZruzVoLxjvvVUNh78ozUWipsXjT+qAIv8iewxs1yUC3/yzI2+EringM 42honZshSYEVvc+bB/D68aISgxex25cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU9whoXudvZQzZ9KfV pdmpntf7d6owHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYYXNo bGV5LndhcmRAc3VyZXZpbmUuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAgap/JvdT9yikc7GD 7d675gyrXiHoxVUJXqf62lWNLf2t/7z552zV/q20oT9i4dXg8/0l92jStU9d7KybGN/sh9/oCCkT C35lX8Ua60iFPom2OA3t+70/HXdRmMAmDYDTUkzaZwe2ZxCZVELc/4MVo6FQIhuvgwGk+i+5X65y 9n0Plbgo3qQ8FpEC3vp4H1rDY9CyxyteTafG9pKnDiqzNm8S0rVPoiWVxkNsUhbmwJU/0MEQyFG2 TY/qoVPptKAldpP15s8hL2K26Xc0X7+btoXFOibxWnNUNf/qbELdhFMffUQY3IXnLvdL/QwD/Rot mRi23JILM5rNxmqSE1V60TGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAweLvDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDAyMTAxMzA1MjdaMCMGCSqGSIb3DQEJBDEWBBQxBLF5xEW4WlZT/CEptjAz0D8n TTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAweLvDCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB4u8MA0G CSqGSIb3DQEBAQUABIIBAIX60SrRl44NK/f0OXbGhegp0rBfXmqEbTa8Dc/wxlOHzlbvE2AgKffg 8NQD4ORNzY4U8olOc3x/2YqC+cMtYOxuF+4QQa18GdTgIC8ZbpUaa9S6ijfPv6HtrXl2tc6TFR2b L2xjFQY5oRI19gdbE+WrKmlsRbDkIPFLJOczu7IUuAa569uxMgXdK6+M+DF3Ba4lqHnxJUn6ISv1 abbs3IFUB7tahymXzujiFSxPVp2TbT6FZuVVRmlK4EH4WC7H+3KUzeXs7p2SKKw+i89FXfTbxQc7 7pr+XNZRt8U8Feeddv2CfW29o65U8b2qFeZDdfqr+NU2MYrTRrqwV3QYNqIAAAAAAAA= --Apple-Mail=_8113C84B-D761-4E05-9731-D8D3E21A6B86-- From stpeter@stpeter.im Mon Feb 10 08:38:26 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5CC1A06DC for ; Mon, 10 Feb 2014 08:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n5pxWhsx0zp for ; Mon, 10 Feb 2014 08:38:24 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 57CA81A0882 for ; Mon, 10 Feb 2014 08:38:24 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BD3654032A; Mon, 10 Feb 2014 09:38:23 -0700 (MST) Message-ID: <52F9007F.3010108@stpeter.im> Date: Mon, 10 Feb 2014 09:38:23 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ashley Ward , XMPP Working Group References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:38:26 -0000 On 2/10/14, 6:05 AM, Ashley Ward wrote: > On 10 Feb 2014, at 12:12, Thijs Alkemade wrote: >> I’ve submitted an I-D about this issue here, to help discussion at IETF 89: >> >> http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/ > > Just wondering if it's possible to use a stronger section title than “Recommendations”, or is that standard IETF I-D heading wording? We can call it whatever we want. :-) Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Mon Feb 10 08:40:31 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D823E1A017E for ; Mon, 10 Feb 2014 08:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOwlypCdEtAf for ; Mon, 10 Feb 2014 08:40:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D8CB61A0409 for ; Mon, 10 Feb 2014 08:40:29 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A81554032A; Mon, 10 Feb 2014 09:40:29 -0700 (MST) Message-ID: <52F900FD.5030805@stpeter.im> Date: Mon, 10 Feb 2014 09:40:29 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thijs Alkemade , kevin@kismith.co.uk References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:40:32 -0000 On 2/10/14, 5:12 AM, Thijs Alkemade wrote: > > On 9 feb. 2014, at 23:04, Kevin Smith wrote: > >> On Sun, Feb 9, 2014 at 7:30 PM, Dave Cridland wrote: >>> I'd hope Kev's example is way off, though - I suspect that servers ignore >>> the XEP-0199 reply stanza and just look for activity on the socket. >> >> I would hope so, too - but given some of the things we've seen on the >> client side in the last couple of weeks, I don't think it's >> unreasonable to suspect there might be servers with as severe >> problems. Whether we can find the vulnerabilities or not, though, >> doesn't reduce the need to document the issues, I think. >> >> /K > > I’ve submitted an I-D about this issue here, to help discussion at IETF 89: > > http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/ Hi Thijs, The document looks good to me. I'll review it in more detail after I submit the ~10 I-Ds I need to update this week. :-) Peter -- Peter Saint-Andre https://stpeter.im/ From dave@cridland.net Mon Feb 10 08:44:03 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BF31A06E5 for ; Mon, 10 Feb 2014 08:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6GMIq4wADVO for ; Mon, 10 Feb 2014 08:44:02 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFBE1A06EE for ; Mon, 10 Feb 2014 08:44:02 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id wp4so7512553obc.30 for ; Mon, 10 Feb 2014 08:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bsksBOqjoKe561+hdIgiZRSaqPv7CYx6NguRCnzIIl4=; b=jEklwkZDLWLCS0wZtMijYwhUfOgio/jcqY+2od1VVelQQe1yUx5sZb7m+mJCLyv6e0 JeIq7U2q6R+5+tRunhMKLUqFq8W6N7EYjCi6MBUKfTzk8OZFuVQxAficG2/em2oFIIyo k6/vEM4H+O+z9hM+bUiDyzMAgQ5n+1J9i9uR4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bsksBOqjoKe561+hdIgiZRSaqPv7CYx6NguRCnzIIl4=; b=QJjq+ko4Zhv29ZpItVjEImCdjIvorEsuSnB2vHLu5Jyd1n8fCiZoCtTIie0bhNTxDu ZeuT2CXRJIfg+kL+nWFxy21mU+X4rcmcFck8DUL9PlL+mNcj2+XRUIOjtSQXVLDEw4ae UrwvzqCg6HbwRY1LBoo+IbUZBKufPPFVOnK5o2L6w+g/a9XWOi2AXYfD/9h0CIbEfiXz D2TAtbeesFbIvTddcOSPiotGpmb+shBqyK9pj9TtialcaVnhzz6imFRhpzvKChz8MaD1 21J0hGgBCUJHINYz+upIj9lN+wPTzMsOeS11vslWwrodLm14CrdOpEDnZnTymHX5UzrQ W7Zg== X-Gm-Message-State: ALoCoQkReYvKKaa6dpUE08XY5kMung1pGY9jpz4BKgwPNdMLkEfKse1bf11Zs+rkLoFnwPVI9VJW MIME-Version: 1.0 X-Received: by 10.60.103.178 with SMTP id fx18mr1195626oeb.69.1392050642059; Mon, 10 Feb 2014 08:44:02 -0800 (PST) Received: by 10.60.55.138 with HTTP; Mon, 10 Feb 2014 08:44:01 -0800 (PST) In-Reply-To: <52F900FD.5030805@stpeter.im> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> <52F900FD.5030805@stpeter.im> Date: Mon, 10 Feb 2014 16:44:01 +0000 Message-ID: From: Dave Cridland To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=089e0118409607969704f2100c57 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:44:03 -0000 --089e0118409607969704f2100c57 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 4:40 PM, Peter Saint-Andre wrote: > The document looks good to me. I'll review it in more detail after I > submit the ~10 I-Ds I need to update this week. :-) > > That's just showing off. ;-) --089e0118409607969704f2100c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 10, 2014 at 4:40 PM, Peter Saint-Andre <stpeter@stpeter.im>= ; wrote:
The document looks good to me. I'll rev= iew it in more detail after I submit the ~10 I-Ds I need to update this wee= k. :-)


=
That's just showing off. ;-)=A0
--089e0118409607969704f2100c57-- From ashley.ward@surevine.com Mon Feb 10 08:48:12 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF1281A06F1 for ; Mon, 10 Feb 2014 08:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59zDyJdb52i2 for ; Mon, 10 Feb 2014 08:48:11 -0800 (PST) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9387D1A06E5 for ; Mon, 10 Feb 2014 08:48:10 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id l18so4303056wgh.11 for ; Mon, 10 Feb 2014 08:48:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=d53A9Oj0D+6jQQf7YtwV95W9FQnvseJ1lleA1SbglSM=; b=HUJf4Ng+1JnsDZM6R3A02vUDUmCf9BB1kySNDySKPWCOj+WOJs8IhAdKiLn7s7yu8R zzPDQ5hrRuzwURbXNQ5Gpd4hwjlU0iSqO0NZpZYxG5QPkRQXwJUvGJmxqes/7PHgVaVV j+ZCOMX3d3/jxZwKYn5PvpsZ0sYsdJEekLq6djEQJugpyG5t4uA5KQL2dJjBMCU8zJXl rGoEL+XajrUBkyyg9ZwagkjyvZsHjUfXe62zYUSJRLXTBZ86ARmzvdDw/K8tTuHf8D3S icUHE414OTwr9BywTo8mUEJGZ9Pfb2ANXr2uetTfNqRUDEFo4ClVMdB5/b4zCiz97fa3 y+zg== X-Gm-Message-State: ALoCoQk1TZUEPqm6UgAG6QX+gphrsOfiuNBAWcx8Ea19PMeOxGJquAovexoi8+LDD4f+hXiygQW3 X-Received: by 10.194.192.233 with SMTP id hj9mr391231wjc.78.1392050889965; Mon, 10 Feb 2014 08:48:09 -0800 (PST) Received: from [10.0.0.11] (host86-129-24-95.range86-129.btcentralplus.com. [86.129.24.95]) by mx.google.com with ESMTPSA id r1sm38026889wia.5.2014.02.10.08.48.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 08:48:07 -0800 (PST) From: Ashley Ward Content-Type: multipart/signed; boundary="Apple-Mail=_36008790-D6A5-469C-A913-6D444D8BB7E1"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <08A4B13D-00C3-4EC7-9CE1-C6F4933B2366@surevine.com> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Date: Mon, 10 Feb 2014 16:48:05 +0000 References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> <52F9007F.3010108@stpeter.im> To: XMPP Working Group In-Reply-To: <52F9007F.3010108@stpeter.im> X-Mailer: Apple Mail (2.1827) Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:48:12 -0000 --Apple-Mail=_36008790-D6A5-469C-A913-6D444D8BB7E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 10 Feb 2014, at 16:38, Peter Saint-Andre wrote: > On 2/10/14, 6:05 AM, Ashley Ward wrote: >> On 10 Feb 2014, at 12:12, Thijs Alkemade wrote: >>> I=92ve submitted an I-D about this issue here, to help discussion at = IETF 89: >>>=20 >>> http://datatracker.ietf.org/doc/draft-alkemade-xmpp-iq-validation/ >>=20 >> Just wondering if it's possible to use a stronger section title than = =93Recommendations=94, or is that standard IETF I-D heading wording? >=20 > We can call it whatever we want. :-) Cool. The only thing I was thinking is that =93Recommendation=94 already = has a meaning in this context, but there=92s actually some important = MUSTs in there. Saying that I can=92t think of a good alternative title though! =97 Ash= --Apple-Mail=_36008790-D6A5-469C-A913-6D444D8BB7E1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGUTCCBTmg AwIBAgIDB4u8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwOTExMTQ1NzExWhcNMTQwOTEzMDY1ODQyWjBnMRkwFwYDVQQNExBTQTJmOEtoalJZajFlMTcz MSEwHwYDVQQDDBhhc2hsZXkud2FyZEBzdXJldmluZS5jb20xJzAlBgkqhkiG9w0BCQEWGGFzaGxl eS53YXJkQHN1cmV2aW5lLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhrR088 72GtgQEkA7wVTAnJSq88pqQMh/6vm9yBPswKf9WGP7vvbELG9QVhrBT4xy3dfwiOi6pP8uLX8IXj AySoGy/c/NYCiRszaRb69Mtbg+SC21sAnHciSomaLOvQTvH4YOwaA8MYVsLGiXqM5bOnKPCnc12o R8pJsc8e2tnFYLarOfZU0Ls/FeSjG/WYYFCvWtey8BZ8UBSGtw8LMwdAy5GC0EnDN6bzrMsTncJj HcNQP/q5h7LEN8HJOX6gGZruzVoLxjvvVUNh78ozUWipsXjT+qAIv8iewxs1yUC3/yzI2+EringM 42honZshSYEVvc+bB/D68aISgxex25cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU9whoXudvZQzZ9KfV pdmpntf7d6owHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYYXNo bGV5LndhcmRAc3VyZXZpbmUuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAgap/JvdT9yikc7GD 7d675gyrXiHoxVUJXqf62lWNLf2t/7z552zV/q20oT9i4dXg8/0l92jStU9d7KybGN/sh9/oCCkT C35lX8Ua60iFPom2OA3t+70/HXdRmMAmDYDTUkzaZwe2ZxCZVELc/4MVo6FQIhuvgwGk+i+5X65y 9n0Plbgo3qQ8FpEC3vp4H1rDY9CyxyteTafG9pKnDiqzNm8S0rVPoiWVxkNsUhbmwJU/0MEQyFG2 TY/qoVPptKAldpP15s8hL2K26Xc0X7+btoXFOibxWnNUNf/qbELdhFMffUQY3IXnLvdL/QwD/Rot mRi23JILM5rNxmqSE1V60TGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAweLvDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDAyMTAxNjQ4MDVaMCMGCSqGSIb3DQEJBDEWBBTn7whZMF24DcVRdTf4QBXEU7oz sDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAweLvDCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB4u8MA0G CSqGSIb3DQEBAQUABIIBAD/SzvWh6BugDSpl04kYaChJ+YutgSHwzB013HrptuNVNvSeYQbPTL/p wEbnpoTscRbvSo0Op+GlUHDXAtWnsIrFjBePbkUQmbP2bzeyI/gJMp+JWG0IVDxkt5xhSX74aaDq FiQgjMbwJoTMIeuuz0ckZXAyde9nq2+adD5Kj0WShou26odwAqqQ3+mYMIat1DzcT+IH/BS2EOUW mRMXFYfAUO6vdHh/rKuUNth0jKI9/benayoKfUY4xmDArqKAM/7jukvLF4jo9/zsUtkJb8QbjFBB Xbvd/iKalwa4XVj0EJDhV5QyiLcVTRdRvmen8McxVDJ85jZXnfs0jQRf4V8AAAAAAAA= --Apple-Mail=_36008790-D6A5-469C-A913-6D444D8BB7E1-- From stpeter@stpeter.im Mon Feb 10 08:58:16 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27731A0406 for ; Mon, 10 Feb 2014 08:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjsOEshX4VB9 for ; Mon, 10 Feb 2014 08:58:15 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 33A361A03A5 for ; Mon, 10 Feb 2014 08:58:15 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 068204032A; Mon, 10 Feb 2014 09:58:14 -0700 (MST) Message-ID: <52F90526.508@stpeter.im> Date: Mon, 10 Feb 2014 09:58:14 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Cridland References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <12420410-2615-4A32-8998-AFF19D4EF7BC@xnyhps.nl> <52F900FD.5030805@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:58:16 -0000 On 2/10/14, 9:44 AM, Dave Cridland wrote: > On Mon, Feb 10, 2014 at 4:40 PM, Peter Saint-Andre > wrote: > > The document looks good to me. I'll review it in more detail after I > submit the ~10 I-Ds I need to update this week. :-) > > > That's just showing off. ;-) That's just letting you know that my response times might be slow this week. :-) Peter From jhildebr@cisco.com Mon Feb 10 09:15:27 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9091A0840 for ; Mon, 10 Feb 2014 09:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TpRx-Oya0o1b for ; Mon, 10 Feb 2014 09:15:25 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C005B1A0105 for ; Mon, 10 Feb 2014 09:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=475; q=dns/txt; s=iport; t=1392052521; x=1393262121; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jnNUJVx3CprZ18py4shEDB7ayC2tzI36Tk7NkKb89OY=; b=epqALvpwiHnp06jNvLO+IfpNLzSRMHkd35Q6LcJSw9KWUfhretOr/ah1 ojiW0k2T6J+MPHaG7c5ebXiwza3FW/t/6sEqBNCU+WEb8cp7/45ZAw1gH 981BOgHn+yRrQU9iahsa25Gh+OG7qQlXakNH6m65WUbvnj8lNUT6dJjJ1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8HAHUI+VKtJV2b/2dsb2JhbABZgwyBBAu/PoESFnSCJgEBBDo/EAIBCDYQMiUCBAENBYgFyhsXjn0HhDgBA5grkiGDLYIq X-IronPort-AV: E=Sophos;i="4.95,818,1384300800"; d="scan'208";a="303041532" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 10 Feb 2014 17:15:20 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1AHFKaH014389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 17:15:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 11:15:20 -0600 From: "Joe Hildebrand (jhildebr)" To: "Joe Hildebrand (jhildebr)" , Dave Cridland Thread-Topic: [xmpp] IQ Handling vulnerabilities Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEAgACdaoCAAL9TgP//w6cAgACRRID//6GvV4AEt5CA Date: Mon, 10 Feb 2014 17:15:20 +0000 Message-ID: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.125.120] Content-Type: text/plain; charset="us-ascii" Content-ID: <022C52C97CC32A45BC585EBE77A67B16@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:15:27 -0000 On 2/7/14 8:13 AM, "Joe Hildebrand (jhildebr)" wrote: >I have a couple of ludicrous s2s attacks on mind, but more important I >think is doing what > >Mobile/terse. DYAC. Yes, well that was even more terse than normal. I was going to say something about generating less-guessable IDs that don't eat up much entropy. For example: start =3D sha1(crytpo_rand()) start+1 =3D sha1(start) would probably do nicely. --=20 Joe Hildebrand From thijs@xnyhps.nl Mon Feb 10 11:25:49 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1993B1A01A8 for ; Mon, 10 Feb 2014 11:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ro2neIQF8-KN for ; Mon, 10 Feb 2014 11:25:47 -0800 (PST) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCAF1A046A for ; Mon, 10 Feb 2014 11:25:47 -0800 (PST) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 1472220AEB; Mon, 10 Feb 2014 20:25:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1392060339; bh=DfVu6kJdm34kZJF0yTOFY94zpiKCWPcH7s48fUFfoQg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=E8lDaweUx1/o4l5MjQVlVrpqp3cm2GO9v/9fO7jTHadiru7SUaMliTHnYn5zTlOrC u/GE2G+kiIDKsCl0QrSJMm/G0htkLCIcngrdAPtzc7QQixZvPwsp9yxr6Vec8zCzJN aWDAFLbJqgNsEOLqIBJtqANORhiHao7pBXC95BjU= Content-Type: multipart/signed; boundary="Apple-Mail=_FB30FA60-BBE6-4B22-B687-9D9F7AD2D0D1"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thijs Alkemade In-Reply-To: Date: Mon, 10 Feb 2014 20:25:36 +0100 Message-Id: <1078DA63-EB0B-4724-A4DA-BA1B5C4FE4EC@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1827) Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:25:49 -0000 --Apple-Mail=_FB30FA60-BBE6-4B22-B687-9D9F7AD2D0D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 10 feb. 2014, at 18:15, Joe Hildebrand (jhildebr) = wrote: > On 2/7/14 8:13 AM, "Joe Hildebrand (jhildebr)" = wrote: >=20 >> I have a couple of ludicrous s2s attacks on mind, but more important = I >> think is doing what >>=20 >> Mobile/terse. DYAC. >=20 > Yes, well that was even more terse than normal. I was going to say > something about generating less-guessable IDs that don't eat up much > entropy. For example: >=20 > start =3D sha1(crytpo_rand()) > start+1 =3D sha1(start) >=20 > would probably do nicely. Uhm. Maybe this email is missing a line again, but if you use those = values as 'id's directly, they will not be unpredictable at all, as anyone who = receives an can generate the rest of the chain. However, if you make sure the 'id' values are only half the hashes, it = should be unpredictable unless an attacker is willing to spend an insane amount = of work. So: start =3D sha1(crytpo_rand()) start+1 =3D sha1(start) ... id1 =3D start[0:10] id2 =3D start+1[0:10] =85 Thijs --Apple-Mail=_FB30FA60-BBE6-4B22-B687-9D9F7AD2D0D1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS+SewAAoJELRGwhIrI4PEDt4QAMRBMkD3NN/mUck965IN83fR GsuNLActUYxxOjz3EOpNZYwfp7d/U0KeoZH+EdiyDHRmjsTRqAy8oMZ+twJ/YFq2 cW7ffCBUu+NCLy5SL/rdWS92b9RuU+p6fZLXLVgSFxeGroxK5FGCofJyHt/xtDPp 6cFr/pI+Trkm5q62pHl08XV9AJ2Zfxq8PY1KN+R8KEgEUQBjBeLUoe0McYgCTaJs 1/+xlD/MUuOFBHelAVA0rp+U65WGkCyPWWpGK0mNpaTql/nnHV6Vb6RGYnc6fQUm OvjQLE7wLJoUYzRk5IAuuj56YjyYKdXRhBWMpDElW86O5l9Ty+6x5tckrRpCHxCP k7jLeMYK5capa/rR4IH0edMsDR05vIjb30TzglR/rLabt8WcZo80kpElBAUetXGp lFZ42llrdXVdCOe8MpRUn6YnxgpmgHgflw51fSRBLsWjdXNzM+Hl+dK9Y4cWiOZ0 /T5kHvX7Iz9zwqQVHPGdqo7MoTbBQcCGphXFCwGfaOlFzW3Hfw3EeHr1MI5FUhb1 ZQ0s4AvNmwlpEJpsg+YTgjmeRk07AgAXE9G2NmjOP979awa4yjLouo/FpdbKIVdb jJULMQKe68cEatkSQvYpofJf5xaPVejEcnWq8/tGEhFT3CX6hPSHmxStcmKDEkHo TDkRg+oLdboTyDtgRTqd =Ntxy -----END PGP SIGNATURE----- --Apple-Mail=_FB30FA60-BBE6-4B22-B687-9D9F7AD2D0D1-- From thijs@xnyhps.nl Mon Feb 10 11:25:49 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202511A0433 for ; Mon, 10 Feb 2014 11:25:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmwj7hyDEKKY for ; Mon, 10 Feb 2014 11:25:47 -0800 (PST) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2A01A0450 for ; Mon, 10 Feb 2014 11:25:47 -0800 (PST) Received: from [192.168.1.11] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 5477320BF9; Mon, 10 Feb 2014 20:25:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1392060341; bh=fOCV22n7QMq4raeL1eTbxIMNfL0zY+Bcl/wNbcZPxvA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ekhT0eYv3HPIlAzroTO7SMoyBztkPhqWumG6EZVmOfDCxYWnmiQOIWvdn+AB7uGNM 7ZaHd2SB/F5Hmeq48f70OD1Jr8tN1CbbOhnrVN3dP3zpXL/FZ2W3VU6wbktbp01fbv HT1Zim3fM9o/svXIiPuiJgvWiBsSEroIqFrcohCg= Content-Type: multipart/signed; boundary="Apple-Mail=_60F60CE3-FE59-47E3-A262-69A4BB475C77"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thijs Alkemade In-Reply-To: Date: Mon, 10 Feb 2014 20:25:36 +0100 Message-Id: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> To: "Joe Hildebrand (jhildebr)" X-Mailer: Apple Mail (2.1827) Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:25:49 -0000 --Apple-Mail=_60F60CE3-FE59-47E3-A262-69A4BB475C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 10 feb. 2014, at 18:15, Joe Hildebrand (jhildebr) = wrote: > On 2/7/14 8:13 AM, "Joe Hildebrand (jhildebr)" = wrote: >=20 >> I have a couple of ludicrous s2s attacks on mind, but more important = I >> think is doing what >>=20 >> Mobile/terse. DYAC. >=20 > Yes, well that was even more terse than normal. I was going to say > something about generating less-guessable IDs that don't eat up much > entropy. For example: >=20 > start =3D sha1(crytpo_rand()) > start+1 =3D sha1(start) >=20 > would probably do nicely. Uhm. Maybe this email is missing a line again, but if you use those = values as 'id's directly, they will not be unpredictable at all, as anyone who = receives an can generate the rest of the chain. However, if you make sure the 'id' values are only half the hashes, it = should be unpredictable unless an attacker is willing to spend an insane amount = of work. So: start =3D sha1(crytpo_rand()) start+1 =3D sha1(start) ... id1 =3D start[0:10] id2 =3D start+1[0:10] =85 Thijs --Apple-Mail=_60F60CE3-FE59-47E3-A262-69A4BB475C77 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJS+SewAAoJELRGwhIrI4PEDt4QAMRBMkD3NN/mUck965IN83fR GsuNLActUYxxOjz3EOpNZYwfp7d/U0KeoZH+EdiyDHRmjsTRqAy8oMZ+twJ/YFq2 cW7ffCBUu+NCLy5SL/rdWS92b9RuU+p6fZLXLVgSFxeGroxK5FGCofJyHt/xtDPp 6cFr/pI+Trkm5q62pHl08XV9AJ2Zfxq8PY1KN+R8KEgEUQBjBeLUoe0McYgCTaJs 1/+xlD/MUuOFBHelAVA0rp+U65WGkCyPWWpGK0mNpaTql/nnHV6Vb6RGYnc6fQUm OvjQLE7wLJoUYzRk5IAuuj56YjyYKdXRhBWMpDElW86O5l9Ty+6x5tckrRpCHxCP k7jLeMYK5capa/rR4IH0edMsDR05vIjb30TzglR/rLabt8WcZo80kpElBAUetXGp lFZ42llrdXVdCOe8MpRUn6YnxgpmgHgflw51fSRBLsWjdXNzM+Hl+dK9Y4cWiOZ0 /T5kHvX7Iz9zwqQVHPGdqo7MoTbBQcCGphXFCwGfaOlFzW3Hfw3EeHr1MI5FUhb1 ZQ0s4AvNmwlpEJpsg+YTgjmeRk07AgAXE9G2NmjOP979awa4yjLouo/FpdbKIVdb jJULMQKe68cEatkSQvYpofJf5xaPVejEcnWq8/tGEhFT3CX6hPSHmxStcmKDEkHo TDkRg+oLdboTyDtgRTqd =Ntxy -----END PGP SIGNATURE----- --Apple-Mail=_60F60CE3-FE59-47E3-A262-69A4BB475C77-- From jhildebr@cisco.com Mon Feb 10 11:33:34 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B231A07EF for ; Mon, 10 Feb 2014 11:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiaqgGS9tscE for ; Mon, 10 Feb 2014 11:33:32 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id BA7171A06AF for ; Mon, 10 Feb 2014 11:33:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=772; q=dns/txt; s=iport; t=1392060812; x=1393270412; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=thsvPpBvdnFTIRTQLJLkJsYj/6AliXnVy1EgpUDP+Gc=; b=jVk+rgJNeyWsaufMO2Td/FtwRUm7mH/L6LcIuOJRCTBCuyTc92lLoX95 iFY5YrgD8A6Qs//Np85Vec4cSBJ+kiUgg6wz5T5NXSbCTKsEY80FviSQC YrtIL+kqBfYBh7tg6/a8ewxOZgNcku7wY7Zqpv51JLq4V+d6n+H4cTDT1 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAMEo+VKtJXG8/2dsb2JhbABZgwyBD79hgRUWdIImAQEEOj8QAgEINhAyJQIEDgUbh2rJPBeOGxEBUAeEOAEDmCuSIIMtgXE5 X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208";a="19353915" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-8.cisco.com with ESMTP; 10 Feb 2014 19:33:32 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1AJXWtS018284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 19:33:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 13:33:32 -0600 From: "Joe Hildebrand (jhildebr)" To: Thijs Alkemade Thread-Topic: [xmpp] IQ Handling vulnerabilities Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEAgACdaoCAAL9TgP//w6cAgACRRID//6GvV4AEt5CAgACZvwD//4zYAA== Date: Mon, 10 Feb 2014 19:33:31 +0000 Message-ID: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <1078DA63-EB0B-4724-A4DA-BA1B5C4FE4EC@xnyhps.nl> In-Reply-To: <1078DA63-EB0B-4724-A4DA-BA1B5C4FE4EC@xnyhps.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.85.69] Content-Type: text/plain; charset="us-ascii" Content-ID: <7AA134E36786244BA425C07D87DDEF64@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:33:34 -0000 On 2/10/14 12:25 PM, "Thijs Alkemade" wrote: >Uhm. Maybe this email is missing a line again, but if you use those >values as >'id's directly, they will not be unpredictable at all, as anyone who >receives >an can generate the rest of the chain. > >However, if you make sure the 'id' values are only half the hashes, it >should >be unpredictable unless an attacker is willing to spend an insane amount >of >work. > >So: > >start =3D sha1(crytpo_rand()) >start+1 =3D sha1(start) >... > >id1 =3D start[0:10] >id2 =3D start+1[0:10] Or add a nonce to each round: nonce =3D crytpo_rand() start =3D sha1(nonce + crytpo_rand()) start+1 =3D sha1(nonce + start) Regardless, there exist solutions. --=20 Joe Hildebrand From dave@cridland.net Mon Feb 10 12:22:26 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67931A046A for ; Mon, 10 Feb 2014 12:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJ-Ofl_XdNpe for ; Mon, 10 Feb 2014 12:22:25 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9051A047C for ; Mon, 10 Feb 2014 12:22:23 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wp18so7814777obc.36 for ; Mon, 10 Feb 2014 12:22:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zUjqFfRFunXVFQEEpolYJicoeKnUNX8YJ582KhjPXtk=; b=Kq1hpH3GhR66OUjlj8nb2e7PVtMgzfgX/G9o+gkdLg4m3NALW0MwMcAF2EvCaJZIQk ZTfNgXi5Y5tqWNS+6ZXH1UZAvMPRV8RKln4n9zKTKA+vt0oUsx6cF07Gqqq5+n3LkXo4 Nj+tq6YJX+Oyn59ysTHBELYl6LjB8sNQ4M8zs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zUjqFfRFunXVFQEEpolYJicoeKnUNX8YJ582KhjPXtk=; b=LnMzm4vu5GUFoGMmTpQF9+d9eigISLZEAtBMaMrqBvYGMdwUGGA3deDVbyzyIPQ6OT 4C8Zj7EaOXxGO1qFaUlZNCiJi5k1Q8IM+QHqVPPzdAbtltMkA+4M69M0XPMkr/yq5g2e d4bKZOOyQO1IZ88YgQSh5hVDQ0CXTY9EVyP7Okqk+Ae674ZWSl2fsuN0CUDWmBAe2PF9 4sD2lxZwBhH5w5n8CNs0R26QG7qFo/98pl6En9TDnwnzeH2bc52tFHfc0ExZ5/G+OhAR RryZ5E9ELumtLwSTFUHD6l3ia+tBGgjspGpPWGUTwD7hlE9RhjLuy/nA0TDquZ8KUmZR Yv+Q== X-Gm-Message-State: ALoCoQkCksCiBrlOIpvzmOea8HRL52g19WrzEYlm6rsZMzGmdAotT/EuqVTcO1Lk30OXeM/VR7sI MIME-Version: 1.0 X-Received: by 10.60.134.200 with SMTP id pm8mr8263487oeb.40.1392063743008; Mon, 10 Feb 2014 12:22:23 -0800 (PST) Received: by 10.60.55.138 with HTTP; Mon, 10 Feb 2014 12:22:22 -0800 (PST) In-Reply-To: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <1078DA63-EB0B-4724-A4DA-BA1B5C4FE4EC@xnyhps.nl> Date: Mon, 10 Feb 2014 20:22:22 +0000 Message-ID: From: Dave Cridland To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=047d7b417831e8919504f213184b Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:22:27 -0000 --047d7b417831e8919504f213184b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 7:33 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > Or add a nonce to each round: > > nonce = crytpo_rand() > start = sha1(nonce + crytpo_rand()) > start+1 = sha1(nonce + start) > > Regardless, there exist solutions. > At the risk of diving into what's quite clearly a bit of a bikeshed at this point... I wondered whether there's value in going a step further. What if an entity constructed ids based on a random per-session key, the original "to" value, and a suitable salt (which itself need not be cryptographically random), such that the id was the salt followed by a (truncated, probably) HMAC result as follows: id = salt + hmac(salt + to, session-key)[0:10] That way, on receipt of such an id in an iq response or error, the sender could validate the id somewhat securely? I suspect a single session-key is a little simplistic; but that's easy to adapt. The advantage here isn't really in the case we've been mostly discussing, but the other cases of a returned id - since we don't want to track outbound directed presence, or message, ids for an arbitrary length of time. (I assume). Dave. --047d7b417831e8919504f213184b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 10, 2014 at 7:33 PM, Joe Hildebrand (jhildebr) &l= t;jhildebr@cisco.co= m> wrote:
Or add a nonce to each round= :

nonce =3D crytpo_rand()
start =3D sha1(nonce + crytpo_rand())
start+1 =3D sha1(nonce + start)

Regardless, there exist solutions.

At t= he risk of diving into what's quite clearly a bit of a bikeshed at this= point...

I wondered whether there's value in = going a step further. What if an entity constructed ids based on a random p= er-session key, the original "to" value, and a suitable salt (whi= ch itself need not be cryptographically random), such that the id was the s= alt followed by a (truncated, probably) HMAC result as follows:

id =3D salt + hmac(salt + to, session-key)[0:10]
<= div>
That way, on receipt of such an id in an iq response or = error, the sender could validate the id somewhat securely?

I suspect a single session-key is a little simplistic; but that&= #39;s easy to adapt.

The advantage here isn't = really in the <iq/> case we've been mostly discussing, but the ot= her cases of a returned id - since we don't want to track outbound dire= cted presence, or message, ids for an arbitrary length of time. (I assume).=

Dave.
--047d7b417831e8919504f213184b-- From dave@cridland.net Mon Feb 10 12:56:30 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D231A0869 for ; Mon, 10 Feb 2014 12:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF_eOZPwZFoV for ; Mon, 10 Feb 2014 12:56:29 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CE6531A0836 for ; Mon, 10 Feb 2014 12:56:28 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wo20so7814178obc.24 for ; Mon, 10 Feb 2014 12:56:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xVZuyJbOLeRb0xL7U2K2zJlPNIAEHHVFUpwbaAiW5pM=; b=jG67kLIpqMprxRmemRg9gtN1c3xsuRCJ5WPUaflissAhPhiy4Xx39bP6dzCnQu2uv4 nkDzYZ8BEdmudZdsFxV2hmHGlWs+sGsV5X/XDRlgqg+zhuNLFpBdn1RtaDg4HwCEUlGR mESs7jmocEiX+/j7LlPUsfIdoXr6fS0DcIhNo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xVZuyJbOLeRb0xL7U2K2zJlPNIAEHHVFUpwbaAiW5pM=; b=G73aFSjTfLsnTe51bP2R0R5DuUDl1znkGEkFm9Ot6KohnA6e9B1DECTswd/3Rn+z8q 1hzVGyXxeEXo3pu7HxAYub5Fb9RKHieVNA0H2D7Lh2gRP1vtfJCqtI/paPbMzBku4/B1 lC7yT9ULF3ZDvJkqsRRHlcmO739A6/FSltdvkAIuSxcK/BlvqAvCzU5VXASrInHY292n DvCxI5QMDj8IyIUV6x/Ve9C9TWv4ygqJeEjq9ZSN+B/ksVeJUqbR7YCWFjCtpY0DbniD bjWDxUluQIva8sG1EMjeBEeOo0wxHPnPESC5nWO+oGm3TnePBUwo71Pmzv+blp5uvhiA qbVA== X-Gm-Message-State: ALoCoQnGzT30AJE99qTKqWAQSiKL++RA1Yf16fDwqFFqdZbDXvtFICSld7X1/KT4VAOvn4C7bDWd MIME-Version: 1.0 X-Received: by 10.182.232.4 with SMTP id tk4mr29255679obc.9.1392065788278; Mon, 10 Feb 2014 12:56:28 -0800 (PST) Received: by 10.60.55.138 with HTTP; Mon, 10 Feb 2014 12:56:28 -0800 (PST) In-Reply-To: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <1078DA63-EB0B-4724-A4DA-BA1B5C4FE4EC@xnyhps.nl> Date: Mon, 10 Feb 2014 20:56:28 +0000 Message-ID: From: Dave Cridland To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=f46d0445178fd11acf04f2139263 Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:56:30 -0000 --f46d0445178fd11acf04f2139263 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 10, 2014 at 8:22 PM, Dave Cridland wrote: > The advantage here isn't really in the case we've been mostly > discussing, but the other cases of a returned id - since we don't want to > track outbound directed presence, or message, ids for an arbitrary length > of time. (I assume). > > Just to summarize a chat I had with Joe on this; neither of us can immediately think of any attack based on bounced presence or message, but no doubt Thijs will ruin my complacency. There's no need, even if such an attack exists, to actually mandate a particular format or generation strategy, of course - there's no interop need here - but a recommendation along the lines of XEP-0185 might be useful. Dave. --f46d0445178fd11acf04f2139263 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --f46d0445178fd11acf04f2139263-- From holler@ahsoftware.de Tue Feb 11 04:24:08 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6B41A081F for ; Tue, 11 Feb 2014 04:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dmESqtrXAZIS for ; Tue, 11 Feb 2014 04:24:06 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id D275B1A0281 for ; Tue, 11 Feb 2014 04:24:05 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id C1E32423C2E6; Tue, 11 Feb 2014 13:24:02 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 98BE9423C2BC for ; Tue, 11 Feb 2014 13:24:01 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 252A87FA1B; Tue, 11 Feb 2014 13:24:00 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id 0FB597F82C; Tue, 11 Feb 2014 12:23:56 +0000 (UTC) Message-ID: <52FA165B.8050901@ahsoftware.de> Date: Tue, 11 Feb 2014 13:23:55 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thijs Alkemade , "Joe Hildebrand (jhildebr)" References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 12:24:09 -0000 Am 10.02.2014 20:25, schrieb Thijs Alkemade: > > On 10 feb. 2014, at 18:15, Joe Hildebrand (jhildebr) wrote: > >> On 2/7/14 8:13 AM, "Joe Hildebrand (jhildebr)" wr= ote: >> >>> I have a couple of ludicrous s2s attacks on mind, but more important = I >>> think is doing what >>> >>> Mobile/terse. DYAC. >> >> Yes, well that was even more terse than normal. I was going to say >> something about generating less-guessable IDs that don't eat up much >> entropy. For example: >> >> start =3D sha1(crytpo_rand()) >> start+1 =3D sha1(start) >> >> would probably do nicely. > > Uhm. Maybe this email is missing a line again, but if you use those val= ues as > 'id's directly, they will not be unpredictable at all, as anyone who re= ceives > an can generate the rest of the chain. > > However, if you make sure the 'id' values are only half the hashes, it = should > be unpredictable unless an attacker is willing to spend an insane amoun= t of > work. > > So: > > start =3D sha1(crytpo_rand()) > start+1 =3D sha1(start) > ... > > id1 =3D start[0:10] > id2 =3D start+1[0:10] > =E2=80=A6 Hmm, in all these mails it was never be mentioned that IDs still have to = be unique over some time for one session. I'm not sure if such is given=20 with the above constructs. It might be very unlikely that the same ID=20 will appear twice, but someone has to take a deeper look at it when=20 using such constructs like above. Of course, in reality the window in=20 time IDs must be unique is rather small, but ... Regards, Alexander Holler From dave@cridland.net Tue Feb 11 04:29:45 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728E61A0381 for ; Tue, 11 Feb 2014 04:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6IZN_IaMLZr for ; Tue, 11 Feb 2014 04:29:44 -0800 (PST) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id EB7051A0281 for ; Tue, 11 Feb 2014 04:29:43 -0800 (PST) Received: by mail-oa0-f48.google.com with SMTP id l6so9049342oag.35 for ; Tue, 11 Feb 2014 04:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zanoJCLXFZSVa5D0soaoFjj4qlxfVXbJ2+gv/42Yht0=; b=QBFH4qk1+fwMhN9V7saFUpfPXKg1cBCKY87Xv0RH54lj/ZTQVMvtOeZ01VCEzm2f5j 1wQTXoLgwS+jQzk6zKzBrsXaR3EAjlVl7OhYrw7Ay4vdAFfTBLKRiNt/Y3L1VebZ9Txp KGr/asYQgWc98LOVXojr6qDrZe5mbzfNhNVqQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zanoJCLXFZSVa5D0soaoFjj4qlxfVXbJ2+gv/42Yht0=; b=S5TT8sPfsBj/d93QRkhiB04/TRaI7PVU7hHSkPC+DowwuMKUAm+j97hnQOQnSjFSJH 6wW23ccnIq0sJnwzdtFAx+fVYV/TPoCZF2YMSKQX96pS/7ZXLne4ntexN6mgGihIT4XP MNvBlJ4/M5++nkX7XmYd3nBMZE9P15tHoENMzQooByYWtRvPNhmj6dcyv72NcrmLkjbL yCzVvEp9lXnWYWOflrzzj9dBI+b7qMMqiRBaW/kNBtI6bp8LROtZ1/KGFICNu7qgm+Om bGcKDFOdTqTV2neHV3EMRCQarzagZ+OK4c6eOC0RWnfEKET+4RLPdpOktuLM8sGw8tQq YPSQ== X-Gm-Message-State: ALoCoQlzqIQVAeGuRWuw7hTcrCF0YucnwnbG5RSfunGIiS+UpgydHg78sTKjwjM19M/XvTFv51Sa MIME-Version: 1.0 X-Received: by 10.60.142.166 with SMTP id rx6mr518714oeb.57.1392121783124; Tue, 11 Feb 2014 04:29:43 -0800 (PST) Received: by 10.60.55.197 with HTTP; Tue, 11 Feb 2014 04:29:42 -0800 (PST) In-Reply-To: <52FA165B.8050901@ahsoftware.de> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> Date: Tue, 11 Feb 2014 12:29:42 +0000 Message-ID: From: Dave Cridland To: Alexander Holler Content-Type: multipart/alternative; boundary=047d7b2e0b295e1a3404f2209cb1 Cc: XMPP Working Group , Ben Campbell Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 12:29:45 -0000 --047d7b2e0b295e1a3404f2209cb1 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler wrote: > Hmm, in all these mails it was never be mentioned that IDs still have to > be unique over some time for one session. I'm not sure if such is given > with the above constructs. It might be very unlikely that the same ID will > appear twice, but someone has to take a deeper look at it when using such > constructs like above. Of course, in reality the window in time IDs must be > unique is rather small, but ... > You'd need random collisions amongst cryptographically secure hashes. You're pretty safe. In practise, ids do not have to be unique anyway, even over a small window. Most MUC implementations preserve ids on broadcast, for instance, to no ill-effect. Dave. --047d7b2e0b295e1a3404f2209cb1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 11, 2014 at 12:23 PM, Alexander Holler <holler@ahsoftware.de> wrote:
Hmm, in all these mails it was never be ment= ioned that IDs still have to be unique over some time for one session. I= 9;m not sure if such is given with the above constructs. It might be very u= nlikely that the same ID will appear twice, but someone has to take a deepe= r look at it when using such constructs like above. Of course, in reality t= he window in time IDs must be unique is rather small, but ...

You'd need random collisions amongst c= ryptographically secure hashes. You're pretty safe.

In practise, ids do not have to be unique anyway, even over a small w= indow. Most MUC implementations preserve ids on broadcast, for instance, to= no ill-effect.

Dave.
--047d7b2e0b295e1a3404f2209cb1-- From holler@ahsoftware.de Tue Feb 11 07:15:06 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B911A01A8 for ; Tue, 11 Feb 2014 07:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE5HIA-pl16Q for ; Tue, 11 Feb 2014 07:15:05 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id DC4A91A0376 for ; Tue, 11 Feb 2014 07:15:03 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id B2036423C2E3; Tue, 11 Feb 2014 16:15:02 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 7A81D423C2E2 for ; Tue, 11 Feb 2014 16:14:57 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 2B4417FA1B; Tue, 11 Feb 2014 16:14:56 +0100 (CET) Received: from [IPv6:feeb::c685:8ff:fe12:175d] (unknown [IPv6:feeb::c685:8ff:fe12:175d]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by eiche.ahsoftware (Postfix) with ESMTPS id C23DC7F829; Tue, 11 Feb 2014 15:14:37 +0000 (UTC) Message-ID: <52FA3E53.3060009@ahsoftware.de> Date: Tue, 11 Feb 2014 16:14:27 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Cridland References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group , Ben Campbell Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:15:06 -0000 Am 11.02.2014 13:29, schrieb Dave Cridland: > On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler wrote: > >> Hmm, in all these mails it was never be mentioned that IDs still have to >> be unique over some time for one session. I'm not sure if such is given >> with the above constructs. It might be very unlikely that the same ID will >> appear twice, but someone has to take a deeper look at it when using such >> constructs like above. Of course, in reality the window in time IDs must be >> unique is rather small, but ... >> > > You'd need random collisions amongst cryptographically secure hashes. > You're pretty safe. I don't aggree. You are safe if you use the hash as intendend, but not if you just use some part of the hash(-number) or hashes of hashes. I'm not sure about how safe it is (in regard to collisions) if you look at consequent hashes of hashes. I would assume that is not what cryptographers do look for (primarily). At least I can't remember to have seen some discussion if the series of hash(hash(hash(...))) is collision free (that is imho quiet different than hash(random); hash(random)). Of course, I'm not looking that often at cryptographic papers, I usually prefer if cryptographers do such. ;) > In practise, ids do not have to be unique anyway, even over a small window. > Most MUC implementations preserve ids on broadcast, for instance, to no > ill-effect. How do you track responses if you don't have unique IDs? Unique IDs might not be necessary for everything, but usually you are unable to match a response to a request without having unique IDs in consequent requests (of the same session). Regards, Alexander Holler From thijs@xnyhps.nl Tue Feb 11 07:31:54 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC521A0564 for ; Tue, 11 Feb 2014 07:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, LOTS_OF_MONEY=0.001, RP_MATCHES_RCVD=-0.548] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWGgSvdhSMlm for ; Tue, 11 Feb 2014 07:31:52 -0800 (PST) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id BEDEF1A05E0 for ; Tue, 11 Feb 2014 07:31:51 -0800 (PST) Received: from [192.168.1.4] (196pc201.sshunet.nl [145.97.201.196]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by s.xnyhps.nl (Postfix) with ESMTPSA id 2093C247FD; Tue, 11 Feb 2014 16:31:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1392132701; bh=xOwuL2olihdo6N1z4F341UvH1MkMs5RBjvIOvqIY098=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Psw7MUHFqr3Nw4CoSRZGs+wkpoumnHNhXZgvtUPGty+XyegrHasP/YkI2c6SP/xVa l3z7bBLs0ltKJqRvtgPv+lWNPn3aLlQc+oO2aTzHvS+L3cL62wu+Cj3q/mI7W0d/Jv wkXSh5Cjdf10NKDayrO0Q+Yd6LVfyBVgnr/y85hE= Content-Type: multipart/signed; boundary="Apple-Mail=_D329E652-F036-4921-B5DF-FAD94442C96F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Thijs Alkemade In-Reply-To: <52FA3E53.3060009@ahsoftware.de> Date: Tue, 11 Feb 2014 16:33:26 +0100 Message-Id: <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> To: Alexander Holler X-Mailer: Apple Mail (2.1827) Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 15:31:54 -0000 --Apple-Mail=_D329E652-F036-4921-B5DF-FAD94442C96F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 11 feb. 2014, at 16:14, Alexander Holler = wrote: > Am 11.02.2014 13:29, schrieb Dave Cridland: >> On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler = wrote: >>=20 >>> Hmm, in all these mails it was never be mentioned that IDs still = have to >>> be unique over some time for one session. I'm not sure if such is = given >>> with the above constructs. It might be very unlikely that the same = ID will >>> appear twice, but someone has to take a deeper look at it when using = such >>> constructs like above. Of course, in reality the window in time IDs = must be >>> unique is rather small, but ... >>>=20 >>=20 >> You'd need random collisions amongst cryptographically secure hashes. >> You're pretty safe. >=20 > I don't aggree. You are safe if you use the hash as intendend, but not > if you just use some part of the hash(-number) or hashes of hashes. = I'm > not sure about how safe it is (in regard to collisions) if you look at > consequent hashes of hashes. I would assume that is not what > cryptographers do look for (primarily). >=20 > At least I can't remember to have seen some discussion if the series = of > hash(hash(hash(...))) is collision free (that is imho quiet different > than hash(random); hash(random)). Of course, I'm not looking that = often > at cryptographic papers, I usually prefer if cryptographers do such. = ;) You're not going to stumble upon a SHA-1 collision by accident. Even if = you do "hashes of hashes". The esitmated cost of an intentional SHA-1 collision = is still at least $1M: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html If you do happen to find one, congratulations, you are now famous. = Nobody has published a SHA-1 collision yet. Collisions in 'id's is also not very relevant. In any XMPP client, there = will be a finite list of 'id's for which it still expects a reply = (outstanding queries, unacked messages). Checking against each of those is trivial. Thijs --Apple-Mail=_D329E652-F036-4921-B5DF-FAD94442C96F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJS+kLTAAoJELRGwhIrI4PErykQAKwWkyGfO6TmyB3rD9dF0KBx Qgod0w+/p7TB27XrYRMcS7hVmbVADEB1pYMEZ7O/Ay69yFxGygABbnSrnaSjViWs hLq1rNZfiEjm7/kC9J4HAO0Syzshe9I9HbPfZ/wSPUDCc/d1iNGAax3D3KBSmAfI 9FQtwRAAKYw81lwCkljGdck5W2e2yQyJtbeaCBEpMDRjXrPboN/tmfoYBw9BT/gG ECzZ+sGtTHMK0N0oAcP+UAO02gqnFl4yZ2v7flS0Jo/srKXdbxrl4wqJ9+Bw/0C9 KFHwbaN021D7lvBXmiFdROqwP0jM9yNDM8/v0kKBrWx8b6vy7K99wjR2Ki5qc/VY iWYozYwzt3oGHwR4Xma4nDNS1LplA+4FSBkinb7vWiyli4A/+H7z3aY+1D0vft6d 8op8HK6MuHxf4D+UPmzTSdmrbO7ADaXngC3uROA6SWvI3Devg2cJUm6LN5qSw3jz Y9DN1WjWRr6yd6OChZ2Rx6l14Y92avhKTGv1mqzcehbxeRy/BwVWJ3CvzmTPvTAS NJ9LXrMMXlQTEWJ5vaztQ5uK2fxf1B2x02AMQLe+bqdoBNDSpfQ2RLKPxejMTir/ CHlpp1WExFlCfqQHyT2tJMqF/tofiU3ief/r07SY+w0xsnGW5UjStpsiouMXXUMx 7fyq2tScY/xzkdyyhgj2 =Ku0r -----END PGP SIGNATURE----- --Apple-Mail=_D329E652-F036-4921-B5DF-FAD94442C96F-- From holler@ahsoftware.de Tue Feb 11 08:18:05 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2891A01A8 for ; Tue, 11 Feb 2014 08:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seYZnaJhNAze for ; Tue, 11 Feb 2014 08:17:59 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 269E01A061F for ; Tue, 11 Feb 2014 08:17:58 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 00478423C2A9; Tue, 11 Feb 2014 17:17:56 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id D31E8423C256 for ; Tue, 11 Feb 2014 17:17:50 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 63AD47F82C; Tue, 11 Feb 2014 17:17:38 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id 76C4E7FA1B; Tue, 11 Feb 2014 16:17:06 +0000 (UTC) Message-ID: <52FA4D02.5050907@ahsoftware.de> Date: Tue, 11 Feb 2014 17:17:06 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thijs Alkemade References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> In-Reply-To: <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:18:06 -0000 Am 11.02.2014 16:33, schrieb Thijs Alkemade: > > On 11 feb. 2014, at 16:14, Alexander Holler wrote: > >> Am 11.02.2014 13:29, schrieb Dave Cridland: >>> On Tue, Feb 11, 2014 at 12:23 PM, Alexander Holler wrote: >>> >>>> Hmm, in all these mails it was never be mentioned that IDs still have to >>>> be unique over some time for one session. I'm not sure if such is given >>>> with the above constructs. It might be very unlikely that the same ID will >>>> appear twice, but someone has to take a deeper look at it when using such >>>> constructs like above. Of course, in reality the window in time IDs must be >>>> unique is rather small, but ... >>>> >>> >>> You'd need random collisions amongst cryptographically secure hashes. >>> You're pretty safe. >> >> I don't aggree. You are safe if you use the hash as intendend, but not >> if you just use some part of the hash(-number) or hashes of hashes. I'm >> not sure about how safe it is (in regard to collisions) if you look at >> consequent hashes of hashes. I would assume that is not what >> cryptographers do look for (primarily). >> >> At least I can't remember to have seen some discussion if the series of >> hash(hash(hash(...))) is collision free (that is imho quiet different >> than hash(random); hash(random)). Of course, I'm not looking that often >> at cryptographic papers, I usually prefer if cryptographers do such. ;) > > You're not going to stumble upon a SHA-1 collision by accident. Even if you do > "hashes of hashes". The esitmated cost of an intentional SHA-1 collision is > still at least $1M: > https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html > > If you do happen to find one, congratulations, you are now famous. Nobody has > published a SHA-1 collision yet. Sorry, but you haven't understood what I've written. Alexander Holler From holler@ahsoftware.de Tue Feb 11 08:32:02 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3DA1A0635 for ; Tue, 11 Feb 2014 08:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, LOTS_OF_MONEY=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEkau98rVt69 for ; Tue, 11 Feb 2014 08:32:00 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2024F1A061A for ; Tue, 11 Feb 2014 08:31:56 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 35142423C2F6; Tue, 11 Feb 2014 17:31:55 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 2F83F423C2F4 for ; Tue, 11 Feb 2014 17:31:54 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 87B5A80502; Tue, 11 Feb 2014 17:31:47 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id 356E37FA1B; Tue, 11 Feb 2014 16:31:31 +0000 (UTC) Message-ID: <52FA5060.9040303@ahsoftware.de> Date: Tue, 11 Feb 2014 17:31:28 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Thijs Alkemade References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> In-Reply-To: <52FA4D02.5050907@ahsoftware.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 16:32:02 -0000 Am 11.02.2014 17:17, schrieb Alexander Holler: > Am 11.02.2014 16:33, schrieb Thijs Alkemade: >> >> You're not going to stumble upon a SHA-1 collision by accident. Even >> if you do >> "hashes of hashes". The esitmated cost of an intentional SHA-1 >> collision is >> still at least $1M: >> https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html >> >> If you do happen to find one, congratulations, you are now famous. >> Nobody has >> published a SHA-1 collision yet. > > Sorry, but you haven't understood what I've written. Just to be a bit more verbose, e.g. your proposal was to use start = sha1(crytpo_rand()) start+1 = sha1(start) ... id1 = start[0:10] id2 = start+1[0:10] which I interpret such, that, besides using a hash from hash (so no new source), the ID consists of just the first 10 characters of the 40 of a sha1. And then you argument with the collision rate of sha1? Alexander Holler From dave@cridland.net Tue Feb 11 09:06:54 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00AE1A0660 for ; Tue, 11 Feb 2014 09:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMDKxd4Le90G for ; Tue, 11 Feb 2014 09:06:52 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id BE1651A0656 for ; Tue, 11 Feb 2014 09:06:48 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so9062333obc.39 for ; Tue, 11 Feb 2014 09:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=beY3xAkkvkMMey1pQlim+VTT8JbAqSE1hfj+QjapXA0=; b=I9L5BEllT41peFSWBjtdW7JKK9g5Py7FA9xsks2d7J472tQOjhgll9yw3AdyPMAdiW hFL0QEfU0Ry7UomnxliEi1/wdiUuuk6TB1g/4rCDzhdRZp6DYdH8nyoyOUhKUP1qKmnx bAknE69ePVXi3mKJJHO2UOABE4GKEyQJLSLYE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=beY3xAkkvkMMey1pQlim+VTT8JbAqSE1hfj+QjapXA0=; b=hS6z7Upn+jJs50/5rljOHs5OwekVZj0IP/u37EhRREvc0iZDc/uljRx26vnNv33xX+ Q0XokG5vkXDOLIFytx90R/zRX0gYRZcfXQ585pBS9ThrHhV6i6JWYGhrhPDerB+ThTUK /o5jnMczyf2lERaH7vz5GJu8Ksv0N7omfiMlCjYmJhw7gyDt3XdW2KZzt/um4xfgGPLa nN6a9XdhWYhWWgPLuiZbaxC+cb35SheXBOfKZlLLwUbdPHsDzr3kG6J24r6okSUanE/u 53bmWtR9tJKmeR4hNyq1M+FCorvUebqkbS2iTNr1+tOOwlb6QupQveRfiiTs4rravmL9 TMFA== X-Gm-Message-State: ALoCoQli+ZAPUnBP1NQHrIzt4LD9QfHzI4ntDsuMQvKrVJEKatKyx44/Y1oe68PKuTEb2KpSpxb7 MIME-Version: 1.0 X-Received: by 10.60.116.74 with SMTP id ju10mr32369504oeb.6.1392138408057; Tue, 11 Feb 2014 09:06:48 -0800 (PST) Received: by 10.60.55.197 with HTTP; Tue, 11 Feb 2014 09:06:47 -0800 (PST) In-Reply-To: <52FA5060.9040303@ahsoftware.de> References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> <52FA5060.9040303@ahsoftware.de> Date: Tue, 11 Feb 2014 17:06:47 +0000 Message-ID: From: Dave Cridland To: Alexander Holler Content-Type: multipart/alternative; boundary=089e0116150a4a70a504f2247b30 Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:06:55 -0000 --089e0116150a4a70a504f2247b30 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 11, 2014 at 4:31 PM, Alexander Holler wrote: > which I interpret such, that, besides using a hash from hash (so no new > source), the ID consists of just the first 10 characters of the 40 of a > sha1. And then you argument with the collision rate of sha1? > > Oh, I see what you mean now. Yes, on that model the collision would probably happen much sooner. It's a collision space of 2^40, though, so a birthday attack would hit after about 1.3 million stanzas by my calculations. The chance of this causing a problem seems pretty low. Dave. --089e0116150a4a70a504f2247b30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Feb 11, 2014 at 4:31 PM, Alexander Holler <holler@ahsof= tware.de> wrote:
which I interpret such, that, besides using = a hash from hash (so no new source), the ID consists of just the first 10 c= haracters of the 40 of a sha1. And then you argument with the collision rat= e of sha1?


Oh, I se= e what you mean now.

Yes, on that model the collis= ion would probably happen much sooner.

It's a = collision space of 2^40, though, so a birthday attack would hit after about= 1.3 million stanzas by my calculations. The chance of this causing a probl= em seems pretty low.

Dave.=A0
--089e0116150a4a70a504f2247b30-- From holler@ahsoftware.de Tue Feb 11 09:29:06 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D911A06A2 for ; Tue, 11 Feb 2014 09:29:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj_oeDZK3HcM for ; Tue, 11 Feb 2014 09:29:04 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 049D31A063F for ; Tue, 11 Feb 2014 09:29:04 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id AC4C1423C2A6; Tue, 11 Feb 2014 18:29:01 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 40F2E423C29B for ; Tue, 11 Feb 2014 18:28:52 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 654CA80503; Tue, 11 Feb 2014 18:28:49 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id F11877F829; Tue, 11 Feb 2014 17:28:24 +0000 (UTC) Message-ID: <52FA5DB5.50206@ahsoftware.de> Date: Tue, 11 Feb 2014 18:28:21 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Cridland References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> <52FA5060.9040303@ahsoftware.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:29:06 -0000 Am 11.02.2014 18:06, schrieb Dave Cridland: > On Tue, Feb 11, 2014 at 4:31 PM, Alexander Holler wrote: > >> which I interpret such, that, besides using a hash from hash (so no new >> source), the ID consists of just the first 10 characters of the 40 of a >> sha1. And then you argument with the collision rate of sha1? >> >> > Oh, I see what you mean now. > > Yes, on that model the collision would probably happen much sooner. > > It's a collision space of 2^40, though, so a birthday attack would hit > after about 1.3 million stanzas by my calculations. The chance of this > causing a problem seems pretty low. Based on the assumption that a hash of a hash has the same collision space as the hash itself. Since I'm long out of university and academics and I'm unfortunately quiet out of practice in dealing with maths (even if I liked to do so, but math isn't needed that often in real world computing than universities tend to teach), I'm not going into a discussion about how (un)likely it is that two consequent outputs of such a homegrewn algorithm (sorry for that term) are different. I just wanted to raise awareness that whatever is used should still produce unique numbers (for a short period of time) and not just numbers which are unpredictable. It's easy to predict that a serial counter is unique for some time, but I don't see that when someone uses a series like whateverhash(whateverhash(...) and I wouldn't trust such without having a deeper look at it. Regards, Alexander Holler From holler@ahsoftware.de Tue Feb 11 09:59:23 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA80E1A06D0 for ; Tue, 11 Feb 2014 09:59:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkE1o_eoFjCF for ; Tue, 11 Feb 2014 09:59:22 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2631A06CA for ; Tue, 11 Feb 2014 09:59:22 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 59FAD423C29B; Tue, 11 Feb 2014 18:59:20 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 4FFA8423C256 for ; Tue, 11 Feb 2014 18:59:18 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 789467FA1B; Tue, 11 Feb 2014 18:59:17 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id E608F7F829; Tue, 11 Feb 2014 17:59:06 +0000 (UTC) Message-ID: <52FA64EA.3010003@ahsoftware.de> Date: Tue, 11 Feb 2014 18:59:06 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Cridland References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> <52FA5060.9040303@ahsoftware.de> <52FA5DB5.50206@ahsoftware.de> In-Reply-To: <52FA5DB5.50206@ahsoftware.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 17:59:23 -0000 Am 11.02.2014 18:28, schrieb Alexander Holler: > Am 11.02.2014 18:06, schrieb Dave Cridland: >> On Tue, Feb 11, 2014 at 4:31 PM, Alexander Holler >> wrote: >> >>> which I interpret such, that, besides using a hash from hash (so no new >>> source), the ID consists of just the first 10 characters of the 40 of a >>> sha1. And then you argument with the collision rate of sha1? >>> >>> >> Oh, I see what you mean now. >> >> Yes, on that model the collision would probably happen much sooner. >> >> It's a collision space of 2^40, though, so a birthday attack would hit >> after about 1.3 million stanzas by my calculations. The chance of this >> causing a problem seems pretty low. > > Based on the assumption that a hash of a hash has the same collision > space as the hash itself. > > Since I'm long out of university and academics and I'm unfortunately > quiet out of practice in dealing with maths (even if I liked to do so, > but math isn't needed that often in real world computing than > universities tend to teach), I'm not going into a discussion about how > (un)likely it is that two consequent outputs of such a homegrewn > algorithm (sorry for that term) are different. > > I just wanted to raise awareness that whatever is used should still > produce unique numbers (for a short period of time) and not just numbers > which are unpredictable. It's easy to predict that a serial counter is > unique for some time, but I don't see that when someone uses a series > like whateverhash(whateverhash(...) and I wouldn't trust such without > having a deeper look at it. To play with that hash of hash, is it possible that the hash of a hash is the hash itself? If that ever happens your system will have a problem, so how likely is that? And in the proposed solution it's a bit more difficult, because only the higher 5 bytes of the 20 bytes long hash are used. At least for me, the answer to that isn't obvious. Regards, Alexander Holler From holler@ahsoftware.de Tue Feb 11 10:48:51 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880491A06D0 for ; Tue, 11 Feb 2014 10:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVLUeUv8HllM for ; Tue, 11 Feb 2014 10:48:50 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id 581871A067D for ; Tue, 11 Feb 2014 10:48:50 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 7A3D1423C2AC; Tue, 11 Feb 2014 19:48:49 +0100 (CET) Received: from eiche.ahsoftware (p57B23CD3.dip0.t-ipconnect.de [87.178.60.211]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 8E721423C2A6 for ; Tue, 11 Feb 2014 19:48:28 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 79DC4851C5; Tue, 11 Feb 2014 19:48:27 +0100 (CET) Received: from krabat.ahsoftware (unknown [IPv6:feee::5246:5dff:fe8b:95f8]) by eiche.ahsoftware (Postfix) with ESMTP id EA76B7F829; Tue, 11 Feb 2014 18:48:22 +0000 (UTC) Message-ID: <52FA7076.6070208@ahsoftware.de> Date: Tue, 11 Feb 2014 19:48:22 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Dave Cridland References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> <52FA5060.9040303@ahsoftware.de> <52FA5DB5.50206@ahsoftware.de> <52FA64EA.3010003@ahsoftware.de> In-Reply-To: <52FA64EA.3010003@ahsoftware.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 18:48:51 -0000 Am 11.02.2014 18:59, schrieb Alexander Holler: > To play with that hash of hash, is it possible that the hash of a hash > is the hash itself? If that ever happens your system will have a > problem, so how likely is that? And in the proposed solution it's a bit > more difficult, because only the higher 5 bytes of the 20 bytes long > hash are used. At least for me, the answer to that isn't obvious. To become completely offtopic, one could formalize that question to how the possibility is that sha1^n(x) = sha1(x) for 2 < n <= 100 (if you need that 100 IDs in series are unique) and furthermore you have to look at the upper 5 bytes. I'm not sure if that is what cryptographers usually do look at if they check hash algorithms. So argueing with whatever they found out about sha1 doesn't look obvious to me. Regards, Alexander Holler From internet-drafts@ietf.org Wed Feb 12 15:34:33 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8BE1A0045; Wed, 12 Feb 2014 15:34:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dCUnDJF12ak; Wed, 12 Feb 2014 15:34:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB1F1A001F; Wed, 12 Feb 2014 15:34:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140212233431.12761.11850.idtracker@ietfa.amsl.com> Date: Wed, 12 Feb 2014 15:34:31 -0800 Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-11.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:34:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Author : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-11.txt Pages : 25 Date : 2014-02-12 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stpeter@stpeter.im Wed Feb 12 15:35:28 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039701A0043 for ; Wed, 12 Feb 2014 15:35:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2pC5sQQh5rC for ; Wed, 12 Feb 2014 15:35:25 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AF3421A0039 for ; Wed, 12 Feb 2014 15:35:25 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 579F8403AE; Wed, 12 Feb 2014 16:35:24 -0700 (MST) Message-ID: <52FC053A.90809@stpeter.im> Date: Wed, 12 Feb 2014 16:35:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20140212233431.12761.11850.idtracker@ietfa.amsl.com> In-Reply-To: <20140212233431.12761.11850.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-11.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 23:35:28 -0000 Some small adjustments to track changes to the precis-framework and precis-mappings documents... On 2/12/14, 4:34 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. > > Title : Extensible Messaging and Presence Protocol (XMPP): Address Format > Author : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-11.txt > Pages : 25 > Date : 2014-02-12 > > Abstract: > This document defines the address format for the Extensible Messaging > and Presence Protocol (XMPP), including support for code points > outside the ASCII range. This document obsoletes RFC 6122. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > -- Peter Saint-Andre https://stpeter.im/ From nobody Thu Feb 13 21:27:36 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0CC1A00D9 for ; Thu, 13 Feb 2014 21:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.049 X-Spam-Level: X-Spam-Status: No, score=-15.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MybrmSReM86t for ; Thu, 13 Feb 2014 21:27:32 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB991A00B9 for ; Thu, 13 Feb 2014 21:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1295; q=dns/txt; s=iport; t=1392355651; x=1393565251; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T2nOX7Z1/5FTOtDszsso0QkG5QFJAUOUKnKCCx1U2Ew=; b=Ovg6o49RwgxFvzyxklqSsz+Q27kFcNeDFzETzI+9U1A1f6zV2yb1E785 WrMlI/qsM20nQSbsoInvQD2nqMoiHOxgvWwZu0E/JtPfGHYESN22PssWm fS4c4fcWQFg9P1+SQ5fYDx2yijrhojiF5kGjGBFgVUgKU8UcXmqUtg+CT E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAHuo/VKtJV2Y/2dsb2JhbABZgwY4V79agRkWdIImAQEEAQEBNzQLEAIBCDYQJwslAgQBDQUbh2oNyGwTBI55B4Q4BJgskiODLYIq X-IronPort-AV: E=Sophos;i="4.95,843,1384300800"; d="scan'208";a="303834600" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 14 Feb 2014 05:27:31 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1E5RVT8025120 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 05:27:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.86]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 23:27:30 -0600 From: "Joe Hildebrand (jhildebr)" To: Alexander Holler , Dave Cridland Thread-Topic: [xmpp] IQ Handling vulnerabilities Thread-Index: AQHPIy5NY8RkLrfuaUqqtuYhYOIBR5qopVEAgACdaoCAAL9TgP//w6cAgACRRID//6GvV4AEt5CAgAFRugGAAGYnAIAALgeAgAAFTgCAAAw0AIAABAMAgAAJ3oCAAAYHgIAACJcAgAANxACAA2HhAA== Date: Fri, 14 Feb 2014 05:27:30 +0000 Message-ID: References: <2F5E925F-021D-408E-91D9-3CC5BEB6BEC6@nostrum.com> <48F4D361-4403-47E6-862D-FBDDDEBCC642@xnyhps.nl> <52FA165B.8050901@ahsoftware.de> <52FA3E53.3060009@ahsoftware.de> <0C2D606F-F718-4B07-A0A8-329C547D1BD8@xnyhps.nl> <52FA4D02.5050907@ahsoftware.de> <52FA5060.9040303@ahsoftware.de> <52FA5DB5.50206@ahsoftware.de> <52FA64EA.3010003@ahsoftware.de> <52FA7076.6070208@ahsoftware.de> In-Reply-To: <52FA7076.6070208@ahsoftware.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.65.209] Content-Type: text/plain; charset="us-ascii" Content-ID: <0EE9DA693A176B42AC64C60AB02FDFC3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/kb6W0f_vDHDW13NfdyWfHyGoDXE Cc: XMPP Working Group Subject: Re: [xmpp] IQ Handling vulnerabilities X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 05:27:34 -0000 (as chair) Yes, let's call that off-topic. (as individual) I don't believe we have to specify an algorithm, since there are no interoperability consequences. On 2/11/14 11:48 AM, "Alexander Holler" wrote: >Am 11.02.2014 18:59, schrieb Alexander Holler: > >> To play with that hash of hash, is it possible that the hash of a hash >> is the hash itself? If that ever happens your system will have a >> problem, so how likely is that? And in the proposed solution it's a bit >> more difficult, because only the higher 5 bytes of the 20 bytes long >> hash are used. At least for me, the answer to that isn't obvious. > >To become completely offtopic, one could formalize that question to how >the possibility is that > >sha1^n(x) =3D sha1(x) for 2 < n <=3D 100 > >(if you need that 100 IDs in series are unique) and furthermore you >have to look at the upper 5 bytes. I'm not sure if that is what >cryptographers usually do look at if they check hash algorithms. So >argueing with whatever they found out about sha1 doesn't look obvious to >me. > >Regards, > >Alexander Holler > >_______________________________________________ >xmpp mailing list >xmpp@ietf.org >https://www.ietf.org/mailman/listinfo/xmpp > --=20 Joe Hildebrand From nobody Fri Feb 14 09:28:47 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAB21A031F; Fri, 14 Feb 2014 09:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTlu1E97vbLx; Fri, 14 Feb 2014 09:28:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C061A0312; Fri, 14 Feb 2014 09:28:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214172839.3876.53825.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 09:28:39 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/HHwLPMlknK1kXyQ94kczFeGAQWQ Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-websocket-01.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:28:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : An XMPP Sub-protocol for WebSocket Authors : Lance Stout Jack Moffitt Eric Cestari Filename : draft-ietf-xmpp-websocket-01.txt Pages : 13 Date : 2014-02-14 Abstract: This document defines a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-websocket-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 14 10:13:25 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D61A0396 for ; Fri, 14 Feb 2014 10:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWCsKJAnFfQJ for ; Fri, 14 Feb 2014 10:13:20 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id B34301A037E for ; Fri, 14 Feb 2014 10:13:20 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa1so12708644pad.27 for ; Fri, 14 Feb 2014 10:13:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=JpuXShQFux2LnK9FCta90EA5BkbnmRXE4m9YSG6U9Cc=; b=CaMicH3B3aldmZj3k+ACHFtj21+KHiCOGSdwdkaMEIsrF9fj8CI86USzzF6O0+J1MW /5gEJHLrbf4iYoSD523OH3x9hjLeWuNkww/OCSf5q7Fdyf8Hu3ZXQ5I5jCYqmji1udWc dj8gH9TgSke546+QP2wEASzySKOXsvlnLhm2i9Ak6OyfY4gc45mksQac5iAmW58kbKMZ YYNa2TEnrr21X9ebTnsFcZCD+GRDaT/CxSN8YoNRwLoaAbg+8zSmUZz2sWftYmpEccp4 dGZxu8FuvrkXYSa0XKo9dF75ILrtUChMSNdB/FJDmHcEv4O+wGDoG3rsJV+qNrwPrNRO YDjA== X-Gm-Message-State: ALoCoQkFNItqBFECkQebXZcWwvh6Qt++yzrqySZeDUNG6Hj5pmboegYMawIVFdr7uH5Vwb6kDsBl X-Received: by 10.66.118.71 with SMTP id kk7mr10510304pab.14.1392401599226; Fri, 14 Feb 2014 10:13:19 -0800 (PST) Received: from [10.0.2.180] (71-84-176-17.dhcp.mdfd.or.charter.com. [71.84.176.17]) by mx.google.com with ESMTPSA id cz3sm19449418pbc.9.2014.02.14.10.13.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 10:13:18 -0800 (PST) From: Lance Stout Content-Type: multipart/signed; boundary="Apple-Mail=_37C2A9B7-11F0-4BBB-A4FB-11A5DFDB07E7"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Fri, 14 Feb 2014 10:13:16 -0800 References: <20140214172839.3876.31414.idtracker@ietfa.amsl.com> To: XMPP Standards , XMPP Working Group Message-Id: <74E82CC3-D0CD-4958-86F0-43013FF8D1DD@andyet.net> Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VmrxCki-JBGKF16cDHQEff1tOcc Subject: [xmpp] Fwd: New Version Notification for draft-ietf-xmpp-websocket-01.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:13:23 -0000 --Apple-Mail=_37C2A9B7-11F0-4BBB-A4FB-11A5DFDB07E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This XMPP over WebSocket draft update warrants some discussion, and will = need a good dose of feedback. 1) Using new open/close elements. At the last IETF meeting we outlined how new open/close elements would = work, but we didn't quite reach consensus on if that approach should = used (discussions both on and off list resulted in people swapping sides = repeatedly). However, after informal discussions at the XSF Summit in = Brussels between those of us who expressed preference on list for the = existing method, I believe we have now reached consensus to = use the new open/close elements. The summary of the new open/close approach is: -- Starting a stream (success) =3D=3D=3D Establish WebSocket =3D=3D=3D=20 C: S: --- Starting a stream (error) C: S: S: ...=20 S: C: =3D=3D=3D Close WebSocket =3D=3D=3D=20 -- Closing a stream S: C: =3D=3D=3D Close WebSocket =3D=3D=3D In addition, every WebSocket message MUST be a full, well-formed XML = fragment with all relevant namespace and xml:lang declarations. There = was concern before about the bandwidth increase this would cause, but it = should be noted that WebSocket compression is well underway and has = implementations in browsers now (with sliding zlib window between = message frames). As should be obvious, but I will state it to be clear: this is a = BREAKING change. Given the relatively small number of existing = implementations and production deployments, I hope we can get everything = switched over fairly quickly.=20 2) The see-other-uri issue With the new element, we now have a way to express = see-other-uri behaviour: 3) Security Considerations Most of the security considerations we've discussed are due to the = browser not exposing the information we traditionally need to perform = peer verification. We have concluded before that in most cases, a = browser-based client will be served from the same domain as the XMPP = server and WebSocket endpoint, and be hardcoded to use the correct = endpoint; however, there still are some gaps in multi-tenant situations = and for browser-based clients intended to be used with any domain. At the XSF, we have updated XEP-0156 (Discovering Alternative XMPP = Connection Methods) to include an HTTPS lookup method. A neat side = effect of that approach is that it lets us have 'POSH-lite', allowing a = client to establish a trust relationship between the targeted XMPP = domain and its WebSocket endpoint (with caveats of not allowing = downgrades from wss to ws, etc). As far as I'm aware, that seems to be = the most we can do in this area. =97 Lance Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-xmpp-websocket-01.txt > Date: February 14, 2014 at 9:28:39 AM PST > To: Eric Cestari , "Lance Stout" = , "Jack Moffitt" , Lance Stout = , "Eric Cestari" , Jack Moffitt = >=20 >=20 > A new version of I-D, draft-ietf-xmpp-websocket-01.txt > has been successfully submitted by Lance Stout and posted to the > IETF repository. >=20 > Name: draft-ietf-xmpp-websocket > Revision: 01 > Title: An XMPP Sub-protocol for WebSocket > Document date: 2014-02-14 > Group: xmpp > Pages: 13 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-xmpp-websocket-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ > Htmlized: = http://tools.ietf.org/html/draft-ietf-xmpp-websocket-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-xmpp-websocket-01 >=20 > Abstract: > This document defines a binding for the XMPP protocol over a > WebSocket transport layer. A WebSocket binding for XMPP provides > higher performance than the current HTTP binding for XMPP. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_37C2A9B7-11F0-4BBB-A4FB-11A5DFDB07E7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM5jCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIGqjCCBZKg AwIBAgICL6UwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MzAzMTQwNTM1MTJaFw0xNTAzMTUyMjMyMzZaMIGMMRkwFwYDVQQNExBQTDAxbVhKMjhha3BBRzVj MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3RvbjESMBAGA1UEBxMJS2VubmV3aWNrMRQw EgYDVQQDEwtMYW5jZSBTdG91dDEjMCEGCSqGSIb3DQEJARYUbGFuY2VzdG91dEBnbWFpbC5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCr0XNL4SLaoBR9y72zNo3eAefV7vk1UaEx xML9TqPKZHV9gGxA/XO5YilACUU/l5In+8akri5djy/haORYEm5HwsR/R1vxhOK7cBEyXMCY41Vg KyqnQPJlidJ0L5PMinz1cwo0wyLlh8WhxIBHBjgLbA8XAoDC7FL6KzDq+qoJdsBbehu4W9fVscRr T7XeM41zHjc7FqJOD8I2n9Z5CIlEeWwaIEZO0HpxOlcbD5EGVaC7Wbji/nEOuQ1OI6iGId/7Xakg JrGfjSg1wQ5dXIBMzbSZmw3B6WmDdNgpCzHYL+QrCLrFenO0u2D6ZR/dZQgIkPRhL6I7PqniJ3FN 0hJpAgMBAAGjggMSMIIDDjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEF BQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFFggdjTZDgsglI1DBpZiCB24Ub+ZMB8GA1UdIwQYMBaA FK5Vg2/sMcq59x36r2sx88gd46y7MFcGA1UdEQRQME6BFGxhbmNlc3RvdXRAZ21haWwuY29tgRRs YW5jZXN0b3V0QGdtYWlsLmNvbYEObGFuY2VAbGFuY2UuaW2BEGxhbmNlQGFuZHlldC5uZXQwggFM BgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBh Y2NvcmRpbmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0 YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2Ug aW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wNgYDVR0fBC8w LTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUH AQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIv Y2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIu Y2xhc3MyLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20v MA0GCSqGSIb3DQEBBQUAA4IBAQALnAVqIrddlyGYqOAb4TfJ25u3sOtC352yAF7VaQdhkV/Z7Rum OPpsEN7rwLfHOphYhafI4IxKy39NZbFBjzzcW8Kx6OJ1L/eDEW5Dbt1XzaBF4VVM1/DZyg/l3C0N 9/YrumhcgdSUgxLL2d/GzEk1dNTcZLpLJABf6L1W5RszU4HSPyVppLzYVVq5yLwmKnlIcnDjEdMr jmsFq8b0Duk1j05IE2KBiWNy/Q0H9Hj/943/rvQOx7464jzuEGkWYO8AU7Nmq3h2DLoo8GECFwxy e7rSL0o3KFkAQHC0YE/8GbaT05Jo7xnF/9X/IOWd0rSvBmTVkreGARQywViv35eCMYIDbDCCA2gC AQEwgZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFz cyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwCQYFKw4DAhoFAKCCAa0wGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMjE0MTgxMzE3WjAjBgkq hkiG9w0BCQQxFgQUvWDulsLsJDn2dYCn6FBHqRdxwjgwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFy eSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIvpTCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkg SW50ZXJtZWRpYXRlIENsaWVudCBDQQICL6UwDQYJKoZIhvcNAQEBBQAEggEAChkzagg5G3+fOoCz oMWrb9R408I8qVp88fKVCPPunAdJjNEMuMAmqTYmD4sW77pqUQmC++S1KkojcL8v1HRwDueFu4Dx ixpM9L5qFMfCUF/vmwW7CfsYX10crBLHygTRPrFBalch/yrnekOTDXVWmaU5Q5Wag8kZnNdK9LDz M0ZMOfbPeeZ9tBs0ux/WB9p9MQQxDTo0WnClxIauigjlUNmJHs5J5dYfSDxFORICWRt2dw6fohna Jiwdz+IT+Bv60L5D+5YU8WefnJbSlNq7yqddP1PFXrrWruRM2etKHCtDZeQivQzrSA0uwbWbdWkW 4DTPSe4o/dZyhsbXDUt3BgAAAAAAAA== --Apple-Mail=_37C2A9B7-11F0-4BBB-A4FB-11A5DFDB07E7-- From nobody Fri Feb 14 13:20:03 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0171A037F for ; Fri, 14 Feb 2014 13:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqwiXpLGHwhM for ; Fri, 14 Feb 2014 13:19:59 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A68211A03C3 for ; Fri, 14 Feb 2014 13:19:55 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1ELJqKO051801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 14 Feb 2014 15:19:53 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Message-Id: Date: Fri, 14 Feb 2014 15:19:51 -0600 To: XMPP Working Group X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/_LI-wvZ0wt76QyUoA6K4aVSKNFQ Subject: [xmpp] Draft Agenda X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:20:01 -0000 Hi Everyone, The draft agenda for the IETF 89 XMPP meeting is available at the = following link. Please send any omissions or suggested changes to the = chairs and the mailing list. http://www.ietf.org/proceedings/89/minutes/minutes-89-xmpp Thanks! Ben.= From nobody Fri Feb 21 12:32:13 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077AE1A024B for ; Fri, 21 Feb 2014 12:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbhm8l4ozF9W for ; Fri, 21 Feb 2014 12:32:11 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A20421A01ED for ; Fri, 21 Feb 2014 12:32:08 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1LKVwfM062897 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 14:32:00 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 21 Feb 2014 14:31:58 -0600 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) To: XMPP Working Group X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/PBLTuAT1Ojl6oUavNJW4Ru5NmWA Subject: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:32:12 -0000 (as chair) Hi Everyone, The XMPP working group has a milestone for "Define a solution for = end-to-end encryption." We have not seen much activity there of late, = and it has been suggested that we may need to delete that milestone due = to insufficient interest and energy. Who is still interested in contributing effort to complete this = milestone? That is, in discussion, review, and perhaps even writing = drafts? Who expects to implement and/or deploy such a solution, once we have = one? Are other approaches (e.g. OTR, TLS everywhere, etc) likely to be "good = enough" that we don't need to do more work? Thanks! Ben.= From nobody Fri Feb 21 12:40:47 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A291A025F for ; Fri, 21 Feb 2014 12:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNt4FwqaYcmS for ; Fri, 21 Feb 2014 12:40:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 50A231A0253 for ; Fri, 21 Feb 2014 12:40:43 -0800 (PST) Received: from netb ([178.13.33.163]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M4jbN-1XCsVl3VpV-00z2FR for ; Fri, 21 Feb 2014 21:40:37 +0100 From: Bjoern Hoehrmann To: Ben Campbell Date: Fri, 21 Feb 2014 21:40:44 +0100 Message-ID: <42efg9p64vusuds7anuc0vjchb2p7qsvev@hive.bjoern.hoehrmann.de> References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:aMLe9Oe+cEz0PLOsII44nReOv1rMPHCn/pSnqRBDAvUUX3Bgjmw ctnQNN2vKUsX+/ejHhOVMbcVSWloURl2hN2fZOMKVNg2Xf/ErBlV5L4S/HIE907vV7493cF hr4O0Hz1igZOLELzE2MKkAlEzYjGnRsPSvB6fvzdIzm356tOMa1THNrKpgyYP9PLp0GaAe5 jaL/wS6y0qO+aBHvZI1GA== Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/PRFBw-Mt9fojF3IiDKnhuaT58Hw Cc: XMPP Working Group Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:40:46 -0000 * Ben Campbell wrote: >The XMPP working group has a milestone for "Define a solution for >end-to-end encryption." We have not seen much activity there of late, >and it has been suggested that we may need to delete that milestone due >to insufficient interest and energy. > >Who is still interested in contributing effort to complete this >milestone? That is, in discussion, review, and perhaps even writing >drafts? > >Who expects to implement and/or deploy such a solution, once we have one? > >Are other approaches (e.g. OTR, TLS everywhere, etc) likely to be "good >enough" that we don't need to do more work? I intend to review mature specification proposals, and would probably participate in requirements discussions if needed. It is possilbe that existing solutions are "good enough" but there are obvious deployment issues; it might be useful or even sufficient to produce an overview specification possibly with recommendations. I think it would be use- ful to send your questions to the `perpass` mailing list, there might be volunteers there. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From nobody Fri Feb 21 12:51:42 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4650A1A019F for ; Fri, 21 Feb 2014 12:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1e2z9Fd5rJx0 for ; Fri, 21 Feb 2014 12:51:40 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 45D711A0135 for ; Fri, 21 Feb 2014 12:51:40 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id s1LKpUcu063840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Feb 2014 14:51:32 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ben Campbell In-Reply-To: <42efg9p64vusuds7anuc0vjchb2p7qsvev@hive.bjoern.hoehrmann.de> Date: Fri, 21 Feb 2014 14:51:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3E1BA015-6AE7-4324-B437-4E4451F6BE74@nostrum.com> References: <42efg9p64vusuds7anuc0vjchb2p7qsvev@hive.bjoern.hoehrmann.de> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1827) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/j-PUc7Y1hYbFaqPvmIxuyg6SnHk Cc: XMPP Working Group Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 20:51:41 -0000 On Feb 21, 2014, at 2:40 PM, Bjoern Hoehrmann wrote: > I think it would be use- > ful to send your questions to the `perpass` mailing list, there might > be volunteers there. I think that would be a good idea before giving up on the milestone, but = I'd like to get a sense of the interest of current working group = participants.= From nobody Fri Feb 21 13:36:48 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDA21A0273 for ; Fri, 21 Feb 2014 13:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jb7gcGXd5MUt for ; Fri, 21 Feb 2014 13:36:45 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3F70A1A0135 for ; Fri, 21 Feb 2014 13:36:45 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id o6so4741073oag.0 for ; Fri, 21 Feb 2014 13:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=AE1cCzm8jXT3+FN6QQu4M22S+ZU2CF1/YUXWLGvxs/Y=; b=BlifQ3TMmhIpTDqTQRDg87+YLPGuOMH5HU4tN6vcxFO4i7gZ6CDtjIicm6JfSePW7P t8qtqR6IrtC2SFfq3wkH6SH38YQP3ieevdq9uPvBdjNCgu1orf5pYqJnPo8U6yaInVEA NVKTW6Jq+yfC61EU1Kxe5zWuZbJU/F97HYSYE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=AE1cCzm8jXT3+FN6QQu4M22S+ZU2CF1/YUXWLGvxs/Y=; b=ELVgvyKSlQIsWe5/TFa6dSt7VT/WAZ7G4YUgt+x4neNG4kvZxZlw7PrCoA8cXHQ1G9 C5lbnoEh9bCFWMIQ35GqNMQVLyeiEbkZHXVcGFEMtQVHdDu77SGk//tqGOXHXeUsRL/L dfkenxkf5NidV9CKjouyeXRm6Mc24yD3M1cXaJ3QubviVznlwkZKtCyNH4B7ZVa93ir5 HVFdnPxFzyYBRqHEUGq7APY4yT0IIpv5m1d9ho/V4QmAYG/S1+BmgSAFvWChOJBByl5o KmVS9YmVpfEqkusVrzP5wtxeed0mUqTyic4TrkyIVy0Hc6jxzE+Ndy7wXnf5UlEdPDLC cT+g== X-Gm-Message-State: ALoCoQlc56g2gALN+yeFJ+X5aerzruj3U5WSTgiHegEEfXVgoWnL30SflGN7ApVlZTTizglaZzft MIME-Version: 1.0 X-Received: by 10.182.146.104 with SMTP id tb8mr8025431obb.54.1393018601172; Fri, 21 Feb 2014 13:36:41 -0800 (PST) Received: by 10.60.55.197 with HTTP; Fri, 21 Feb 2014 13:36:41 -0800 (PST) Date: Fri, 21 Feb 2014 21:36:41 +0000 Message-ID: From: Dave Cridland To: XMPP Working Group Content-Type: multipart/alternative; boundary=f46d04451a39e3841a04f2f16af6 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/BAEH8-rWHnk1eCkylHC-ApoMyfY Subject: [xmpp] London XMPP Meetup - 4th March X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2014 21:36:47 -0000 --f46d04451a39e3841a04f2f16af6 Content-Type: text/plain; charset=ISO-8859-1 The XMPPUK group is preparing for their next Meetup in London - Tuesday 4th March to coincide with IETF 89. If you can come, it would be great to see as many people as possible! Details here: http://www.meetup.com/XMPP-UK-Meetup/ Note that I'm not a good contact for this; any question should be directed instead to the organizer, Laura Gill This does clash with the IETF Social, but it's OK - we'll have pizza. Dave. --f46d04451a39e3841a04f2f16af6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The XMPPUK group is preparing for their next Meetup i= n London - Tuesday 4th Mar= ch to coincide with IETF 89.

If you = can come, it would be great to see as many people as possible! Details here= :=A0htt= p://www.meetup.com/XMPP-UK-Meetup/

Note that I'm not a good contact for this; any ques= tion should be directed instead to the organizer, Laura Gill <laura.gill@surevine.com>

This does clash with the IETF Social, but it's OK - we'll have= pizza.

Dave.
--f46d04451a39e3841a04f2f16af6-- From nobody Sun Feb 23 17:43:55 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8F41A0790 for ; Sun, 23 Feb 2014 17:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT1A3-h7as8a for ; Sun, 23 Feb 2014 17:43:51 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 909691A078C for ; Sun, 23 Feb 2014 17:43:51 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s1O1hnKV015253 for ; Mon, 24 Feb 2014 10:43:49 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s1O1hnh4023755 for xmpp@ietf.org; Mon, 24 Feb 2014 10:43:49 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id LAA23754; Mon, 24 Feb 2014 10:43:49 +0900 Received: from mx12.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s1O1hnVO008029 for ; Mon, 24 Feb 2014 10:43:49 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s1O1hnbp024416; Mon, 24 Feb 2014 10:43:49 +0900 (JST) Received: from [133.196.16.86] (ncg-dhcp86.isl.rdc.toshiba.co.jp [133.196.16.86]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id D503597D5E; Mon, 24 Feb 2014 10:43:48 +0900 (JST) Message-ID: <530AA3D4.50801@toshiba.co.jp> Date: Mon, 24 Feb 2014 10:43:48 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell , XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/arRUkyAbin5pAf1rI7CONCI6yPc Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 01:43:54 -0000 Just a question: (2014-02-22 05:31), Ben Campbell wrote: > The XMPP working group has a milestone for "Define a solution for end-to-end encryption." We have not seen much activity there of late, and it has been suggested that we may need to delete that milestone due to insufficient interest and energy. Does the 'end-to-end encryption' mean something like PGP encryption? I just noticed XEP-0027 is histiorical. Does the WG need different solution? Also, XML encryption seems to fit if key management issue is solved (but maybe too generic and complex for simple stanza encryption). http://www.w3.org/TR/xmlenc-core/ Regards, Yusuke From nobody Sun Feb 23 17:49:40 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 607A51A07A0 for ; Sun, 23 Feb 2014 17:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2C76CXjKR2H for ; Sun, 23 Feb 2014 17:49:36 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8118A1A079C for ; Sun, 23 Feb 2014 17:49:36 -0800 (PST) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 06F4B403BB; Sun, 23 Feb 2014 18:49:35 -0700 (MST) Message-ID: <530AA52E.8040704@stpeter.im> Date: Sun, 23 Feb 2014 18:49:34 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <530AA3D4.50801@toshiba.co.jp> In-Reply-To: <530AA3D4.50801@toshiba.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/_fAmHfF6ZJW4QpELE7KtWocDMHk Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2014 01:49:38 -0000 On 2/23/14, 6:43 PM, Yusuke DOI wrote: > Just a question: > > (2014-02-22 05:31), Ben Campbell wrote: >> The XMPP working group has a milestone for "Define a solution for >> end-to-end encryption." We have not seen much activity there of late, >> and it has been suggested that we may need to delete that milestone >> due to insufficient interest and energy. > > Does the 'end-to-end encryption' mean something like PGP encryption? I > just noticed XEP-0027 is histiorical. Does the WG need different solution? > > Also, XML encryption seems to fit if key management issue is solved (but > maybe too generic and complex for simple stanza encryption). > > http://www.w3.org/TR/xmlenc-core/ Dear Yusuke, There is a *long* history of discussion and work on end-to-end encryption approaches. You might read the following: http://tools.ietf.org/id/draft-ietf-xmpp-e2e-requirements-01.txt http://tools.ietf.org/html/draft-saintandre-strint-workshop-xmpp-02#section-4 https://stpeter.im/journal/1241.html It's quite a sad story, really. Peter -- Peter Saint-Andre https://stpeter.im/ From nobody Mon Feb 24 17:13:45 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F69F1A0334 for ; Mon, 24 Feb 2014 17:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.939 X-Spam-Level: X-Spam-Status: No, score=-4.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2H5Wg-LGXh3 for ; Mon, 24 Feb 2014 17:13:41 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDEE1A02C2 for ; Mon, 24 Feb 2014 17:13:40 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id s1P1DbvW009755 for ; Tue, 25 Feb 2014 10:13:37 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id s1P1Db99026613 for xmpp@ietf.org; Tue, 25 Feb 2014 10:13:37 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id LAA26611; Tue, 25 Feb 2014 10:13:37 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id s1P1Da5j002752 for ; Tue, 25 Feb 2014 10:13:37 +0900 (JST) Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id s1P1DaOW016811; Tue, 25 Feb 2014 10:13:36 +0900 (JST) Received: from [133.196.16.86] (ncg-dhcp86.isl.rdc.toshiba.co.jp [133.196.16.86]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPS id A6B3397D62; Tue, 25 Feb 2014 10:13:36 +0900 (JST) Message-ID: <530BEE3F.2080204@toshiba.co.jp> Date: Tue, 25 Feb 2014 10:13:35 +0900 From: Yusuke DOI User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Saint-Andre , xmpp@ietf.org References: <530AA3D4.50801@toshiba.co.jp> <530AA52E.8040704@stpeter.im> In-Reply-To: <530AA52E.8040704@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/j_WvzhNdDbqcdQB3vngn708y2EY Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 01:13:43 -0000 Dear Peter, Thanks for the pointers. I agree: the perfect is the enemy of good. Hmm... Yusuke (2014-02-24 10:49), Peter Saint-Andre wrote: > On 2/23/14, 6:43 PM, Yusuke DOI wrote: >> Just a question: >> >> (2014-02-22 05:31), Ben Campbell wrote: >>> The XMPP working group has a milestone for "Define a solution for >>> end-to-end encryption." We have not seen much activity there of late, >>> and it has been suggested that we may need to delete that milestone >>> due to insufficient interest and energy. >> >> Does the 'end-to-end encryption' mean something like PGP encryption? I >> just noticed XEP-0027 is histiorical. Does the WG need different solution? >> >> Also, XML encryption seems to fit if key management issue is solved (but >> maybe too generic and complex for simple stanza encryption). >> >> http://www.w3.org/TR/xmlenc-core/ > > Dear Yusuke, > > There is a *long* history of discussion and work on end-to-end encryption approaches. You might read the following: > > http://tools.ietf.org/id/draft-ietf-xmpp-e2e-requirements-01.txt > > http://tools.ietf.org/html/draft-saintandre-strint-workshop-xmpp-02#section-4 > > https://stpeter.im/journal/1241.html > > It's quite a sad story, really. > > Peter > From nobody Tue Feb 25 03:23:29 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253821A0449 for ; Tue, 25 Feb 2014 03:23:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgzV2b_cBU6E for ; Tue, 25 Feb 2014 03:23:26 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 477A11A0440 for ; Tue, 25 Feb 2014 03:23:26 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id vb8so8382378obc.2 for ; Tue, 25 Feb 2014 03:23:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nuNowAGj7wSIagnqtOF5+SzSB29Xsx6J45N/GSOB20k=; b=T777HPGeMJu5TSVIkTfth1sOq4Tn4mEj04qW8vkWeo++uYIjYP4VaahQ31tpWoftsa 5zV4XunAm4gmRyeE29ljGTiAWAfqYJ+UQwnUeetce9m7RpChVBwx+WdNzZxRM8K5TTG4 ApMv9ezop191cOG3YSZ0DMj1kTAWbzkMs4/3Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nuNowAGj7wSIagnqtOF5+SzSB29Xsx6J45N/GSOB20k=; b=Kko3V21RY526wM+pzfMq3SbMB5rC2YBB/Gtbnr4ZYow3SzIvhFuKQmjuICSia51ZZO R3GEHJo6/yu8G+YDz1yDTsEq6n9nom4wHZYP2rF8Vh6xmU2Z4yzcTbNY5UAQhQjEvW10 idCKYd3KU2yhL+ktle0BYrPSDlojWqSXxcB1N0s2raGU37+ET+4mkq5O92r4/0PkbZXI rgAviGxMXmoIrZCDCpzRn3MQBDbgcuxePOChWVYKDgNPORWnkddxfaZEIhJeeP6dJ8SH YcDuByLNhtvkO7ZBO7Vfa3K5hk/kVuoYdumeeYUQGDVAIU9JwcY0GDiAyaicHcCARLWr bxLA== X-Gm-Message-State: ALoCoQlBMeIj0k6pg3qxgIQHrY4NPKLUdHps+L8sLgnn142guO/zcBVHWSuOW6TJ37XiPfIeSmNj MIME-Version: 1.0 X-Received: by 10.182.102.134 with SMTP id fo6mr798875obb.10.1393327405420; Tue, 25 Feb 2014 03:23:25 -0800 (PST) Received: by 10.60.55.197 with HTTP; Tue, 25 Feb 2014 03:23:25 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 11:23:25 +0000 Message-ID: From: Dave Cridland To: Ben Campbell Content-Type: multipart/alternative; boundary=089e0149c3800e65b404f33951d4 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/eIqd2YRIDOG85ua8bV_ArdlBfg8 Cc: XMPP Working Group Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 11:23:28 -0000 --089e0149c3800e65b404f33951d4 Content-Type: text/plain; charset=ISO-8859-1 In a fit of being rubbish, I exchanged a couple of messages with Ben directly before realising I'd not copied the list. The first said: I'd like to get OTR usage in XMPP documented, but I think that's an informational document, possibly better done within the XSF. Ben countered with: Does that mean OTR, after documentation, would be good enough? Or is there still work for the IETF here? I responded: I honestly don't know. I doubt it, but OTR in XMPP is largely a matter of fiddle-until-it-works. It's not, apparently, entirely straightforward due to multiple resources, resource "locking", etc. Documenting it in a way that would be useful to developers would also mean the issues surrounding this form of encryption were laid bare, and give us some ideas of how to tackle the problem ourselves. Doing it within the XSF would *possibly* be simpler in terms of process. On Fri, Feb 21, 2014 at 8:31 PM, Ben Campbell wrote: > (as chair) > > Hi Everyone, > > The XMPP working group has a milestone for "Define a solution for > end-to-end encryption." We have not seen much activity there of late, and > it has been suggested that we may need to delete that milestone due to > insufficient interest and energy. > > Who is still interested in contributing effort to complete this milestone? > That is, in discussion, review, and perhaps even writing drafts? > > Who expects to implement and/or deploy such a solution, once we have one? > > Are other approaches (e.g. OTR, TLS everywhere, etc) likely to be "good > enough" that we don't need to do more work? > > Thanks! > > Ben. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --089e0149c3800e65b404f33951d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In a fit of being rubbish, I exchanged a couple of message= s with Ben directly before realising I'd not copied the list.

<= /div>
The first said:

I'd like to get OTR = usage in XMPP documented, but I think that's an informational document,= possibly better done within the XSF.

Ben countered with: Does that mean OTR, after doc= umentation, would be good enough? Or is there still work for the IETF here?=

I responded:

I hone= stly don't know. I doubt it, but OTR in XMPP is largely a matter of fid= dle-until-it-works. It's not, apparently, entirely straightforward due = to multiple resources, resource "locking", etc. Documenting it in= a way that would be useful to developers would also mean the issues surrou= nding this form of encryption were laid bare, and give us some ideas of how= to tackle the problem ourselves.

Doing it within the XSF would *possibly* be simpler in = terms of process.


On Fri, Feb 21, 2014 at 8:31 PM, Ben Campbell <ben@nos= trum.com> wrote:
(as chair)

Hi Everyone,

The XMPP working group has a milestone for "Define a solution for end-= to-end encryption." We have not seen much activity there of late, and = it has been suggested that we may need to delete that milestone due to insu= fficient interest and energy.

Who is still interested in contributing effort to complete this milestone? = That is, in discussion, review, and perhaps even writing drafts?

Who expects to implement and/or deploy such a solution, once we have one?
Are other approaches (e.g. OTR, TLS everywhere, etc) likely to be "goo= d enough" that we don't need to do more work?

Thanks!

Ben.
_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--089e0149c3800e65b404f33951d4-- From nobody Tue Feb 25 04:12:08 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB961A044C for ; Tue, 25 Feb 2014 04:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqa_Zx9jMdBX for ; Tue, 25 Feb 2014 04:12:05 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 671EC1A03DD for ; Tue, 25 Feb 2014 04:12:05 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id a41so6710264yho.11 for ; Tue, 25 Feb 2014 04:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dIE05DZGM9Dr62QRAccIEJhuoJ7ZwTdc3jSRswfeMUw=; b=RTUXqUJNyzgAB3nqpeZJFMPT2xDyETMuL10SIXsfcV833BtoRT0Qqm0hFSw6t0/bTg 7aU3aaiXG66jp6mAmWpQWNtNUBHg04ki0lZCD35pHKSXbi9RhtFHO55zpV5Wvuzd2kPW McK/08Yz3wUkne1XEH33MP6SnoyC/WPj+0Z/XuTQL/B9XYobqjNqtffUlBs7XvYnzx+2 h1oL03E6ZbzR4Rr47nc4wUtNiStOIoIWbrDAdoQU5fQJ6t4n4HuImeYRfe09BjVeOkVs QQBvKgU7AxqPfz/WQYkXSITYiiFnd8C4Otl90yiAEcHmvWUAaCq0ONk2MvTaSr665OIG T2Cw== X-Received: by 10.236.17.195 with SMTP id j43mr42954yhj.137.1393330324237; Tue, 25 Feb 2014 04:12:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.38.142 with HTTP; Tue, 25 Feb 2014 04:11:44 -0800 (PST) In-Reply-To: References: From: Tobias Markmann Date: Tue, 25 Feb 2014 13:11:44 +0100 Message-ID: To: Dave Cridland Content-Type: multipart/alternative; boundary=001a11c1e2f807f1c604f339ffa6 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/_FrU7LMyhBEr9fSEW-7SvL05CcE Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 12:12:06 -0000 --001a11c1e2f807f1c604f339ffa6 Content-Type: text/plain; charset=UTF-8 I think what's really needed is some kind of overview/comparison document about that current status. While the current requirements document is a start in listing some potential requirements, modern IM use cases are a bit more complex, w.r.t. multi-device and the mobile application scenarios. So basically a document that compares existing proposals, like OTR, PGP, XTLS and maybe even some more general e2e IM security solutions like the TextSecure protocol or multi-party OTR, and analyze those regarding their security, support for PubSub/MUC, support for offline messages, support for multi-device usage, and possibly even more. On Tue, Feb 25, 2014 at 12:23 PM, Dave Cridland wrote: > Doing it within the XSF would *possibly* be simpler in terms of process. Indeed. I don't know if the IETF is the right place for a status quo comparison document or if it'd be more attractive within the XSF with less process. I for one would gladly review and try to contribute as much as possible to such document. Reviewing current proposals and exposing their advantages and shortcomings, especially regarding multi-resource and offline usage, would be a great way to start looking for possible solutions for XMPP. Cheers, Tobias --001a11c1e2f807f1c604f339ffa6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I th= ink what's really needed is some kind of overview/comparison document a= bout that current status. While the current requirements document is a star= t in listing some potential requirements, modern IM use cases are a bit mor= e complex, w.r.t. multi-device and the mobile application scenarios.

So basicall= y a document that compares existing proposals, like OTR, PGP, XTLS and mayb= e even some more general e2e IM security solutions like the TextSecure prot= ocol or multi-party OTR, and analyze those regarding their security, suppor= t for PubSub/MUC, support for offline messages, support for multi-device us= age, and possibly even more.=C2=A0

On Tue, Feb= 25, 2014 at 12:23 PM, Dave Cridland <dave@cridland.net> wro= te:
Doing it within the XSF would *possibly* be = simpler in terms of process.

Indeed. I don't know= if the IETF is the right place for a status quo comparison document or if = it'd be more attractive within the XSF with less process. I for one wou= ld gladly review and try to contribute as much as possible to such document= . Reviewing current proposals and exposing their advantages and shortcoming= s, especially regarding multi-resource and offline usage, would be a great = way to start looking for possible solutions for XMPP.

Cheer= s,
Tobias
--001a11c1e2f807f1c604f339ffa6-- From nobody Tue Feb 25 05:27:00 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781E21A06D8 for ; Tue, 25 Feb 2014 05:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.322 X-Spam-Level: * X-Spam-Status: No, score=1.322 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ze4-s36FjvWP for ; Tue, 25 Feb 2014 05:26:57 -0800 (PST) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id C144B1A06D2 for ; Tue, 25 Feb 2014 05:26:57 -0800 (PST) Received: by mail-oa0-f41.google.com with SMTP id o6so372558oag.28 for ; Tue, 25 Feb 2014 05:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UbK8Cuaz2JBSZX05Avl6w2tWq3zbtrdojQpCI7llb+Q=; b=TiFiViZEHcgr8l4dohqoMC06kYJ/+zCEkneDbrYzwL8d1yAz6o8hAaWCZRo46bUrNU M2eBCABMiRieR7zSd8Krto37uN3MQnSjhQaYWjeXE9rcCmA1G27g+zyoJicp49nbVGJS J/fK3aIkkasQLXrqgIAmij22E+SoXivyrl+BY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UbK8Cuaz2JBSZX05Avl6w2tWq3zbtrdojQpCI7llb+Q=; b=fWcO766R/hz4TI/Hb+8xOBqbwf9FtDEuay/93zbVhaftfUsTlAXgr5eYj3S1BG7tNv d3hBxN1b/i6nMSK+J5Je9Ixk/Xw9y3Xwprma+SL8AyQXGdmVEuYVsJVsQIwP2V2VOY+M 5ucuP4ax706Tk9peI/BQ/y8RaOtuabmcbvTTagJdkCNtbcgNeYJzD6Q+ET0Pj5anp6Vi pmM/HkI8P4mtUiOoHMYDLmzZmwUpKs8scwwymJp51jE/h6kR4jZgoG9G4nXkGNRobBK3 gGYOer+qapWYanFy536owYjw7m1da6RVSB5j4xAb3PByM9NCVv/u200kJtKmfESICelz AQdA== X-Gm-Message-State: ALoCoQlgbuMFeqkLuDctCPYYjzTjcvJjo5HlYf4xZZ67t0Ynhce4LtHX5pxoL6UnuYENrInmg4Ua MIME-Version: 1.0 X-Received: by 10.60.173.147 with SMTP id bk19mr1248481oec.46.1393334816816; Tue, 25 Feb 2014 05:26:56 -0800 (PST) Received: by 10.60.55.197 with HTTP; Tue, 25 Feb 2014 05:26:56 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 13:26:56 +0000 Message-ID: From: Dave Cridland To: Tobias Markmann Content-Type: multipart/alternative; boundary=089e01184baecf538c04f33b0ab2 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Tf7nUzQ1JnFOgf5DqnXcS75vxgM Cc: Ben Campbell , XMPP Working Group Subject: Re: [xmpp] End-to-End Encryption Milestone X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2014 13:26:59 -0000 --089e01184baecf538c04f33b0ab2 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 25, 2014 at 12:11 PM, Tobias Markmann wrote: > I think what's really needed is some kind of overview/comparison document > about that current status. While the current requirements document is a > start in listing some potential requirements, modern IM use cases are a bit > more complex, w.r.t. multi-device and the mobile application scenarios. > > So basically a document that compares existing proposals, like OTR, PGP, > XTLS and maybe even some more general e2e IM security solutions like the > TextSecure protocol or multi-party OTR, and analyze those regarding their > security, support for PubSub/MUC, support for offline messages, support for > multi-device usage, and possibly even more. > > That sounds really useful. I suspect that: a) Even quite experienced XMPP developers probably don't know what's on offer, and what they provide. b) It'd help focus discussion enormously, by enumerating the requirements properly. > On Tue, Feb 25, 2014 at 12:23 PM, Dave Cridland wrote: > >> Doing it within the XSF would *possibly* be simpler in terms of process. > > > Indeed. I don't know if the IETF is the right place for a status quo > comparison document or if it'd be more attractive within the XSF with less > process. I for one would gladly review and try to contribute as much as > possible to such document. Reviewing current proposals and exposing their > advantages and shortcomings, especially regarding multi-resource and > offline usage, would be a great way to start looking for possible solutions > for XMPP. > > A comparison document such as you're suggesting could probably be done as either; the process overhead isn't important either way. I suspect that longer term, it'd be nice to maintain it (unless we think we'll find the Final and Ultimate Solution to Encryption (FUSE), in which case it'll be only useful as a snapshot. If we want a "living document", then the XSF affords us that relatively easily, whereas if we did it as an I-D, I wouldn't press for publication as an RFC at all. In that sense, it'll be lower process within the IETF. Dave. --089e01184baecf538c04f33b0ab2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 25, 2014 at 12:11 PM, Tobias Markmann <tmarkmann@googlemail= .com> wrote:
=
I think what's really needed is some kind of= overview/comparison document about that current status. While the current = requirements document is a start in listing some potential requirements, mo= dern IM use cases are a bit more complex, w.r.t. multi-device and the mobil= e application scenarios.

So basicall= y a document that compares existing proposals, like OTR, PGP, XTLS and mayb= e even some more general e2e IM security solutions like the TextSecure prot= ocol or multi-party OTR, and analyze those regarding their security, suppor= t for PubSub/MUC, support for offline messages, support for multi-device us= age, and possibly even more.=A0

That sounds really useful. I suspect that:

a) Even quite experienced XMPP developers probably don't know wha= t's on offer, and what they provide.

b) It'd help focus discussion enormously, by enumer= ating the requirements properly.
=A0
On Tue, Feb 25, 2014 at 12:23 = PM, Dave Cridland <dave@cridland.net> wrote:
Doing it within the XSF would *possibly* be = simpler in terms of process.

Indeed. I don'= t know if the IETF is the right place for a status quo comparison document = or if it'd be more attractive within the XSF with less process. I for o= ne would gladly review and try to contribute as much as possible to such do= cument. Reviewing current proposals and exposing their advantages and short= comings, especially regarding multi-resource and offline usage, would be a = great way to start looking for possible solutions for XMPP.


A comparison document such as you're suggesting could probably b= e done as either; the process overhead isn't important either way. I su= spect that longer term, it'd be nice to maintain it (unless we think we= 'll find the Final and Ultimate Solution to Encryption (FUSE), in which= case it'll be only useful as a snapshot.

If we want a "living document", then the XSF = affords us that relatively easily, whereas if we did it as an I-D, I wouldn= 't press for publication as an RFC at all. In that sense, it'll be = lower process within the IETF.

Dave.
--089e01184baecf538c04f33b0ab2-- From nobody Wed Feb 26 11:51:43 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 248D71A06D5 for ; Wed, 26 Feb 2014 11:51:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIsjLPjk4LSF for ; Wed, 26 Feb 2014 11:51:31 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1141A067D for ; Wed, 26 Feb 2014 11:51:28 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1QJpPmU024272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 26 Feb 2014 13:51:27 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: Date: Wed, 26 Feb 2014 13:51:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <64A0097C-4798-47BF-80C8-FD509A393B60@nostrum.com> References: To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/cluS5SdllGddUTsCtpbQdktMQ54 Subject: Re: [xmpp] Draft Agenda X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 19:51:33 -0000 Oops, looks like I uploaded the agenda as "minutes" rather than = "agenda". The agenda is now available at the correct link: https://datatracker.ietf.org/meeting/89/agenda/xmpp/ Thanks! Ben. On Feb 14, 2014, at 3:19 PM, Ben Campbell wrote: > Hi Everyone, >=20 > The draft agenda for the IETF 89 XMPP meeting is available at the = following link. Please send any omissions or suggested changes to the = chairs and the mailing list. >=20 > http://www.ietf.org/proceedings/89/minutes/minutes-89-xmpp >=20 > Thanks! >=20 > Ben. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Wed Feb 26 13:28:23 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B98B1A07A9 for ; Wed, 26 Feb 2014 13:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdoCT3HXCzOo for ; Wed, 26 Feb 2014 13:28:14 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 72AC21A0798 for ; Wed, 26 Feb 2014 13:28:13 -0800 (PST) Received: from [192.168.0.101] (2.68.130.206.mobile.tre.se [2.68.130.206]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s1QLS7Ki001242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 26 Feb 2014 22:28:11 +0100 Message-ID: <530E5C61.1010000@goodadvice.pages.de> Date: Wed, 26 Feb 2014 22:28:01 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> In-Reply-To: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/IBEQw2WuJjbAm0OpR4gT1JSrElw Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:28:22 -0000 Am 04.02.2014 21:23, schrieb internet-drafts@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. [...] I've been prodded to give feedback again... overall, I (still) think the technique described solve the problem. The description still confuses me and I want to rewrite this from scratch, but lack the time to actually do this. In part, this confusion seems to be caused by the attempt to do both C2S and S2S. DNA is needed for both, but the document mostly describes S2S, which is the more complicated case. I think starting with a C2S scenario would be better. It's alot easier because only a single party does DNA. Explaining delegation and multi-tenancy is easier, too. I have a problem with the description of S2S. Bullet #6 in section 4 (as well as the flow chart) puts the creation of the association immediately after the TLS negotation. While authentication happens during/after the TLS handshake and the subsequent exchange of stream headers, there is an identity assertion step which is done either using SASL (EXTERNAL) or . IMO this is where the domain name association is created. And it gets alot easier to explain the need for stuff like piggybacking in subsequent sections. For C2S (or the client role of S2S), I actually agree that the client creates the association immediately after (or during) the TLS handshake, i.e. MUST check whether they like their counterparts authorization enough to continue. But clients have a concept of expected identity of the server (RFC 6125?) Servers, however, do not yet know who their counterpart is or wants to act as (assuming they discarded all information that was obtained in an insecure way before the TLS handshake). Additionally, there is no clear definition of what "A establishes DNA for B" actually means, which may be another source of confusion. It seems to be an entry in a list of "i know who this guy is"-domains which can then be used in dialback. However, so far I haven't felt a need to explicitly implement it that way, probably because most of the time a synchronus lookup in the list of domains contained in the cert was enough. DANE and POSH change that obviously. From nobody Wed Feb 26 13:41:31 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2E81A0696 for ; Wed, 26 Feb 2014 13:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u-qdu1dR9Gr for ; Wed, 26 Feb 2014 13:41:27 -0800 (PST) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 10E961A036D for ; Wed, 26 Feb 2014 13:41:26 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id i11so1543536oag.23 for ; Wed, 26 Feb 2014 13:41:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jbTVWyTr4wRPQEA5annWb11MO3+18jJS3a8ypxAUfjI=; b=G2GVxa93lOVcE+9gZhil+ubscx/+HmSdnanI3bpc8dkSUn3k0ljkgURvxFmyenCT/T 0a+OImtTv/rFDsCUX61UTaGZUuEgGIb02AYjrf4e0W+zJcfmxzRAX70qQTtUWLuCnNXz 6z+XrnW0HlBo07Bzq473YuaW2Nlj2pw4I20+Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jbTVWyTr4wRPQEA5annWb11MO3+18jJS3a8ypxAUfjI=; b=h+9PgztwWOwzUJrnfGzPgWKZk7Lg/H7/w7yxt++3CukwIztDOOxvneFIAmLu9WPGh7 ZnEPyS+Awn6DsK7MhlE0atAoyflZF90z9RW2VRMCQuc2D+HLc+LqYBkYazWXZOpbE1FQ nm2aOIdB1i5ds81uB1NO4LF+rLabA3YLhWmpIxmO7DpdIiP0Rszw1B/euuN+aBbCWrdK tmWgj/edQmf48MN3u88knvCLx+w3vaYc1f2OcSaLgT8Rz05yjUP+JqBUvZdzA2b1vsYm u7jmO7UX2xD3BxTkX6BBKK5BRF4BKhqnC8c1m3ahcCL8mQd4RuOd5ww7HE8U8Wuj6BE6 cG2Q== X-Gm-Message-State: ALoCoQnXIdtMzlNox3hq2az0ZNquFz1+MgJfeihKbblD06DDYyM+ec9sbq5W8XmoMj49656Gg/xD MIME-Version: 1.0 X-Received: by 10.182.104.101 with SMTP id gd5mr4778869obb.54.1393450885625; Wed, 26 Feb 2014 13:41:25 -0800 (PST) Received: by 10.60.55.197 with HTTP; Wed, 26 Feb 2014 13:41:25 -0800 (PST) In-Reply-To: <530E5C61.1010000@goodadvice.pages.de> References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> <530E5C61.1010000@goodadvice.pages.de> Date: Wed, 26 Feb 2014 21:41:25 +0000 Message-ID: From: Dave Cridland To: Philipp Hancke Content-Type: multipart/alternative; boundary=089e0115ec140ccee904f3561146 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/vZj3_jPLsF9WslnnsCDBUnaJOdM Cc: XMPP Working Group Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2014 21:41:28 -0000 --089e0115ec140ccee904f3561146 Content-Type: text/plain; charset=ISO-8859-1 On 26 February 2014 21:28, Philipp Hancke wrote: > While authentication happens during/after the TLS handshake and the > subsequent exchange of stream headers, there is an identity assertion step > which is done either using SASL (EXTERNAL) or . > I think this is actually an authorization step. WHich seems the right place for DNA to happen, yes. --089e0115ec140ccee904f3561146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2= 6 February 2014 21:28, Philipp Hancke <fippo@goodadvice.pages.de> wrote:
While authentication happens during/after th= e TLS handshake and the subsequent exchange of stream headers, there is an = identity assertion step which is done either using SASL (EXTERNAL) or <d= b:result/>.

I think this is actually an authorization = step. WHich seems the right place for DNA to happen, yes.=A0
--089e0115ec140ccee904f3561146-- From nobody Thu Feb 27 07:32:57 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431331A0300 for ; Thu, 27 Feb 2014 07:32:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBnW_2oOF47e for ; Thu, 27 Feb 2014 07:32:52 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 601611A02E0 for ; Thu, 27 Feb 2014 07:32:52 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1RFWgJq012064 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 09:32:44 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <530E5C61.1010000@goodadvice.pages.de> Date: Thu, 27 Feb 2014 09:32:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <9DE55A87-E46F-4DBC-B9CE-15EAB0A99045@nostrum.com> References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> <530E5C61.1010000@goodadvice.pages.de> To: Philipp Hancke X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/X5sT3xsaDC3tGdfLcw-ui4Fh_zE Cc: xmpp@ietf.org Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 15:32:55 -0000 (as co-chair) On Feb 26, 2014, at 3:28 PM, Philipp Hancke = wrote: > In part, this confusion seems to be caused by the attempt to do both = C2S and S2S. DNA is needed for both, but the document mostly describes = S2S, which is the more complicated case. >=20 > I think starting with a C2S scenario would be better. It's alot easier = because only a single party does DNA. Explaining delegation and = multi-tenancy is easier, too. That is probably because we are chartered for S2S, but not explicitly = for C2S. That doesn't prevent a solution that solves both, but we need = to solve S2S in order to claim victory.=20 If we agree that C2S is a better problem to solve, then we would need to = recharter for it. That's not a problem to do if we have reason. Thanks! Ben.= From nobody Thu Feb 27 08:20:58 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E61A02A1 for ; Thu, 27 Feb 2014 08:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yX6cv8KdSC3n for ; Thu, 27 Feb 2014 08:20:55 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9081A0316 for ; Thu, 27 Feb 2014 08:20:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1764; q=dns/txt; s=iport; t=1393518054; x=1394727654; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=D1q2y2JE8XncSwp6CVgskESsPpvcZY0hTnLxf6lJmTs=; b=al+EpgkwkbyAbphkqeqv8Sy3XdJ6ZJSul97vemySwbmNmfJSjdNPXyUd hENSJ1Nxv6kaylw6zvp7BUT844/NzYNl4GGxzTgCRf0o3iU83F8b5ubzx VNkkIZzw9AFTyOKWQTYiCw4LY5C9/2xG+NzOEXWT/4yr9NAJRyslnWOnq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoKAAxlD1OtJV2a/2dsb2JhbABagwY7V6gpBJhegRsWdIIlAQEBBHgBEAsYCRYPCQMCAQIBRQYBDAEFAgEBF4deywUXjiIzB4Q3AQOJEjiLA4NrkiqDTYIK X-IronPort-AV: E=Sophos;i="4.97,555,1389744000"; d="scan'208";a="23692524" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 27 Feb 2014 16:20:53 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1RGKrQB029408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 16:20:53 GMT Received: from jack.cisco.com (64.101.72.76) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Feb 2014 10:20:52 -0600 Message-ID: <530F65E4.4070405@cisco.com> Date: Thu, 27 Feb 2014 09:20:52 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell , Philipp Hancke References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> <530E5C61.1010000@goodadvice.pages.de> <9DE55A87-E46F-4DBC-B9CE-15EAB0A99045@nostrum.com> In-Reply-To: <9DE55A87-E46F-4DBC-B9CE-15EAB0A99045@nostrum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.76] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/rTlsBFCVmgnOyN4vl7F-MfFbjQo Cc: xmpp@ietf.org Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 16:20:57 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/27/14, 8:32 AM, Ben Campbell wrote: > (as co-chair) > > On Feb 26, 2014, at 3:28 PM, Philipp Hancke > wrote: > >> In part, this confusion seems to be caused by the attempt to do >> both C2S and S2S. DNA is needed for both, but the document mostly >> describes S2S, which is the more complicated case. >> >> I think starting with a C2S scenario would be better. It's alot >> easier because only a single party does DNA. Explaining >> delegation and multi-tenancy is easier, too. > > That is probably because we are chartered for S2S, but not > explicitly for C2S. That doesn't prevent a solution that solves > both, but we need to solve S2S in order to claim victory. > > If we agree that C2S is a better problem to solve, then we would > need to recharter for it. That's not a problem to do if we have > reason. > I don't think the suggestion is to abandon (for now) the S2S case, but to show the C2S case first because there's a lot fewer moving parts. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTD2XkAAoJEDWi+S0W7cO11QsIAJlLfOkQJwK1DsAmgOCmsRCp AjUGEaLiCv/5ffHW9VeqOLn0/LmPGzctFHjezeTVPQhCSVipBvvcxZcG72VtWsF/ o9Z6lQwDcgVxNBouRczFphxAVLAtOR3UQ60U0jLmSPbs2OiiIKUDzawCGYHxos4j 0G+V2DEywFBEVInT9NomcbmBRnjh54jjCQ6E5NXcc3TrOL7a7rECToiMOpBWTy5o 0YlphD9jJwcMoe3Ph6efI19BN0BMjh0MqgJvbnMES3VqhS3ujKKJp2QpAR/Heypx S2EGFXmRPfSjParRUzquJc1T/BuqUIxy6/fUh3Jn6xL7R8yC8wPb2dM58OeQWmI= =F5UX -----END PGP SIGNATURE----- From nobody Thu Feb 27 10:07:37 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB7F1A0382 for ; Thu, 27 Feb 2014 10:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xogb876DDk08 for ; Thu, 27 Feb 2014 10:07:32 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AF90F1A02A1 for ; Thu, 27 Feb 2014 10:07:32 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8B07840410; Thu, 27 Feb 2014 11:07:30 -0700 (MST) Message-ID: <530F7EE2.1090404@stpeter.im> Date: Thu, 27 Feb 2014 11:07:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <64A0097C-4798-47BF-80C8-FD509A393B60@nostrum.com> In-Reply-To: <64A0097C-4798-47BF-80C8-FD509A393B60@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/dSUg50UwWp39i_BruMKNrTVBHnc Subject: Re: [xmpp] Draft Agenda X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:07:36 -0000 On 2/26/14, 12:51 PM, Ben Campbell wrote: > Oops, looks like I uploaded the agenda as "minutes" rather than "agenda". The agenda is now available at the correct link: > > https://datatracker.ietf.org/meeting/89/agenda/xmpp/ Thanks, Ben! Would it be possible to add information about remote participation? I've encouraged several WebSocket developers to provide feedback on the list or remotely during the meeting, so the Meetecho coordinates would be helpful. See you soon, Peter From nobody Thu Feb 27 10:11:59 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E05B1A015A for ; Thu, 27 Feb 2014 10:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgOoMi-6xhsT for ; Thu, 27 Feb 2014 10:11:51 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6C51A019B for ; Thu, 27 Feb 2014 10:11:51 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C6D21403BB; Thu, 27 Feb 2014 11:11:49 -0700 (MST) Message-ID: <530F7FE5.6010402@stpeter.im> Date: Thu, 27 Feb 2014 11:11:49 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/nghQn5Fxv_CceTBMNGz9fM7laDg Subject: [xmpp] draft WebSocket slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:11:58 -0000 Lance and I have drafted some slides for the discussion about XMPP Over WebSocket: https://stpeter.im/files/ietf89-xmpp-websocket.pdf The final slide on implementation status is a moving target since we're still hearing from developers about their schedules for updating code, so it might change before Tuesday. Feedback is welcome as always. :-) Peter -- Peter Saint-Andre https://stpeter.im/ From nobody Thu Feb 27 10:16:20 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD141A019B for ; Thu, 27 Feb 2014 10:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd4aCqaizkCM for ; Thu, 27 Feb 2014 10:16:17 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5431A015A for ; Thu, 27 Feb 2014 10:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1393524976; x=1394734576; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=i6z4CkvVQoSlo7m0lTXgub0VqtN2nnxxw2w0CQy4tWs=; b=eZ0I6OZfJa3h/48pe4VKqassAfwNAFPSLPSzXhTx0/PA4XKGnCGBDTjO OOEfISCMJhLZy1BXJyHJ2aqf2H7dOcx+KvCU6I3aPODQB7OYYYkS9GKd/ KxGc9URITg/xcbxDR2x23zKif9WbVVORjFCWYE3ZQBowm25q+5EsTXzLd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsRAOp/D1OtJV2c/2dsb2JhbABaFoJwO1eoKQQGmXUWdIIqej0WGAMCAQIBSw0GAgEBh3UNmmqwDheOAYUSBIkSOI5ukiqDTYIK X-IronPort-AV: E=Sophos;i="4.97,556,1389744000"; d="scan'208";a="23715304" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP; 27 Feb 2014 18:16:15 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1RIGFXj024599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Feb 2014 18:16:15 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.73) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Feb 2014 12:16:14 -0600 Message-ID: <530F80ED.5080400@cisco.com> Date: Thu, 27 Feb 2014 11:16:13 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP Group X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.73] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/3lAHGC5_Ff2DVLM_yrFrCNTOtaI Subject: [xmpp] Slides for IETF 89 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:16:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (One set of) My slides for our session are at < https://outer-planes.net/~linuxwolf/ietf/ietf89-xmppwg-dna.pdf >. Feedback is welcome. See you in London! - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTD4DtAAoJEDWi+S0W7cO1sMwH/2P8h3JtBgP/u8KMzbZ7Ozsr rPwmHviQbd+fks7UA5UWb/puiV6l6TfBaGe4VWys+6ijcShZWfR9n26SHW5WU0uo 9WhjH26ODHi2ajNke7KXaLffKGCi6ggsDoQtms8pZvObPmP47URBCoj8h919L6RT BKDXU8Rn1Hn+m/aKmGC/tFwVyYCBWFqk9tmr+/xvTWdahqjvEUUb9/TlbJ91yHbq 4+C+41IFFjIhLsoskJ6kY3ORoMu/DNyhDX29NFYKUlcQ/JGuQ2MV5NqLWe+rRLkr 0iuGmCvohjkudhvkzwEAgG+YsSzpeikt9e5wcoDeruj7AW2fdmz/e4sy1XU8qGQ= =w2B8 -----END PGP SIGNATURE----- From nobody Thu Feb 27 10:21:30 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F961A00B8 for ; Thu, 27 Feb 2014 10:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmw9kE3cV6ui for ; Thu, 27 Feb 2014 10:21:27 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 108A01A01AC for ; Thu, 27 Feb 2014 10:21:27 -0800 (PST) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8AEAE403BB; Thu, 27 Feb 2014 11:21:25 -0700 (MST) Message-ID: <530F8225.2020307@stpeter.im> Date: Thu, 27 Feb 2014 11:21:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Matt Miller , XMPP Group References: <530F80ED.5080400@cisco.com> In-Reply-To: <530F80ED.5080400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/nI8Son83QXgBu7m5OpRVPfYSFkE Subject: Re: [xmpp] Slides for IETF 89 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 18:21:28 -0000 Love those photos. :-) On 2/27/14, 11:16 AM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > (One set of) My slides for our session are at < > https://outer-planes.net/~linuxwolf/ietf/ietf89-xmppwg-dna.pdf >. > Feedback is welcome. > > See you in London! > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTD4DtAAoJEDWi+S0W7cO1sMwH/2P8h3JtBgP/u8KMzbZ7Ozsr > rPwmHviQbd+fks7UA5UWb/puiV6l6TfBaGe4VWys+6ijcShZWfR9n26SHW5WU0uo > 9WhjH26ODHi2ajNke7KXaLffKGCi6ggsDoQtms8pZvObPmP47URBCoj8h919L6RT > BKDXU8Rn1Hn+m/aKmGC/tFwVyYCBWFqk9tmr+/xvTWdahqjvEUUb9/TlbJ91yHbq > 4+C+41IFFjIhLsoskJ6kY3ORoMu/DNyhDX29NFYKUlcQ/JGuQ2MV5NqLWe+rRLkr > 0iuGmCvohjkudhvkzwEAgG+YsSzpeikt9e5wcoDeruj7AW2fdmz/e4sy1XU8qGQ= > =w2B8 > -----END PGP SIGNATURE----- > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > From nobody Thu Feb 27 13:06:46 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AE21A069E for ; Thu, 27 Feb 2014 13:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yM_9-oWeXclE for ; Thu, 27 Feb 2014 13:06:43 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8E1A0698 for ; Thu, 27 Feb 2014 13:06:42 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1RL6VDk038687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Feb 2014 15:06:33 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <530F8225.2020307@stpeter.im> Date: Thu, 27 Feb 2014 15:06:31 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <97E3B63D-AC5C-47BF-825F-D38E5829155E@nostrum.com> References: <530F80ED.5080400@cisco.com> <530F8225.2020307@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/tWOPbxqv1wx9BHNR8kOuH0P4mbg Cc: XMPP Group Subject: Re: [xmpp] Slides for IETF 89 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 21:06:45 -0000 On Feb 27, 2014, at 12:21 PM, Peter Saint-Andre = wrote: > Love those photos. :-) >=20 I'm not entirely sure the pic on slide 7 really evokes "approachable by = humans" :-) > On 2/27/14, 11:16 AM, Matt Miller wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >>=20 >> (One set of) My slides for our session are at < >> https://outer-planes.net/~linuxwolf/ietf/ietf89-xmppwg-dna.pdf >. >> Feedback is welcome. >>=20 >> See you in London! >>=20 >>=20 >> - -- >> - - m&m >>=20 >> Matt Miller < mamille2@cisco.com > >> Cisco Systems, Inc. >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >> Comment: GPGTools - https://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >>=20 >> iQEcBAEBCgAGBQJTD4DtAAoJEDWi+S0W7cO1sMwH/2P8h3JtBgP/u8KMzbZ7Ozsr >> rPwmHviQbd+fks7UA5UWb/puiV6l6TfBaGe4VWys+6ijcShZWfR9n26SHW5WU0uo >> 9WhjH26ODHi2ajNke7KXaLffKGCi6ggsDoQtms8pZvObPmP47URBCoj8h919L6RT >> BKDXU8Rn1Hn+m/aKmGC/tFwVyYCBWFqk9tmr+/xvTWdahqjvEUUb9/TlbJ91yHbq >> 4+C+41IFFjIhLsoskJ6kY3ORoMu/DNyhDX29NFYKUlcQ/JGuQ2MV5NqLWe+rRLkr >> 0iuGmCvohjkudhvkzwEAgG+YsSzpeikt9e5wcoDeruj7AW2fdmz/e4sy1XU8qGQ=3D >> =3Dw2B8 >> -----END PGP SIGNATURE----- >>=20 >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >>=20 >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Thu Feb 27 14:13:51 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48E1A015E for ; Thu, 27 Feb 2014 14:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xZPZz5srMMKt for ; Thu, 27 Feb 2014 14:13:48 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id DBF061A0131 for ; Thu, 27 Feb 2014 14:13:47 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wo20so765120obc.36 for ; Thu, 27 Feb 2014 14:13:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LdlGGiggawudlMyz0ijKuT4YVJRMNxN/3tpYanyUcek=; b=LChOX97Nq1h5OcfC9YrJ4fJtHY54vMj9fkbZG2WNsNtyrkfmcf1T6d0/KDwdB3sqtW Y0W13jKFVGV0P2M0/u/LkgPxb8T+YPJAyAikrh6D6NFcPY8S6dEJWKLFUYzVsI6xE185 iPqQ8MjpuQRarlXsRkbuMn7GJkkE+cFPBIpQg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LdlGGiggawudlMyz0ijKuT4YVJRMNxN/3tpYanyUcek=; b=S++zZ5R3Uz6z5FdSN87nDyaNzIPsUOVB4k3VyJrKaSqrKN1jlDyreWMssd5knupkge 9ikokMPYp90G/HEfWKcnyyQRxWkc7dqdKMoBOICtdD1l9uWnBdgqvCJKSr6oYteBEosF 4VE27GmPtfi2PYIOC+9pyCPBapAdOlTbIMZzOnC6wTjZWmP3jQsvvPqQDwzWnKvZLOKr xIcWo8BHOuWFRz22NNZ9n55qwfmPje+1CiM6OS2u/RZ7orrkcIVRHCi/dlQC9visKqW8 TQ0C3qwP1ObIYP6F0wmGU2vmoM6JA94rUYzrW4wiLJP5IvntzuvI9q770vTxGPKmM7OY 2cEA== X-Gm-Message-State: ALoCoQmXfPEJirEOj9POVnFzl94qU1I1F1B9lGBU18Xs2fPw6hLcT+cOT5rHxigXM3lO7nZOGMZM MIME-Version: 1.0 X-Received: by 10.60.227.39 with SMTP id rx7mr9892993oec.52.1393539226142; Thu, 27 Feb 2014 14:13:46 -0800 (PST) Received: by 10.60.70.146 with HTTP; Thu, 27 Feb 2014 14:13:46 -0800 (PST) In-Reply-To: <97E3B63D-AC5C-47BF-825F-D38E5829155E@nostrum.com> References: <530F80ED.5080400@cisco.com> <530F8225.2020307@stpeter.im> <97E3B63D-AC5C-47BF-825F-D38E5829155E@nostrum.com> Date: Thu, 27 Feb 2014 22:13:46 +0000 Message-ID: From: Dave Cridland To: Ben Campbell Content-Type: multipart/alternative; boundary=001a1136b8068e27d604f36aa2c7 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/YJmilsxLeYPwnK7_lnqJPQSmld0 Cc: XMPP Group Subject: Re: [xmpp] Slides for IETF 89 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:13:49 -0000 --001a1136b8068e27d604f36aa2c7 Content-Type: text/plain; charset=ISO-8859-1 On 27 February 2014 21:06, Ben Campbell wrote: > On Feb 27, 2014, at 12:21 PM, Peter Saint-Andre > wrote: > > > Love those photos. :-) > > > > I'm not entirely sure the pic on slide 7 really evokes "approachable by > humans" :-) > > #5 made me realise why I've never really liked POSH much. And #8 confuses me - I must have entirely missed Michael Jackson's drag phase. --001a1136b8068e27d604f36aa2c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 2= 7 February 2014 21:06, Ben Campbell <ben@nostrum.com> wrote:
On Feb 27, 2014, at 12:21 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:

> Love those photos. :-)
>

I'm not entirely sure the pic on slide 7 really evokes "approachab= le by humans" :-)

<= br>
#5 made me realise why I've never really liked POSH much.=

And #8 confuses me - I must have entirely missed = Michael Jackson's drag phase.=A0
--001a1136b8068e27d604f36aa2c7-- From nobody Thu Feb 27 14:24:29 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D31A02BB for ; Thu, 27 Feb 2014 14:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voF3l51v1ZYh for ; Thu, 27 Feb 2014 14:24:25 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 455D61A0293 for ; Thu, 27 Feb 2014 14:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1422; q=dns/txt; s=iport; t=1393539864; x=1394749464; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=/i9i5DKhIuK5fX+T+S5BjnnHf9lagfL95UTa94tArLM=; b=evMGF8QPN2IxzBX48QhBmySMkXS1++E1eVP/4mtij4CPkgBURhz+rigD epE7GL6SYars/b7S7yQO3XC+5NHSpIZqhP54tODe6i+z6JQN73vYypaj0 ZjH8ds2TaWoah+n5D8SutEcXZcqKAycoNsGflaaGZETirbrRuAssyD5Rn I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoNAA26D1OtJV2a/2dsb2JhbABagwY7V6guBIJHlheBHhZ0giUBAQEDAXMFAQULCxgJFggHCQMCAQIBNBEGAQwBBQIBAYdtCMtLF44iMweENwEDiRI4jm6SKoNNggo X-IronPort-AV: E=Sophos;i="4.97,557,1389744000"; d="scan'208";a="307056667" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 27 Feb 2014 22:24:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1RMON64020428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Feb 2014 22:24:23 GMT Received: from MAMILLE2-M-T03K.local (10.129.24.73) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Feb 2014 16:24:22 -0600 Message-ID: <530FBB16.5070809@cisco.com> Date: Thu, 27 Feb 2014 15:24:22 -0700 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dave Cridland , Ben Campbell References: <530F80ED.5080400@cisco.com> <530F8225.2020307@stpeter.im> <97E3B63D-AC5C-47BF-825F-D38E5829155E@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.129.24.73] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/edOVU4c_JbP0jSIgIJxYoywcNgM Cc: XMPP Group Subject: Re: [xmpp] Slides for IETF 89 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:24:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/27/14, 3:13 PM, Dave Cridland wrote: > On 27 February 2014 21:06, Ben Campbell > wrote: > > On Feb 27, 2014, at 12:21 PM, Peter Saint-Andre > > wrote: > >> Love those photos. :-) >> > > I'm not entirely sure the pic on slide 7 really evokes > "approachable by humans" :-) > > > #5 made me realise why I've never really liked POSH much. > Then tell me what you want, what you really really want. (-: > And #8 confuses me - I must have entirely missed Michael Jackson's > drag phase. > > #8 is Linda Richman of Coffee Talk, played by Mike Myers. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTD7sWAAoJEDWi+S0W7cO1wbsH/i1cvxsBWgH+fRlFufw+Jo4s 8et5N/8MFVy4PTi/4EIasKdfwYaCUBXJD9ZdgIb+ZHP7JuV9M4NyxD+k6cWEWfFh cHkAPR/wh+SInCHdPlQ1UmEqlHGvvYmYuCg3eyaqzHMWExG+642VHXRY/8mGJAqK GnYI5ZaUrkwXtlPC68N8r6MJ1HUqaoj/5g0rnABSD49Doa3sOSvEM1GLJypt+UFj u7w1TPPGc8C9bEh4I1+5I46jLp/YAQWTL1crZ4Z3Zm6aeQYXj/M6E/P3Xyp+bbN+ IIzRZdUHxjsm48TLwq0aYCzpL72jlBmXiqI1R5rSZT0JCDPv0TdmFcpQ3gotJ0w= =TgOL -----END PGP SIGNATURE----- From nobody Thu Feb 27 14:26:22 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03751A069E for ; Thu, 27 Feb 2014 14:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-QZh5mziNfG for ; Thu, 27 Feb 2014 14:26:20 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9822C1A0393 for ; Thu, 27 Feb 2014 14:26:19 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id va2so3054544obc.37 for ; Thu, 27 Feb 2014 14:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pkRaWD4MQ6Xbdips0PmGJfj0V16FKGvqJ3KkZ7a3ICU=; b=kdmM97RCP6CrBFovklxVHKSQHzgqX+EBQwEloLzocLkCYaNKxm4Z4BCCzyNA9/wyoo Qvf0Hg8Jn9mKlghLVdRj6YcmrhX2vwU1b+1iDt7bGfkYkErBVIX1vsWP4C8+JyHAbmiH WENUOZRTByk3ikEyWj0eJRjpCqt8XkJBEkkew= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pkRaWD4MQ6Xbdips0PmGJfj0V16FKGvqJ3KkZ7a3ICU=; b=DnONFz+I9eRTw31VmRuCZG7I0vxQCn/650SSuoeIc17q5gxQeunY8g9KFhmM+8ofKY wIPpuPGexNTclEsmzNvDYp1DDj2oIFSKnGlmxUOKx+SO2d1K3oT3GjVWGJWwemGw9p6m cHYhxnc1lk0X0bgNeOfCbModzJX/v31GvDq+x9Ds5jWouLotNy0g3TiqCyrbp6x/4RkT wTPyLGlbKj8kz1gkuNiNxhmXTR4+TblI8HzO/TOyK+MsxLE3U8zyJLHjOgUN5xT3ORvZ uvOTxk82LVacLwe+1StusrzvDTVgU9O03Pf8dazgtxXEOYDTXXK8f1JeW7BwnCGqt3Tk 9vYg== X-Gm-Message-State: ALoCoQmQtvzCXlvokevfSIJNFOAVByoaxfMJi3/G8JA1Yf1lrZMRpaWTM8RCbuqz+tL9Kt7pqWxe MIME-Version: 1.0 X-Received: by 10.60.116.74 with SMTP id ju10mr13985861oeb.6.1393539977938; Thu, 27 Feb 2014 14:26:17 -0800 (PST) Received: by 10.60.70.146 with HTTP; Thu, 27 Feb 2014 14:26:17 -0800 (PST) In-Reply-To: <530FBB16.5070809@cisco.com> References: <530F80ED.5080400@cisco.com> <530F8225.2020307@stpeter.im> <97E3B63D-AC5C-47BF-825F-D38E5829155E@nostrum.com> <530FBB16.5070809@cisco.com> Date: Thu, 27 Feb 2014 22:26:17 +0000 Message-ID: From: Dave Cridland To: Matt Miller Content-Type: multipart/alternative; boundary=089e0116150a5d9aac04f36acfc2 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/XKRZl9xfe8Y3xv7tAflZwhcXgg4 Cc: Ben Campbell , XMPP Group Subject: Re: [xmpp] Slides for IETF 89 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2014 22:26:21 -0000 --089e0116150a5d9aac04f36acfc2 Content-Type: text/plain; charset=ISO-8859-1 On 27 February 2014 22:24, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2/27/14, 3:13 PM, Dave Cridland wrote: > > On 27 February 2014 21:06, Ben Campbell > > wrote: > > > > On Feb 27, 2014, at 12:21 PM, Peter Saint-Andre > > > wrote: > > > >> Love those photos. :-) > >> > > > > I'm not entirely sure the pic on slide 7 really evokes > > "approachable by humans" :-) > > > > > > #5 made me realise why I've never really liked POSH much. > > > > Then tell me what you want, what you really really want. (-: > Careful, or I'll come up with a counter-proposal called zig-a-zig-ah. > > > And #8 confuses me - I must have entirely missed Michael Jackson's > > drag phase. > > > > > > #8 is Linda Richman of Coffee Talk, played by Mike Myers. > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTD7sWAAoJEDWi+S0W7cO1wbsH/i1cvxsBWgH+fRlFufw+Jo4s > 8et5N/8MFVy4PTi/4EIasKdfwYaCUBXJD9ZdgIb+ZHP7JuV9M4NyxD+k6cWEWfFh > cHkAPR/wh+SInCHdPlQ1UmEqlHGvvYmYuCg3eyaqzHMWExG+642VHXRY/8mGJAqK > GnYI5ZaUrkwXtlPC68N8r6MJ1HUqaoj/5g0rnABSD49Doa3sOSvEM1GLJypt+UFj > u7w1TPPGc8C9bEh4I1+5I46jLp/YAQWTL1crZ4Z3Zm6aeQYXj/M6E/P3Xyp+bbN+ > IIzRZdUHxjsm48TLwq0aYCzpL72jlBmXiqI1R5rSZT0JCDPv0TdmFcpQ3gotJ0w= > =TgOL > -----END PGP SIGNATURE----- > --089e0116150a5d9aac04f36acfc2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 27 February 2014 22:24, Matt Miller <mamille2@cisco.com>= ; wrote:
-----BEGIN PGP SIGNED MESSAG= E-----
Hash: SHA512

On 2/27/14, 3:13 PM, Dave Cridland wrote:
> On 27 February 2014 21:06, Ben Campbell <ben@nostrum.com
> <mailto:be= n@nostrum.com>> wrote:
>
> On Feb 27, 2014, at 12:21 PM, Peter Saint-Andre
> <stpete= r@stpeter.im <mailto:stpeter@s= tpeter.im>> wrote:
>
>> Love those photos. :-)
>>
>
> I'm not entirely sure the pic on slide 7 really evokes
> "approachable by humans" :-)
>
>
> #5 made me realise why I've never really liked POSH much.
>

Then tell me what you want, what you really really want. (-:

Careful, or I'll come up with a counter-pro= posal called zig-a-zig-ah.
=A0

> And #8 confuses me - I must have entirely missed Michael Jackson's=
> drag phase.
>
>

#8 is Linda Richman of Coffee Talk, played by Mike Myers.


- --
- - m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http= s://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTD7sWAAoJEDWi+S0W7cO1wbsH/i1cvxsBWgH+fRlFufw+Jo4s
8et5N/8MFVy4PTi/4EIasKdfwYaCUBXJD9ZdgIb+ZHP7JuV9M4NyxD+k6cWEWfFh
cHkAPR/wh+SInCHdPlQ1UmEqlHGvvYmYuCg3eyaqzHMWExG+642VHXRY/8mGJAqK
GnYI5ZaUrkwXtlPC68N8r6MJ1HUqaoj/5g0rnABSD49Doa3sOSvEM1GLJypt+UFj
u7w1TPPGc8C9bEh4I1+5I46jLp/YAQWTL1crZ4Z3Zm6aeQYXj/M6E/P3Xyp+bbN+
IIzRZdUHxjsm48TLwq0aYCzpL72jlBmXiqI1R5rSZT0JCDPv0TdmFcpQ3gotJ0w=3D
=3DTgOL
-----END PGP SIGNATURE-----

--089e0116150a5d9aac04f36acfc2-- From nobody Fri Feb 28 12:57:20 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337991A034D for ; Fri, 28 Feb 2014 12:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al-tp43QgLZK for ; Fri, 28 Feb 2014 12:57:17 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id B52471A033F for ; Fri, 28 Feb 2014 12:57:17 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s1SKvE1T056245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 28 Feb 2014 14:57:15 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <64A0097C-4798-47BF-80C8-FD509A393B60@nostrum.com> Date: Fri, 28 Feb 2014 14:57:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <95DFA808-8719-4B06-B27F-211F337C2235@nostrum.com> References: <64A0097C-4798-47BF-80C8-FD509A393B60@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/v9X0dB4LIz14BhGCF4lbaMiH25M Subject: [xmpp] Remote Access for XMPP Meeting X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 20:57:19 -0000 Hi, Here are the remote access links for the XMPP meeting next week. I've = also added these to the online agenda page. Meetecho: http://www.meetecho.com/ietf89/xmpp XMPP: xmpp@jabber.ietf.org Thanks! Ben. On Feb 26, 2014, at 1:51 PM, Ben Campbell wrote: > Oops, looks like I uploaded the agenda as "minutes" rather than = "agenda". The agenda is now available at the correct link: >=20 > https://datatracker.ietf.org/meeting/89/agenda/xmpp/ >=20 > Thanks! >=20 > Ben. >=20 > On Feb 14, 2014, at 3:19 PM, Ben Campbell wrote: >=20 >> Hi Everyone, >>=20 >> The draft agenda for the IETF 89 XMPP meeting is available at the = following link. Please send any omissions or suggested changes to the = chairs and the mailing list. >>=20 >> http://www.ietf.org/proceedings/89/minutes/minutes-89-xmpp >>=20 >> Thanks! >>=20 >> Ben. >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >=20