From psaintan@cisco.com Fri Feb 1 00:12:11 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4496421F8599 for ; Fri, 1 Feb 2013 00:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mJj3EzbMlFD for ; Fri, 1 Feb 2013 00:12:10 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id A7AD521F8433 for ; Fri, 1 Feb 2013 00:12:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=989; q=dns/txt; s=iport; t=1359706330; x=1360915930; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Au6IdPo+IqIwxeQ7ZhJUT2VcqpGFW3xgobOK8qGgABA=; b=direPFRVltsOcP0n9zL2XL4S9jH+lS155eXLoM9AmR/T44srBjjTCBC6 c+ITpAbqAA5lpmbWvACo4bUhqP41Ik1j3ovC3VY7/YLDy9bOXVkxzeDEq t0w3r9yrTWXCkMKBfqKTuYdEhgLlSGmf0LUuTMQ7WYwVQy3nVnJsxtRAn o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFADV3C1GtJV2Y/2dsb2JhbABFhgG5IxZzgh4BAQEDAQEBAWsLBQsCAQhGJwslAgQOBYgLBgzCIQSQK2EDiC+KMYM0kE6Cew X-IronPort-AV: E=Sophos;i="4.84,579,1355097600"; d="scan'208";a="171604260" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 01 Feb 2013 08:12:10 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r118CA8B030231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Feb 2013 08:12:10 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.138]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 1 Feb 2013 02:12:10 -0600 From: "Peter Saint-Andre (psaintan)" To: "Joe Hildebrand (jhildebr)" Thread-Topic: [xmpp] i18n feedback needed Thread-Index: AQHOAFPUw89K1A1KWUmmLdjz8mrfyg== Date: Fri, 1 Feb 2013 08:12:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 01 Feb 2013 04:32:06 -0800 Cc: XMPP Working Group Subject: Re: [xmpp] i18n feedback needed X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 08:12:11 -0000 Indeed. An IETF last call on the nickname spec is still forthcoming so it i= s not too late for feedback on that document which is the first one to move= forward.=20 Sent from mobile, might be terse=20 On Jan 31, 2013, at 12:31 PM, "Joe Hildebrand (jhildebr)" wrote: > Responding to Kev's request at the XMPP Summit that we have a thread to > talk about Prec=EDs, here are the IDs in Peter's slide that you should > review as soon as possible: >=20 > draft-ietf-precis-framework > draft-ietf-precis-nicname > draft-ietf-xmpp-6122bis > draft-melnikov-precis-saslprepbis >=20 > Of these, draft-ietf-xmpp-6122bis is the one that is on our charter here, > but the others need to be reviewed and commented upon in order to make > sure that 6122bis is correct. >=20 > --=20 > Joe Hildebrand >=20 >=20 >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From ag@ag-projects.com Mon Feb 4 07:21:32 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F221F88C4 for ; Mon, 4 Feb 2013 07:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEkj7OReVQZH for ; Mon, 4 Feb 2013 07:21:32 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5950821F8818 for ; Mon, 4 Feb 2013 07:21:32 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id BE047B35E3; Mon, 4 Feb 2013 16:21:31 +0100 (CET) Received: from ag-retina.fritz.box (xs4all.dns-hosting.info [82.161.39.123]) by mail.sipthor.net (Postfix) with ESMTPSA id D149FB0067 for ; Mon, 4 Feb 2013 16:21:30 +0100 (CET) From: Adrian Georgescu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Feb 2013 16:21:37 +0100 Message-Id: <92CD4353-64BE-4C7E-B4F6-06693473DCAA@ag-projects.com> To: xmpp@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [xmpp] Feedback for SIMPLE/MSRP to XMPP interoperability X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:21:33 -0000 Hello, By implementing the draft specifications for SIMPLE/MSRP to XMPP and = MSRP-switch to MUC gateway we discovered several issues that we needed = to tackle differently or were not addressed at all at the moment of = their writing. The drafts I am referring to are: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-01 = http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-presence-02.html= http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html = http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-groupchat-01.htm= l As there are many comments, we made a web page to summarize them as best = as we could. http://sylkserver.ag-projects.com/projects/sylkserver/wiki/XMPP-Interop The software implementing these drafts is now available in the public = domain. I hope this feedback can be used to continue and finalize the = standardization works started in those drafts. I am not sure which WG is = the best place for this, so I mailed all three I am aware of. Regards, Adrian From ag@ag-projects.com Mon Feb 4 05:08:23 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDE21F85B1; Mon, 4 Feb 2013 05:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.129 X-Spam-Level: X-Spam-Status: No, score=-0.129 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piq5oXXvbdyl; Mon, 4 Feb 2013 05:08:22 -0800 (PST) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 897A721F84E0; Mon, 4 Feb 2013 05:08:13 -0800 (PST) Received: by mail.sipthor.net (Postfix, from userid 5001) id D85ABB35E2; Mon, 4 Feb 2013 14:08:11 +0100 (CET) Received: from ag-retina.fritz.box (xs4all.dns-hosting.info [82.161.39.123]) by mail.sipthor.net (Postfix) with ESMTPSA id 6906CB35E0; Mon, 4 Feb 2013 14:08:10 +0100 (CET) From: Adrian Georgescu Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Feb 2013 14:08:11 +0100 Message-Id: <67896036-9CE7-427A-9D15-3B75C76CE829@ag-projects.com> To: xmpp@ietf.org, dispatch@ietf.org, simple@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Mailman-Approved-At: Thu, 07 Feb 2013 09:04:11 -0800 Subject: [xmpp] Feedback for SIMPLE/MSRP to XMPP interoperability X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 13:08:23 -0000 Hello, By implementing the draft specifications for SIMPLE/MSRP to XMPP and = MSRP-switch to MUC gateway we discovered several issues that we needed = to tackle differently or were not addressed at all at the moment of = their writing. The drafts I am referring to are: http://tools.ietf.org/html/draft-saintandre-sip-xmpp-core-01 = http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-presence-02.html= http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-im-01.html http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-chat-03.html = http://xmpp.org/internet-drafts/draft-saintandre-sip-xmpp-groupchat-01.htm= l As there are many comments, we made a web page to summarize them as best = as we could. http://sylkserver.ag-projects.com/projects/sylkserver/wiki/XMPP-Interop The software implementing these drafts is now available in the public = domain. I hope this feedback can be used to continue and finalize the = standardization works started in those drafts. I am not sure which WG is = the best place for this, so I mailed all three I am aware of. Regards, Adrian =20 =20= From mamille2@cisco.com Tue Feb 12 08:13:51 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C13A21F8F31 for ; Tue, 12 Feb 2013 08:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1WKqrqx+vUz for ; Tue, 12 Feb 2013 08:13:50 -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 41ADA21F8EEF for ; Tue, 12 Feb 2013 08:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5165; q=dns/txt; s=iport; t=1360685630; x=1361895230; h=from:to:subject:date:message-id:references:mime-version; bh=nhurL1tA8gCRAUiwFocnUshgWCXDvpc9YM+sGop7dLE=; b=GcXy8OhDnmKIWd+L4Pm2KyTAAoBgYWAYkxwclBQfSvUDgjS4DpG8NOli R4O9fIaPIfJzNajHX22ThEle64unTN0VpOfp0HggAe5rRpORioPycmTRz yTgNprW3dciEhGuZVlHMor+XyawMzlxGJKXXGY8P7dOwpJNniv4Wdg+TW U=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAPdpGlGtJXHA/2dsb2JhbABEg3m9QhZzgh8BAQEDAQEBAWsQCwIBGQMBAgskAiULFAcCCAIEEwgBBYd+BgcFrxaQE5EkYQOPFYElhweKJoUQgwaCJw X-IronPort-AV: E=Sophos;i="4.84,650,1355097600"; d="p7s'?scan'208";a="176233206" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 12 Feb 2013 16:13:40 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1CGDeX6027015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Feb 2013 16:13:40 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 12 Feb 2013 10:13:40 -0600 From: "Matt Miller (mamille2)" To: XMPP Working Group Thread-Topic: I-D Action: draft-miller-xmpp-e2e-04.txt Thread-Index: AQHOCTsk6YRy22Fs0EWcVUREVfpD6g== Date: Tue, 12 Feb 2013 16:13:40 +0000 Message-ID: References: <20130212160739.26338.96092.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: multipart/signed; boundary="Apple-Mail=_02B152A1-3673-4A4B-8153-A80C1530ACD0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [xmpp] Fwd: I-D Action: draft-miller-xmpp-e2e-04.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:13:51 -0000 --Apple-Mail=_02B152A1-3673-4A4B-8153-A80C1530ACD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Updated to use an approach at JOSE standalone key protection. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. Begin forwarded message: > From: > Subject: I-D Action: draft-miller-xmpp-e2e-04.txt > Date: February 12, 2013 9:07:39 AM MST > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : End-to-End Object Encryption for the = Extensible Messaging and Presence Protocol (XMPP) > Author(s) : Matthew Miller > Filename : draft-miller-xmpp-e2e-04.txt > Pages : 27 > Date : 2013-02-12 >=20 > Abstract: > This document defines a method of end-to-end object encryption for > the Extensible Messaging and Presence Protocol (XMPP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-miller-xmpp-e2e-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-04 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 --Apple-Mail=_02B152A1-3673-4A4B-8153-A80C1530ACD0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDIxMjE2MTM0MFowIwYJKoZIhvcNAQkEMRYEFK2pFHDF+newouIkesWdlAIzzzJaMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQACFwZ4eqawkmeyntQhdUBFPyVX96lGmRK14RrESUZj 5zvjUZPFG6eoJwdGyxLYD6VN/f/E1Z512Xqk4ySkwDVW6FbS/Ydy4lPdLRr3mfpS0WCrw4MXPyZb L6Y25+WXo5WlkcGg3TYi8sRNNgnoo8T48HJh7hqQB/r3uFAMNOogYMoEa68+QgLPtCEvysreyT+2 ihEZaZ22jZ4iQirS1ZhOefndbuR0Fs0z75Mk8X1ucf3hpt3Xj4zT+kqd/zcT7KyCNRQMm8+Ns3Ai mMYqJ4lE4KVXysJNINBEZmjkoElx8yHqSDv/UvNZD4O1Z2LYwlPJqYU5gBzuzXslWOC3cvH6AAAA AAAA --Apple-Mail=_02B152A1-3673-4A4B-8153-A80C1530ACD0-- From simon@buddycloud.com Wed Feb 13 06:02:39 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E84DD21F86F5 for ; Wed, 13 Feb 2013 06:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOIwTlsUlw2s for ; Wed, 13 Feb 2013 06:02:38 -0800 (PST) Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3DE21F86F4 for ; Wed, 13 Feb 2013 06:02:18 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l13so5721958wie.14 for ; Wed, 13 Feb 2013 06:02:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/DYUgcpfYoYWYf63b5INf6UsNqX6etxs0tTTzQher+0=; b=LP8ZRMv/4nCvHehAeql3ZThQTPl1AcrrJOIGAj07+Z7HkbqoeizN1AahVcJITOwMer X/+c23HuCqQaoHUJ9vtrUKAlfMb8yKu4xGdqlDzDESubjYUlg1hFVZjmO5F3ifyzjZke C8nKjjWahh8TcCcmZvRYXD7xC1imZ3QtKXwtrjhqaj0rROKu4rGa3tOp/ekGlih3hgUc xf6yL9SJqGrwse2/6gt+dZcqAReL5EgKkomzB/LNZvSUN4NI1B9BXHzP+K6COrMKvyhO pjwfxBpHn5lrNowX9L808sdTcnOE1A1HWO7YeX4eSSNxqs6CkvGJh/wrWUWKunSQWTpw hR/w== MIME-Version: 1.0 X-Received: by 10.194.76.7 with SMTP id g7mr38483122wjw.50.1360764129137; Wed, 13 Feb 2013 06:02:09 -0800 (PST) Received: by 10.216.243.140 with HTTP; Wed, 13 Feb 2013 06:02:08 -0800 (PST) X-Originating-IP: [194.127.8.20] In-Reply-To: <50EF71A4.1050606@stpeter.im> References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> Date: Wed, 13 Feb 2013 15:02:08 +0100 Message-ID: From: Simon Tennant To: XMPP Working Group Content-Type: multipart/alternative; boundary=047d7beba2028a562c04d59b9646 X-Gm-Message-State: ALoCoQmziGNVrnEjA28T6K86gAysJChnakc1m5aMBX21axaxSZB7BmDjSSc9foysXSaU4e/gUhT0 Cc: Florian Jensen Subject: Re: [xmpp] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:02:40 -0000 --047d7beba2028a562c04d59b9646 Content-Type: text/plain; charset=UTF-8 I've been chatting with Florian about this the two standards for proving ownership in the case of a delegating domain hosting. Some background: Florian hosts many XMPP domains and at buddycloud, we're putting plans in place to host XMPP domains. In both cases, the more we have to ask customers to configure on their end, the less chance there is of a successful deployment. Right now this is: a) customer edits their DNS and point it at our servers. Nothing else. I have huge concerns about expecting customers to provide proofs at the web layer. Especially something that runs on their "main" website. Some reasons off the top of my head: a) Messaging team is different to web team - slow or no deployment. b) no website hosted on their domain - do we now host web stuff too? c) their website is created or hosted by their marketing agency / some other less technical. A simple website push could overwrite their .well-known record could kill their messaging service. d) it's complicated. DNSSEC is being rolled out. Sure some registrar and TLDs will take longer to deploy, but in the long term, I think this is the right way to have customers (especially non-technical customers who would rather delegate hosting) delegate their hosting. S. On 11 January 2013 02:57, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Just a small update to reflect publication of RFC 6698... > > Peter > > - -------- Original Message -------- > Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt > Date: Thu, 10 Jan 2013 10:44:32 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Using DNS Security Extensions (DNSSEC) and > DNS-based Authentication of Named Entities (DANE) as a Prooftype for > XMPP Domain Name Associations > Author(s) : Matthew Miller > Peter Saint-Andre > Filename : draft-miller-xmpp-dnssec-prooftype-03.txt > Pages : 7 > Date : 2013-01-10 > > Abstract: > This document defines a prooftype that uses DNS-based Authentication > of Named Entities (DANE) for associating a domain name with an XML > stream in the Extensible Messaging and Presence Protocol (XMPP). It > also defines a method that uses DNS Security (DNSSEC) for securely > delegating a source domain to a derived domain in XMPP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-miller-xmpp-dnssec-prooftype-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-miller-xmpp-dnssec-prooftype-03 > > > 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-Draftdirectories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iEYEARECAAYFAlDvcaQACgkQNL8k5A2w/vxOswCfSD5OrV7Fgj0gkgrFaBfroWks > HWAAn0hwNNsP0pPiX+lRwoz0sEEHj53X > =8YV7 > -----END PGP SIGNATURE----- > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > -- Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/ tQgxP --047d7beba2028a562c04d59b9646 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been chatting with Florian ab= out this the two standards for proving ownership in the case of a delegatin= g domain hosting.

Some background: Florian hosts many XMPP domains and at buddy= cloud, we're putting plans in place to host XMPP domains. In both cases, the more we have to ask customers to= configure on their end, the less chance there is of a successful deploymen= t.

Right now this is:
a) customer edits their DNS and point it at our servers. Nothing else.
I have huge concerns about expecting customers to provide proofs at = the web layer. Especially something that runs on their "main" web= site. Some reasons off the top of my head:
a) Messaging team is different to web team - slow or no deployment.
b)=C2=A0no website hosted on their domain - do we now host web stuf= f too?
c) their website is created or hosted by the= ir marketing agency / some other less technical. A simple website push coul= d overwrite their .well-known record could kill their messaging service.
d) it's complicated.

DNSSEC is being rolled out. Sure some registrar and TLDs will take longer to deploy, but in the long term, I th= ink this is the right way to have customers (especially non-technical custo= mers who would rather delegate hosting) delegate their hosting.

S.


On 11 January 2013 02:57, Peter Saint-An= dre <stpeter@stpeter= .im> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Just a small update to reflect publication of RFC 6698...

Peter

- -------- Original Message --------
Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt
Date: Thu, 10 Jan 2013 10:44:32 -0800
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Usin= g DNS Security Extensions (DNSSEC) and
DNS-based Authentication of Named Entities (DANE) as a Prooftype for
XMPP Domain Name Associations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author(s) =C2=A0 =C2=A0 =C2=A0 : Matthew Miller=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Peter Saint-Andre
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-mil= ler-xmpp-dnssec-prooftype-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2013-01-10

Abstract:
=C2=A0 =C2=A0This document defines a prooftype that uses DNS-based Authenti= cation
=C2=A0 =C2=A0of Named Entities (DANE) for associating a domain name with an= XML
=C2=A0 =C2=A0stream in the Extensible Messaging and Presence Protocol (XMPP= ). =C2=A0It
=C2=A0 =C2=A0also defines a method that uses DNS Security (DNSSEC) for secu= rely
=C2=A0 =C2=A0delegating a source domain to a derived domain in XMPP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-miller-xmpp-d= nssec-prooftype

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-miller-xmpp-dnssec-pro= oftype-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-miller= -xmpp-dnssec-prooftype-03


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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.18 (Darwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDvcaQACgkQNL8k5A2w/vxOswCfSD5OrV7Fgj0gkgrFaBfroWks
HWAAn0hwNNsP0pPiX+lRwoz0sEEHj53X
=3D8YV7
-----END PGP SIGNATURE-----
_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp



--
Simon Tennant | = buddycloud.com | +49 17 8545 0880= | office hours: goo.= gl/tQgxP
--047d7beba2028a562c04d59b9646-- From fippo@goodadvice.pages.de Wed Feb 13 06:50:57 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B02021F85BD for ; Wed, 13 Feb 2013 06:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du84kqcObCwY for ; Wed, 13 Feb 2013 06:50:54 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 77BCC21F8778 for ; Wed, 13 Feb 2013 06:50:52 -0800 (PST) Received: from lo.psyced.org (localhost [127.0.0.1]) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r1DEobYp003693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2013 15:50:37 +0100 Received: from localhost (fippo@localhost) by lo.psyced.org (8.14.3/8.14.3/Submit) with ESMTP id r1DEob5B003689; Wed, 13 Feb 2013 15:50:37 +0100 X-Authentication-Warning: lo.psyced.org: fippo owned process doing -bs Date: Wed, 13 Feb 2013 15:50:37 +0100 (CET) From: Philipp Hancke X-X-Sender: fippo@lo.psyced.org To: Simon Tennant In-Reply-To: Message-ID: References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="683466026-262484210-1360767037=:2647" Cc: XMPP Working Group , Florian Jensen Subject: Re: [xmpp] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:50:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --683466026-262484210-1360767037=:2647 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT > I've been chatting with Florian about this the two standards for proving ownership in the case of a delegating domain hosting. > > Some background: Florian hosts many XMPP domains and at buddycloud, we're putting plans in place to host XMPP domains. In both cases, the more we have to ask customers to configure on their end, the less chance there is of a successful deployment. > > Right now this is: > a) customer edits their DNS and point it at our servers. Nothing else. No security at all, right? (other than server dialback) > I have huge concerns about expecting customers to provide proofs at the web layer. Especially something that runs on their "main" website. Some reasons off the top of my head: > a) Messaging team is different to web team - slow or no deployment. > b) no website hosted on their domain - do we now host web stuff too? Well, then the POSH proof type (or an equivalent integrated into draft-daboo-aggregated-service-discovery) can not be used by another xmpp server to discover the certificate for that domain. > c) their website is created or hosted by their marketing agency / some other less technical. A simple website push could overwrite their .well-known record could kill their messaging service. hosting providers will have to protect .well-known. > d) it's complicated. > > DNSSEC is being rolled out. Sure some registrar and TLDs will take longer to deploy, but in the long term, I think this is the right way to have customers (especially non-technical customers who would rather delegate hosting) delegate their hosting. Then deploy DNSSEC. Smart servers will (might) try that first and gradually fall back to POSH (or equivalent) and may resort to dial-back as a "who cares about security as long as it works" method. --683466026-262484210-1360767037=:2647-- From mamille2@cisco.com Wed Feb 13 07:45:39 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7D21F890D for ; Wed, 13 Feb 2013 07:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GokwsVVg+DP0 for ; Wed, 13 Feb 2013 07:45:37 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F179421F88FD for ; Wed, 13 Feb 2013 07:45:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6252; q=dns/txt; s=iport; t=1360770337; x=1361979937; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e85+V9yheGjz7FrhkobsKS2WDf5Dh1prhuzfKLct0+g=; b=LRTRY9C5x2dsjMx2GYfpFc23c2Cp8bzleym9E1s/8qS+itMUNbhBVg6s F3A5d37cXFgZvnWeR9I6K5ixzcL8UfQ1eLRD3XkHMjqGw9e1tXnNVaWx6 qZvqlF4I0Fk1ZVTWg9TsROmPlHKq500cOq8KJ0+CPRDCBgYJcEIdauoOM w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHe0G1GtJXG9/2dsb2JhbABFg3m8cRZzgh8BAQEDAQEBATctBwEKBQcEAgEZAwECAQoUECcLFAkIAgQOBQgBiAMGBwW+apEiYQOXQYomhRCDBoFrJBg X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176666990" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 13 Feb 2013 15:45:31 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1DFjUlm010343 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Feb 2013 15:45:30 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 09:45:30 -0600 From: "Matt Miller (mamille2)" To: Simon Tennant Thread-Topic: Questions on POSH (WAS: [xmpp] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt] Thread-Index: AQHOCgEmBV/1KOpGpEmLRwKBpab5TA== Date: Wed, 13 Feb 2013 15:45:30 +0000 Message-ID: References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <1DE08E3B0EC6494D82ADF5638DE27649@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: XMPP Working Group , Florian Jensen Subject: [xmpp] Questions on POSH (WAS: Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt] X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 15:45:39 -0000 Hello Simon, Thanks for your feedback. I have more comments inline. On Feb 13, 2013, at 7:02 AM, Simon Tennant wrote: > I've been chatting with Florian about this the two standards for proving > ownership in the case of a delegating domain hosting. >=20 > Some background: Florian hosts many XMPP domains and at buddycloud, we're > putting plans in place to host XMPP domains. In both cases, the more we > have to ask customers to configure on their end, the less chance there is > of a successful deployment. >=20 > Right now this is: > a) customer edits their DNS and point it at our servers. Nothing else. Today this provides no actual verification in and of itself. To be trusted= , that hosting provider must present a certificate with the source domain's= identifier. This is becoming more and more difficult to do if the hosting= provider and the source domain are not the same thing. Alternatively, the hosting provider could acquire a certificate+private key= from the source domain, and carry the liabilities that having that private= key carries. >=20 > I have huge concerns about expecting customers to provide proofs at the w= eb > layer. Especially something that runs on their "main" website. Some reaso= ns > off the top of my head: > a) Messaging team is different to web team - slow or no deployment. Reality is that deployment requires coordination. I do appreciate the diffi= culties that arise with coordination, but trust sometimes requires coordina= tion. > b) no website hosted on their domain - do we now host web stuff too? For POSH, it would mean having enough of an HTTPS server to either present = the certs, or have a HTTPS-level redirect. > c) their website is created or hosted by their marketing agency / some > other less technical. A simple website push could overwrite their > .well-known record could kill their messaging service. They would need to protect .well-known, but this would be true of just abou= t anything that gets placed on a web server. > d) it's complicated. >=20 Please elaborate on what exactly is complicated about POSH. > DNSSEC is being rolled out. Sure some registrar and TLDs will take longer > to deploy, but in the long term, I think this is the right way to have > customers (especially non-technical customers who would rather delegate > hosting) delegate their hosting. >=20 Personally, I don't think DNSSEC will be useable for several years. Not on= ly does each domain need to have signed records, but just about all of the = recursive resolvers would need to leave any response (answer + additional += authority) from their upstream unmolested. It would also require the clie= nts to do the validation; trusting the "AD flag" from your recursive valida= ting resolver is about as trustworthy as today's dialback. While parts of these are happening, the implications are still not well und= erstood, which further hurts deployment. POSH is seen by some as a path tha= t we could start to deploy today with a very reasonable chance of success. If POSH doesn't work for you, then I guess you don't deploy it. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. >=20 > On 11 January 2013 02:57, Peter Saint-Andre wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Just a small update to reflect publication of RFC 6698... >>=20 >> Peter >>=20 >> - -------- Original Message -------- >> Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt >> Date: Thu, 10 Jan 2013 10:44:32 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : Using DNS Security Extensions (DNSSEC) and >> DNS-based Authentication of Named Entities (DANE) as a Prooftype for >> XMPP Domain Name Associations >> Author(s) : Matthew Miller >> Peter Saint-Andre >> Filename : draft-miller-xmpp-dnssec-prooftype-03.txt >> Pages : 7 >> Date : 2013-01-10 >>=20 >> Abstract: >> This document defines a prooftype that uses DNS-based Authentication >> of Named Entities (DANE) for associating a domain name with an XML >> stream in the Extensible Messaging and Presence Protocol (XMPP). It >> also defines a method that uses DNS Security (DNSSEC) for securely >> delegating a source domain to a derived domain in XMPP. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-miller-xmpp-dnssec-prooftype-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-dnssec-prooftype-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draftdirectories: >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>=20 >>=20 >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.18 (Darwin) >> Comment: Using GnuPG with undefined - http://www.enigmail.net/ >>=20 >> iEYEARECAAYFAlDvcaQACgkQNL8k5A2w/vxOswCfSD5OrV7Fgj0gkgrFaBfroWks >> HWAAn0hwNNsP0pPiX+lRwoz0sEEHj53X >> =3D8YV7 >> -----END PGP SIGNATURE----- >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp >>=20 >=20 >=20 >=20 > --=20 > Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/ > tQgxP > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From stpeter@stpeter.im Wed Feb 13 08:40:34 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F2E21F88A9 for ; Wed, 13 Feb 2013 08:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMtGVyHdp98D for ; Wed, 13 Feb 2013 08:40:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A36E621F8893 for ; Wed, 13 Feb 2013 08:40:30 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0E0B040564; Wed, 13 Feb 2013 09:47:34 -0700 (MST) Message-ID: <511BC1FC.6040202@stpeter.im> Date: Wed, 13 Feb 2013 09:40:28 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group , Florian Jensen Subject: Re: [xmpp] Questions on POSH (WAS: Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt] X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:40:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/13/13 8:45 AM, Matt Miller (mamille2) wrote: > If POSH doesn't work for you, then I guess you don't deploy it. Exactly. The idea behind DNA is that we have a "framework" for proving the validity of a server-to-server connection, with (initially) three different prooftypes: 1. PKI (RFC 6120 / RFC 6125) 2. DNSSEC (draft-miller-xmpp-dnssec-prooftype) 3. POSH (draft-miller-xmpp-posh-prooftype) Simon / Florian, we'd appreciate your feedback on the whole system here. Is one of those prooftypes deployable? Maybe two in some circumstances or for some customers? Matt and I added POSH to the mix because of difficulties with PKI and DNSSEC in many scenarios. Our hope is that, for hosting providers and customers who care about having secure s2s connections, at least one of the prooftypes would work. If that's not the case, then we might need to think about defining additional prooftypes (possibilities include some kind of ticket system a la OAuth, TLS with PGP as in RFC 6091, and other things that might or might not be easy to implement to deploy either). But we'll want to make sure that in any given deployment scenario at least one of the prooftypes is a reasonable approach. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRG8H7AAoJEOoGpJErxa2pxpwQAKR4jXvopHo8pS8vvWk3dVB3 2/cJIoEhQjc+OvopFg17ck8T8azErE29cctWfnztocPV+63K4tsSepDI14MnkzoC HqwHOx7MnZpud6VBpvlHErpyT3S6Ch9AFjrBgodP7fG34JrOUe5ikWhz1XtJII86 2en0sfIe5QnYhJqF3+F8GoaimcUXK21EG3x5sM3gKswXLt5uBhFW5zk9mE1PlUOK lRJWZHSCCceUv/Ry//e07hIblog+vsY59q9rRHjlsLpeGbzoZ+OBLbtixQh1fLuf XzZYNDSyKs/p2p9w9iOqw7RuefqDa8jKe2l2wSwqY77WWWe2V+lbeCHI6XlH4j2/ 0p7hyFsRWshne6h1b4xx5d905MaWViuIDCS+WHo35umQDoD6pAsRZHpK2QgCCzyp 6EU1XBPyToNQMpU/JeeYWM3OP2TQ4UzpFaySDk+OD+4uV9e5evCaY6YiA5kUkF06 cr6vAZYNn17qn3k29MEA2GLW0LJwVtG3vrdKU2wBYZcXTMJIgDmiZa+vlLUYUV03 yVrLLcl/DHvW4ekLgzFaSh5nGbxlAAFmq32RmcwmH89ltTFTnJBVaTnf3C8sHr5j M/RNpfY3vFPAqeFui/9tOf3TGqN/AXJ7hHRLd8COm2IQKu6P/AdIK5Bnnn8CeJsH dkPaZvsgtt7HWpNGeRZ7 =sdvF -----END PGP SIGNATURE----- From mamille2@cisco.com Wed Feb 13 10:55:58 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F46E1F0CE7 for ; Wed, 13 Feb 2013 10:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoZvAX26oTR8 for ; Wed, 13 Feb 2013 10:55:56 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D0F201F0D08 for ; Wed, 13 Feb 2013 10:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2015; q=dns/txt; s=iport; t=1360781757; x=1361991357; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=xK+lvxlh3ssOQ6d0TFB1vtt0yW6J/f0x0GxodWkk4FQ=; b=W17K9woOtGohwkvL19d2yGJO5fF+o5fZhG/oFDPutkNDOu5gyEAu5akA MkooCyjoJ5QV+3/F6EtZvkmTY5lv97GzqnwbScyO/DoisJT9rwbJcZCTX Q1Fk+6qqpTZGEVl6fEXvmuCyoejdfOy3BT7As3IOXNat5x4m4LoBWygoh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAALhG1GtJXG9/2dsb2JhbABFg3q8dBZzgh8BAQEDAQEBATc0EAsCARkDAQILFBAnCxQHAggCBBMIAYgDBgcFv02RI2EDl0GKJoUQgwaCJw X-IronPort-AV: E=Sophos;i="4.84,658,1355097600"; d="scan'208";a="176780047" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 13 Feb 2013 18:55:56 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1DItudg030113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 13 Feb 2013 18:55:56 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 13 Feb 2013 12:55:56 -0600 From: "Matt Miller (mamille2)" To: XMPP Working Group Thread-Topic: I-D Action: draft-miller-xmpp-posh-prooftype-02.txt Thread-Index: AQHOChraCe0ajbkQeEiaC73JhK1rfQ== Date: Wed, 13 Feb 2013 18:55:55 +0000 Message-ID: References: <20130213184911.31392.70999.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [xmpp] Fwd: I-D Action: draft-miller-xmpp-posh-prooftype-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 18:55:58 -0000 FYI... This update takes one possible approach to dealing with certificate chains = and roll-overs. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. Begin forwarded message: > From: > Subject: I-D Action: draft-miller-xmpp-posh-prooftype-02.txt > Date: February 13, 2013 11:49:11 AM MST > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Using PKIX over Secure HTTP (POSH) as a Prooftype for = XMPP Domain Name Associations > Author(s) : Matthew Miller > Peter Saint-Andre > Filename : draft-miller-xmpp-posh-prooftype-02.txt > Pages : 11 > Date : 2013-02-13 >=20 > Abstract: > This document defines a prooftype involving PKIX over Secure HTTP > (POSH) for associating a domain name with an XML stream in the > Extensible Messaging and Presence Protocol (XMPP). It also defines a > method involving HTTPS redirects (appropriate for use with the POSH > prooftype) for securely delegating a source domain to a derived > domain in XMPP. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-posh-prooftype >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-miller-xmpp-posh-prooftype-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-posh-prooftype-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 From admin@flosoft.biz Wed Feb 13 14:05:35 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D16221F8889 for ; Wed, 13 Feb 2013 14:05:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4vzzgbMWjAc for ; Wed, 13 Feb 2013 14:05:35 -0800 (PST) Received: from core1.flosoft-servers.net (flosoft.biz [178.33.33.198]) by ietfa.amsl.com (Postfix) with ESMTP id ABD0E21F8886 for ; Wed, 13 Feb 2013 14:05:34 -0800 (PST) X-No-Relay: not in my network Received: from homer.ldn.flosoft-servers.net (cpc18-slam5-2-0-cust142.2-4.cable.virginmedia.com [86.26.230.143]) by core1.flosoft-servers.net (Postfix) with ESMTPSA id 2DE3D416DB6 for ; Wed, 13 Feb 2013 23:06:55 +0100 (CET) From: Florian Jensen Content-Type: multipart/signed; boundary="Apple-Mail=_26B8F1E7-E7F9-4186-B5BE-CC5FF341681B"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <4A967520-23F9-4518-8246-CBC1700AC392@flosoft.biz> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Wed, 13 Feb 2013 22:05:02 +0000 References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> To: XMPP Working Group In-Reply-To: X-Mailer: Apple Mail (2.1499) Subject: Re: [xmpp] I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:05:35 -0000 --Apple-Mail=_26B8F1E7-E7F9-4186-B5BE-CC5FF341681B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Feb 2013, at 14:50, Philipp Hancke = wrote: >> I've been chatting with Florian about this the two standards for = proving ownership in the case of a delegating domain hosting. >> Some background: Florian hosts many XMPP domains and at buddycloud, = we're putting plans in place to host XMPP domains. In both cases, the = more we have to ask customers to configure on their end, the less chance = there is of a successful deployment. >> Right now this is: >> a) customer edits their DNS and point it at our servers. Nothing = else. >=20 > No security at all, right? (other than server dialback) Well, how often don't you trust your DNS ... It's pretty reliable. >=20 >> I have huge concerns about expecting customers to provide proofs at = the web layer. Especially something that runs on their "main" website. = Some reasons off the top of my head: >> a) Messaging team is different to web team - slow or no deployment. >> b) no website hosted on their domain - do we now host web stuff too? >=20 > Well, then the POSH proof type (or an equivalent integrated into = draft-daboo-aggregated-service-discovery) can not be used by another = xmpp server to discover the certificate for that domain. Correct. >=20 >> c) their website is created or hosted by their marketing agency / = some other less technical. A simple website push could overwrite their = .well-known record could kill their messaging service. >=20 > hosting providers will have to protect .well-known. So, in our case, we don't always host the Web service. Same for Google. = Heck, we host quite a few domains who don't use HTTP at all. >=20 >> d) it's complicated. >> DNSSEC is being rolled out. Sure some registrar and TLDs will take = longer to deploy, but in the long term, I think this is the right way to = have customers (especially non-technical customers who would rather = delegate hosting) delegate their hosting. >=20 > Then deploy DNSSEC. Smart servers will (might) try that first and = gradually fall back to POSH (or equivalent) and may resort to dial-back = as a "who cares about security as long as it works" method. --Apple-Mail=_26B8F1E7-E7F9-4186-B5BE-CC5FF341681B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINxTCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHiTCCBnGg AwIBAgICISgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjA1MTcxOTM1MDlaFw0xNDA1MTkxNTA1MzlaMIGQMRkwFwYDVQQNExBKa1JVR1dLejgyd1VDNjJk MQswCQYDVQQGEwJCRTEXMBUGA1UECBMOVmxhYW1zLUJyYWJhbnQxEjAQBgNVBAcTCUhvZWlsYWFy dDEXMBUGA1UEAxMORmxvcmlhbiBKZW5zZW4xIDAeBgkqhkiG9w0BCQEWEWFkbWluQGZsb3NvZnQu Yml6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvEm/5JmkvtLQsMw7gZOvL6HAUODp UPENwUcv4Ssx+3itC1Vd/Obrd87spTpC85G2Od4eJq7DL3Jl4gFhkHUJnD0szf04A23yokPlhOOn xlQAyXCudYsodx86uZobA1pnZmLIRTMtiU21dlOM/yYzHXp80bG9JeAq3DYYydS4btbNJaaUjlAo +wj1G8M/yWoQTPMHHGIYXkeHoxHBZTOio/lqwljwM3vuJ2HIyDQIEQQ2I2IRV1jzr8WpsUpyQeFF v6QRAv6zPh7lWhTY2J8BV1eC64zrKu/N1k326LhKN6Q8QDXW4z+wsC/8/5UFsoFqNkuD2Ii4DpTq zoPHsJL8NwIDAQABo4ID7TCCA+kwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSyoT7pfCut8JeFsUPsZMREHs5qPTAfBgNVHSME GDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzBdBgNVHREEVjBUgRFhZG1pbkBmbG9zb2Z0LmJpeoER YWRtaW5AZmxvc29mdC5iaXqBGWZsb3JpYW5AZmxvcmlhbmplbnNlbi5jb22BEWZsb3JpYW5Aamtn YnIuY29tMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVu dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq hkiG9w0BAQUFAAOCAQEATGR12NT+SHFH7zxb0+ZQnGsH1sbaRWkXuDc8LGyQpVn051HanW0oEZpt yqD5OAkZc75cGqKRQ/yEaU3k4bMY/jTONe59duW87ZhZLeLv7+mh/aNZN1sXMLpTsmKCMlJaiWVA QzBxCQXA9RcWwUe4HV9i86+MoCG9lJwykSrLOhfU0h9j5DZILTqFcIRR1+Z4xL/ncEGLAuqk+DwU ehpbvbrHQrUpnbU9fA0K0CsmUG8sXCIoo3m82uRxaTNxLLjX6l/u4r7mQ2natahGX4CGmM5TzSVN EoWRmN0xI0BUKYfcpyrWH/mOQpV/frlHqQKcJbMIndAXPXvILiK9cQHE+zGCA2wwggNoAgEBMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAiEoMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDIxMzIyMDUwM1owIwYJKoZIhvcN AQkEMRYEFCLr1xiEGiM4e7ZyfJtVdUDhz5ovMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQICISgwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2Vy dGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAiEoMA0GCSqGSIb3DQEBAQUABIIBAIx+FMr9CancgpSqwS2KvuCP iSmfzkI0YuDu6T+1MbUSqhBNK5FiXgRZhe1KntZlglv9LJwLoT2OXKw7Qw+Vs5VIp/yp+hwAM0he NXmqsXcL7P0XZhke7bC0FUCYA9sOHcGY4otSUOkQYaBhRDhGMdf1ADF0TY9/YC6qNSOUfKJglOOo BODQHUbj8EcadhaC9rK7C2fTRcFtpGCZ8Nuentf3OuLelwMRfhMhiOYuro79ZX3Fy9XjxpFUFwEb r9S865a0pGe/7RWHQH5Wr2xFj1YPknynltHVpmnyouErV7b9joZZ5LpCbao28/W7y7tAxLR+nmLL mB1sTWmAee+l4T8AAAAAAAA= --Apple-Mail=_26B8F1E7-E7F9-4186-B5BE-CC5FF341681B-- From admin@flosoft.biz Wed Feb 13 14:10:50 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78621F86F0 for ; Wed, 13 Feb 2013 14:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NG8jupbOm8D for ; Wed, 13 Feb 2013 14:10:49 -0800 (PST) Received: from core1.flosoft-servers.net (flosoft.biz [178.33.33.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7132021F86AF for ; Wed, 13 Feb 2013 14:10:49 -0800 (PST) X-No-Relay: not in my network X-No-Relay: not in my network Received: from [IPv6:2001:470:9274::6c2f:d151:4f4b:56] (unknown [IPv6:2001:470:9274:0:6c2f:d151:4f4b:56]) by core1.flosoft-servers.net (Postfix) with ESMTPSA id 7F673416931; Wed, 13 Feb 2013 23:12:02 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_960CB758-3583-4FF8-BA32-54C074312AA9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Florian Jensen In-Reply-To: <511BC1FC.6040202@stpeter.im> Date: Wed, 13 Feb 2013 22:09:56 +0000 Message-Id: <4C07E5BE-8D07-4036-9068-6C3FD3E77BC1@flosoft.biz> References: <20130110184432.5134.57184.idtracker@ietfa.amsl.com> <50EF71A4.1050606@stpeter.im> <511BC1FC.6040202@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Cc: XMPP Working Group Subject: Re: [xmpp] Questions on POSH (WAS: Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-03.txt] X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 22:10:50 -0000 --Apple-Mail=_960CB758-3583-4FF8-BA32-54C074312AA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, for 'us webhosts' I believe that DNSSEC is the way forward for secure = federation. It's simple and straight forward for us and customers. If you want secure federation, get DNSSEC enabled on your domain. Done. My 2 cents. Florian On 13 Feb 2013, at 16:40, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2/13/13 8:45 AM, Matt Miller (mamille2) wrote: >=20 >> If POSH doesn't work for you, then I guess you don't deploy it. >=20 > Exactly. The idea behind DNA is that we have a "framework" for proving > the validity of a server-to-server connection, with (initially) three > different prooftypes: >=20 > 1. PKI (RFC 6120 / RFC 6125) >=20 > 2. DNSSEC (draft-miller-xmpp-dnssec-prooftype) >=20 > 3. POSH (draft-miller-xmpp-posh-prooftype) >=20 > Simon / Florian, we'd appreciate your feedback on the whole system > here. Is one of those prooftypes deployable? Maybe two in some > circumstances or for some customers? Matt and I added POSH to the mix > because of difficulties with PKI and DNSSEC in many scenarios. Our > hope is that, for hosting providers and customers who care about > having secure s2s connections, at least one of the prooftypes would > work. If that's not the case, then we might need to think about > defining additional prooftypes (possibilities include some kind of > ticket system a la OAuth, TLS with PGP as in RFC 6091, and other > things that might or might not be easy to implement to deploy either). > But we'll want to make sure that in any given deployment scenario at > least one of the prooftypes is a reasonable approach. >=20 > Peter >=20 > - --=20 > Peter Saint-Andre > https://stpeter.im/ >=20 >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >=20 > iQIcBAEBAgAGBQJRG8H7AAoJEOoGpJErxa2pxpwQAKR4jXvopHo8pS8vvWk3dVB3 > 2/cJIoEhQjc+OvopFg17ck8T8azErE29cctWfnztocPV+63K4tsSepDI14MnkzoC > HqwHOx7MnZpud6VBpvlHErpyT3S6Ch9AFjrBgodP7fG34JrOUe5ikWhz1XtJII86 > 2en0sfIe5QnYhJqF3+F8GoaimcUXK21EG3x5sM3gKswXLt5uBhFW5zk9mE1PlUOK > lRJWZHSCCceUv/Ry//e07hIblog+vsY59q9rRHjlsLpeGbzoZ+OBLbtixQh1fLuf > XzZYNDSyKs/p2p9w9iOqw7RuefqDa8jKe2l2wSwqY77WWWe2V+lbeCHI6XlH4j2/ > 0p7hyFsRWshne6h1b4xx5d905MaWViuIDCS+WHo35umQDoD6pAsRZHpK2QgCCzyp > 6EU1XBPyToNQMpU/JeeYWM3OP2TQ4UzpFaySDk+OD+4uV9e5evCaY6YiA5kUkF06 > cr6vAZYNn17qn3k29MEA2GLW0LJwVtG3vrdKU2wBYZcXTMJIgDmiZa+vlLUYUV03 > yVrLLcl/DHvW4ekLgzFaSh5nGbxlAAFmq32RmcwmH89ltTFTnJBVaTnf3C8sHr5j > M/RNpfY3vFPAqeFui/9tOf3TGqN/AXJ7hHRLd8COm2IQKu6P/AdIK5Bnnn8CeJsH > dkPaZvsgtt7HWpNGeRZ7 > =3DsdvF > -----END PGP SIGNATURE----- > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp --Apple-Mail=_960CB758-3583-4FF8-BA32-54C074312AA9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINxTCCBjQw 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/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHiTCCBnGg AwIBAgICISgwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjA1MTcxOTM1MDlaFw0xNDA1MTkxNTA1MzlaMIGQMRkwFwYDVQQNExBKa1JVR1dLejgyd1VDNjJk MQswCQYDVQQGEwJCRTEXMBUGA1UECBMOVmxhYW1zLUJyYWJhbnQxEjAQBgNVBAcTCUhvZWlsYWFy dDEXMBUGA1UEAxMORmxvcmlhbiBKZW5zZW4xIDAeBgkqhkiG9w0BCQEWEWFkbWluQGZsb3NvZnQu Yml6MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvEm/5JmkvtLQsMw7gZOvL6HAUODp UPENwUcv4Ssx+3itC1Vd/Obrd87spTpC85G2Od4eJq7DL3Jl4gFhkHUJnD0szf04A23yokPlhOOn xlQAyXCudYsodx86uZobA1pnZmLIRTMtiU21dlOM/yYzHXp80bG9JeAq3DYYydS4btbNJaaUjlAo +wj1G8M/yWoQTPMHHGIYXkeHoxHBZTOio/lqwljwM3vuJ2HIyDQIEQQ2I2IRV1jzr8WpsUpyQeFF v6QRAv6zPh7lWhTY2J8BV1eC64zrKu/N1k326LhKN6Q8QDXW4z+wsC/8/5UFsoFqNkuD2Ii4DpTq zoPHsJL8NwIDAQABo4ID7TCCA+kwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSyoT7pfCut8JeFsUPsZMREHs5qPTAfBgNVHSME GDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzBdBgNVHREEVjBUgRFhZG1pbkBmbG9zb2Z0LmJpeoER YWRtaW5AZmxvc29mdC5iaXqBGWZsb3JpYW5AZmxvcmlhbmplbnNlbi5jb22BEWZsb3JpYW5Aamtn YnIuY29tMIICIQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGc BggrBgEFBQcCAjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRM aWFiaWxpdHkgYW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBh bmQgTGltaXRhdGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGB MH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVu dC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNz Mi5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq hkiG9w0BAQUFAAOCAQEATGR12NT+SHFH7zxb0+ZQnGsH1sbaRWkXuDc8LGyQpVn051HanW0oEZpt yqD5OAkZc75cGqKRQ/yEaU3k4bMY/jTONe59duW87ZhZLeLv7+mh/aNZN1sXMLpTsmKCMlJaiWVA QzBxCQXA9RcWwUe4HV9i86+MoCG9lJwykSrLOhfU0h9j5DZILTqFcIRR1+Z4xL/ncEGLAuqk+DwU ehpbvbrHQrUpnbU9fA0K0CsmUG8sXCIoo3m82uRxaTNxLLjX6l/u4r7mQ2natahGX4CGmM5TzSVN EoWRmN0xI0BUKYfcpyrWH/mOQpV/frlHqQKcJbMIndAXPXvILiK9cQHE+zGCA2wwggNoAgEBMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAiEoMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDIxMzIyMDk1N1owIwYJKoZIhvcN AQkEMRYEFGi8Ej8PyTPsNzzjHa+CThpaZfqYMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQICISgwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQG EwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2Vy dGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0ECAiEoMA0GCSqGSIb3DQEBAQUABIIBAHDLFeUvouLqWM+YHAQqY4OS jJGsVDnwl2b05z2AB3U398j2YSIBmkG2SGL5fFGHN39oAUTKHkcN2YzE01TuEvrBH4KoRYsgTM/Z iCTpNkCHWIYSLAO/vqR8LQrI2dci8Q+aQkqSNAPyESgFZPAf/uUgtcnhdpJH8kilpvDZladnbJ6V kzJ4hq/pfkVoWEGxoLs+OimAs7sAHGCcBLhpavtD7Mx4B4T8y8QejoBzFd6T00+gMQ3H/G5i80Dn +I3RXvvEnLF5BncRcRpb1oWGJ7eZbGXasp7uawRsMMx+zHON3hL94+YocBAQlkZfnwiuNfUqqNGo Rfe1Boqfwy6b3RAAAAAAAAA= --Apple-Mail=_960CB758-3583-4FF8-BA32-54C074312AA9-- From wwwrun@rfc-editor.org Mon Feb 18 06:44:28 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B395A21F899E for ; Mon, 18 Feb 2013 06:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5G15etCCxdcA for ; Mon, 18 Feb 2013 06:44:28 -0800 (PST) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BB28621F8996 for ; Mon, 18 Feb 2013 06:44:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F2B8AB1E004; Mon, 18 Feb 2013 06:43:44 -0800 (PST) To: psaintan@cisco.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, jhildebr@cisco.com, ben@nostrum.com From: RFC Errata System Message-Id: <20130218144344.F2B8AB1E004@rfc-editor.org> Date: Mon, 18 Feb 2013 06:43:44 -0800 (PST) Cc: maranda@lightwitch.org, xmpp@ietf.org, rfc-editor@rfc-editor.org Subject: [xmpp] [Editorial Errata Reported] RFC6120 (3486) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 14:44:28 -0000 The following errata report has been submitted for RFC6120, "Extensible Messaging and Presence Protocol (XMPP): Core". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6120&eid=3486 -------------------------------------- Type: Editorial Reported by: Marco Cirillo Section: 5.4.1 Original Text ------------- The receiving entity then MUST send stream features to the initiating entity. If the receiving entity supports TLS, the stream features MUST include an advertisement for support of STARTTLS negotiation, i.e., a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. Corrected Text -------------- The receiving entity then MUST send stream features to the initiating entity. If the receiving entity offers TLS capability, the stream features MUST include an advertisement for support of STARTTLS negotiation, i.e., a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. Notes ----- Current text mixes up actual support of STARTTLS/TLS (which is mandated by section 5.2) with deployment/availableness of the said. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6120 (draft-ietf-xmpp-3920bis-22) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Core Publication Date : March 2011 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From ben@nostrum.com Thu Feb 21 11:59:16 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D3D21F8F5B for ; Thu, 21 Feb 2013 11:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ascvE8+SmdOm for ; Thu, 21 Feb 2013 11:59:15 -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 B86AE21F8F5A for ; Thu, 21 Feb 2013 11:59:15 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1LJxEnU024039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 13:59:15 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Feb 2013 13:59:14 -0600 Message-Id: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> To: XMPP Working Group Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Subject: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:59:16 -0000 Hi Everyone, We need to do a minor charter update to add the XMPP/WebSockets work.=20 Here's the proposed new text. This version is the same as before, except = it removes the text for XMPP interworking with SIP/SIMPLE, an adds text = for WebSockets. The new text is the second to last paragraph. Please send any feedback to the XMPP mailing list as soon as possible. = (If you agree with the text as is, please say that, too :-) ) Thanks! Ben. ----------------- The Extensible Messaging and Presence Protocol (XMPP) is an technology for the near-real-time exchange of messages and presence notifications, where data is exchanged over Extensible Markup Language (XML) streams. The original XMPP working group published RFCs 3920-3923. Implementation and deployment experience since that time has resulted in errata, clarifications, and suggestions for improvement to the core XMPP specifications (RFCs 3920 and 3921). Some technologies on which XMPP depends (e.g., Transport Layer Security and the Simple Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a sustainable solution to internationalization of XMPP addresses, since the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and draft-saintandre-rfc3921bis-* reflect community input so far regarding these modifications, but the group needs to complete this work, especially with regard to internationalization. Because of the scope of changes involved, it is envisioned that these specifications will be cycled at Proposed Standard. Although RFC 3923 defines an end-to-end signing and encryption technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security technologies. XMPP uses TLS for encryption and the Simple Authentication and Security Layer (SASL) for authentication. In the case of a server-to-server stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, where each peer presents an X.509 certificate. This model introduces scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus necessitating multiple TCP connections. The group will work to overcome these challenges by defining an optional mechanism for using a single connection with multiple identities. It is anticipated that most of the work will consist of defining and providing requirements to the TLS and SASL working groups. In addition to the TCP binding defined in RFC 6120, the XMPP community has long employed an HTTP binding (XEP-0124 and XEP-0206 published by=20 the XMPP Standards Foundation). Given that this binding uses HTTP long=20= polling, which has many known issues (RFC 6202), it is reasonable to=20 transition to use of the WebSocket protocol (RFC 6455) instead. Work = has begun on defining a WebSocket subprotocol for XMPP=20 (draft-moffitt-xmpp-over-websocket). The group will complete the=20 definition of such a subprotocol, and coordinate reviews with the HYBI = WG=20 where appropriate. In completing its work, the group will strive to retain backwards compatibility with RFCs 3920 and 3921. However, changes that are not backwards compatible might be accepted if the group determines that the changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them.= From bernard.aboba@gmail.com Thu Feb 21 14:44:53 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25421E803D for ; Thu, 21 Feb 2013 14:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa4kFkCgHnOV for ; Thu, 21 Feb 2013 14:44:52 -0800 (PST) Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9242D21E8039 for ; Thu, 21 Feb 2013 14:44:50 -0800 (PST) Received: by mail-qe0-f53.google.com with SMTP id 1so26751qee.40 for ; Thu, 21 Feb 2013 14:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LIZrvUR+eI4u7mmPOd8EF7eGz/2261aLBNwWTtCPZ4o=; b=W+0OLoVp7sohqvMlp61SvoKOr8Mk2AWBNbAt7eEbRPHMUgc8QLf7DjJXU4+uXslWUr EK4tCBwY5Y1FsrptJzu3TXRBQgFxu6dqNaOmYDzX/0AtFBMPNzueoS4yX5VLAA9UBg+z LDdBskJP7tegh57SErRzG6mx0mfWsnh2BhQe8MUfWp5XLZ38DmWTlol3UroBo64DecAt j/74NokwbVb5zygQrG6fDtbHvxCORlhQsnwHKEyRYWx5IZQxvdAds0fZyxrlZ33ghqFZ pBiam/kO25TLFe9G0eSfl8uGUxoGXO71tRL+5Mq9gE5i45RV+oEnC2T7SoEosJL9bJOo mu5w== X-Received: by 10.224.168.144 with SMTP id u16mr252219qay.18.1361486685991; Thu, 21 Feb 2013 14:44:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.49.110.8 with HTTP; Thu, 21 Feb 2013 14:44:25 -0800 (PST) In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> From: Bernard Aboba Date: Thu, 21 Feb 2013 14:44:25 -0800 Message-ID: To: Ben Campbell Content-Type: multipart/alternative; boundary=20cf3074d86648f1ce04d643d28d Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:44:53 -0000 --20cf3074d86648f1ce04d643d28d Content-Type: text/plain; charset=ISO-8859-1 The Websockets work is badly needed. So the charter changes look good. On Thu, Feb 21, 2013 at 11:59 AM, Ben Campbell wrote: > Hi Everyone, > > We need to do a minor charter update to add the XMPP/WebSockets work. > > Here's the proposed new text. This version is the same as before, except > it removes the text for XMPP interworking with SIP/SIMPLE, an adds text for > WebSockets. The new text is the second to last paragraph. > > Please send any feedback to the XMPP mailing list as soon as possible. (If > you agree with the text as is, please say that, too :-) ) > > Thanks! > > Ben. > > ----------------- > > The Extensible Messaging and Presence Protocol (XMPP) is an > technology for the near-real-time exchange of messages and presence > notifications, where data is exchanged over Extensible Markup Language > (XML) streams. The original XMPP working group published RFCs 3920-3923. > > Implementation and deployment experience since that time has resulted > in errata, clarifications, and suggestions for improvement to the core > XMPP specifications (RFCs 3920 and 3921). Some technologies on which > XMPP depends (e.g., Transport Layer Security and the Simple > Authentication and Security Layer) have undergone modifications of their > own, which XMPP needs to track. Finally, the group needs to define a > sustainable solution to internationalization of XMPP addresses, since > the approach taken in RFC 3920 (based on stringprep profiles) is limited > to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and > draft-saintandre-rfc3921bis-* reflect community input so > far regarding these modifications, but the group needs to complete this > work, especially with regard to internationalization. Because of the > scope of changes involved, it is envisioned that these specifications > will be cycled at Proposed Standard. > > Although RFC 3923 defines an end-to-end signing and encryption > technology for use by XMPP systems, to date it has not been implemented. > A goal of the group is to develop an implementable method for end-to-end > encryption, preferably based on well known and widely deployed security > technologies. > > XMPP uses TLS for encryption and the Simple Authentication and Security > Layer (SASL) for authentication. In the case of a server-to-server > stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, > where each peer presents an X.509 certificate. This model introduces > scaling challenges in multi-domain deployments because RFC 3920 requires > that a stream cannot be reused for more than one domain, thus > necessitating multiple TCP connections. The group will work to overcome > these challenges by defining an optional mechanism for using a single > connection with multiple identities. It is anticipated that most of the > work will consist of defining and providing requirements to the TLS and > SASL working groups. > > In addition to the TCP binding defined in RFC 6120, the XMPP community > has long employed an HTTP binding (XEP-0124 and XEP-0206 published by > the XMPP Standards Foundation). Given that this binding uses HTTP long > polling, which has many known issues (RFC 6202), it is reasonable to > transition to use of the WebSocket protocol (RFC 6455) instead. Work has > begun on defining a WebSocket subprotocol for XMPP > (draft-moffitt-xmpp-over-websocket). The group will complete the > definition of such a subprotocol, and coordinate reviews with the HYBI WG > where appropriate. > > In completing its work, the group will strive to retain backwards > compatibility with RFCs 3920 and 3921. However, changes that are not > backwards compatible might be accepted if the group determines that the > changes are required to meet the group's technical objectives and the > group clearly documents the reasons for making them. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --20cf3074d86648f1ce04d643d28d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The Websockets work is badly needed.=A0 So the charter changes look good.
On Thu, Feb 21, 2013 at 11:59 AM, Ben Camp= bell <ben@nostrum.com> wrote:
Hi Everyone,

We need to do a minor charter update to add the XMPP/WebSockets work.

Here's the proposed new text. This version is the same as before, excep= t it removes the text for XMPP interworking with SIP/SIMPLE, an adds text f= or WebSockets. The new text is the second to last paragraph.

Please send any feedback to the XMPP mailing list as soon as possible. (If = you agree with the text as is, please say that, too :-) )

Thanks!

Ben.

-----------------

The Extensible Messaging and Presence Protocol (XMPP) is an
technology for the near-real-time exchange of messages and presence
notifications, where data is exchanged over Extensible Markup Language
(XML) streams. The original XMPP working group published RFCs 3920-3923.
Implementation and deployment experience since that time has resulted
in errata, clarifications, and suggestions for improvement to the core
XMPP specifications (RFCs 3920 and 3921). Some technologies on which
XMPP depends (e.g., Transport Layer Security and the Simple
Authentication and Security Layer) have undergone modifications of their own, which XMPP needs to track. Finally, the group needs to define a
sustainable solution to internationalization of XMPP addresses, since
the approach taken in RFC 3920 (based on stringprep profiles) is limited to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
draft-saintandre-rfc3921bis-* reflect community input so
far regarding these modifications, but the group needs to complete this
work, especially with regard to internationalization. Because of the
scope of changes involved, it is envisioned that these specifications
will be cycled at Proposed Standard.

Although RFC 3923 defines an end-to-end signing and encryption
technology for use by XMPP systems, to date it has not been implemented. A goal of the group is to develop an implementable method for end-to-end encryption, preferably based on well known and widely deployed security
technologies.

XMPP uses TLS for encryption and the Simple Authentication and Security
Layer (SASL) for authentication. In the case of a server-to-server
stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism,
where each peer presents an X.509 certificate. This model introduces
scaling challenges in multi-domain deployments because RFC 3920 requires that a stream cannot be reused for more than one domain, thus
necessitating multiple TCP connections. The group will work to overcome
these challenges by defining an optional mechanism for using a single
connection with multiple identities. It is anticipated that most of the
work will consist of defining and providing requirements to the TLS and
SASL working groups.

In addition to the TCP binding defined in RFC 6120, the XMPP community
has long employed an HTTP binding (XEP-0124 and XEP-0206 published by
the XMPP Standards Foundation). =A0Given that this binding uses HTTP long polling, which has many known issues (RFC 6202), it is reasonable to
transition to use of the WebSocket protocol (RFC 6455) instead. =A0Work has=
begun on defining a WebSocket subprotocol for XMPP
(draft-moffitt-xmpp-over-websocket). =A0The group will complete the
definition of such a subprotocol, and coordinate reviews with the HYBI WG where appropriate.

In completing its work, the group will strive to retain backwards
compatibility with RFCs 3920 and 3921. However, changes that are not
backwards compatible might be accepted if the group determines that the
changes are required to meet the group's technical objectives and the group clearly documents the reasons for making them.
_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--20cf3074d86648f1ce04d643d28d-- From derhoermi@gmx.net Thu Feb 21 15:45:00 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E596921E803D for ; Thu, 21 Feb 2013 15:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIVcwgz0gat5 for ; Thu, 21 Feb 2013 15:45:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id DD84B21E8039 for ; Thu, 21 Feb 2013 15:44:59 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.34]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lveks-1Uw3yk39Se-017VrW for ; Fri, 22 Feb 2013 00:44:14 +0100 Received: (qmail invoked by alias); 21 Feb 2013 23:44:14 -0000 Received: from p5B2322BB.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.34.187] by mail.gmx.net (mp034) with SMTP; 22 Feb 2013 00:44:14 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+q/Dp9BcyqBHomsTjOgVIR5EH3iF2kO9TYeVVGcF GmIiIuWlZLrkHr From: Bjoern Hoehrmann To: Ben Campbell Date: Fri, 22 Feb 2013 00:44:16 +0100 Message-ID: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> 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-Y-GMX-Trusted: 0 Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 23:45:01 -0000 * Ben Campbell wrote: >Although RFC 3923 defines an end-to-end signing and encryption >technology for use by XMPP systems, to date it has not been implemented. >A goal of the group is to develop an implementable method for end-to-end >encryption, preferably based on well known and widely deployed security >technologies. (This is very much needed, as far as I am concerned!) -- 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 ben@nostrum.com Thu Feb 21 16:00:17 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417CC21E803D for ; Thu, 21 Feb 2013 16:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9t2oJt1lhfH for ; Thu, 21 Feb 2013 16:00:16 -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 3465D21E803F for ; Thu, 21 Feb 2013 16:00:16 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1M00Dr6051507 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 21 Feb 2013 18:00:13 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Thu, 21 Feb 2013 18:00:13 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> To: Bjoern Hoehrmann X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:00:17 -0000 On Feb 21, 2013, at 5:44 PM, Bjoern Hoehrmann wrote: > * Ben Campbell wrote: >> Although RFC 3923 defines an end-to-end signing and encryption >> technology for use by XMPP systems, to date it has not been = implemented. >> A goal of the group is to develop an implementable method for = end-to-end >> encryption, preferably based on well known and widely deployed = security >> technologies. >=20 > (This is very much needed, as far as I am concerned!) Agreed--but unless I really messed something up, that paragraph was in = the old (that is, current) charter, too :-) From mamille2@cisco.com Thu Feb 21 16:28:14 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2E221E803A for ; Thu, 21 Feb 2013 16:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzpEma7rPaHi for ; Thu, 21 Feb 2013 16:28:13 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4F521E8034 for ; Thu, 21 Feb 2013 16:28:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4135; q=dns/txt; s=iport; t=1361492893; x=1362702493; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4b1HV2n0VOoCpHz3VuUfv4dpoaQOe9UwXCekMViT8qU=; b=VQcbRmGBjuGQ8RUgBcpr/ELNSqIxyE/ops4FV3O3rfx5AaMtn0Eg9/XH GHevXPWmaB4jrXrcyI3gtDCbhYdFJ0PGH8azM0gZkYDRV6D8tlHIkEI2V eAwGItfuVzxQGk1uv3EZn4q5It/+FbeLDSq3hKevWb8yGBCGKpPRQX9t/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADy6JlGtJXG8/2dsb2JhbABFwRKBCRZzgh8BAQEDAQEBATc0CwULAgEIIhQQJwslAgQOBQgMB4dxBgy/JgSNR4EUAjEHgl9hA6cUgweBaT4 X-IronPort-AV: E=Sophos;i="4.84,711,1355097600"; d="scan'208";a="179845512" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 22 Feb 2013 00:28:12 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1M0SC14007966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Feb 2013 00:28:12 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 21 Feb 2013 18:28:12 -0600 From: "Matt Miller (mamille2)" To: Ben Campbell Thread-Topic: [xmpp] Proposed XMPP Charter Update Thread-Index: AQHOEG3wgKlUzi3iykKWjJHftGObMZiFarUA Date: Fri, 22 Feb 2013 00:28:11 +0000 Message-ID: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.55] Content-Type: text/plain; charset="us-ascii" Content-ID: <1E03CAB00CDBC141B3129F4F99BC1B22@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:28:14 -0000 This looks good to me. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Feb 21, 2013, at 12:59 PM, Ben Campbell wrote: > Hi Everyone, >=20 > We need to do a minor charter update to add the XMPP/WebSockets work.=20 >=20 > Here's the proposed new text. This version is the same as before, except = it removes the text for XMPP interworking with SIP/SIMPLE, an adds text for= WebSockets. The new text is the second to last paragraph. >=20 > Please send any feedback to the XMPP mailing list as soon as possible. (I= f you agree with the text as is, please say that, too :-) ) >=20 > Thanks! >=20 > Ben. >=20 > ----------------- >=20 > The Extensible Messaging and Presence Protocol (XMPP) is an > technology for the near-real-time exchange of messages and presence > notifications, where data is exchanged over Extensible Markup Language > (XML) streams. The original XMPP working group published RFCs 3920-3923. >=20 > Implementation and deployment experience since that time has resulted > in errata, clarifications, and suggestions for improvement to the core > XMPP specifications (RFCs 3920 and 3921). Some technologies on which > XMPP depends (e.g., Transport Layer Security and the Simple > Authentication and Security Layer) have undergone modifications of their > own, which XMPP needs to track. Finally, the group needs to define a > sustainable solution to internationalization of XMPP addresses, since > the approach taken in RFC 3920 (based on stringprep profiles) is limited > to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and > draft-saintandre-rfc3921bis-* reflect community input so > far regarding these modifications, but the group needs to complete this > work, especially with regard to internationalization. Because of the > scope of changes involved, it is envisioned that these specifications > will be cycled at Proposed Standard. >=20 > Although RFC 3923 defines an end-to-end signing and encryption > technology for use by XMPP systems, to date it has not been implemented. > A goal of the group is to develop an implementable method for end-to-end > encryption, preferably based on well known and widely deployed security > technologies. >=20 > XMPP uses TLS for encryption and the Simple Authentication and Security > Layer (SASL) for authentication. In the case of a server-to-server > stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, > where each peer presents an X.509 certificate. This model introduces > scaling challenges in multi-domain deployments because RFC 3920 requires > that a stream cannot be reused for more than one domain, thus > necessitating multiple TCP connections. The group will work to overcome > these challenges by defining an optional mechanism for using a single > connection with multiple identities. It is anticipated that most of the > work will consist of defining and providing requirements to the TLS and > SASL working groups. >=20 > In addition to the TCP binding defined in RFC 6120, the XMPP community > has long employed an HTTP binding (XEP-0124 and XEP-0206 published by=20 > the XMPP Standards Foundation). Given that this binding uses HTTP long=20 > polling, which has many known issues (RFC 6202), it is reasonable to=20 > transition to use of the WebSocket protocol (RFC 6455) instead. Work has > begun on defining a WebSocket subprotocol for XMPP=20 > (draft-moffitt-xmpp-over-websocket). The group will complete the=20 > definition of such a subprotocol, and coordinate reviews with the HYBI WG= =20 > where appropriate. >=20 > In completing its work, the group will strive to retain backwards > compatibility with RFCs 3920 and 3921. However, changes that are not > backwards compatible might be accepted if the group determines that the > changes are required to meet the group's technical objectives and the > group clearly documents the reasons for making them. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From rlb@ipv.sx Thu Feb 21 16:29:30 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13FD521E803A for ; Thu, 21 Feb 2013 16:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rNHtQG6tdUGW for ; Thu, 21 Feb 2013 16:29:29 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 0E01C21E8034 for ; Thu, 21 Feb 2013 16:29:28 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id 16so105752obc.33 for ; Thu, 21 Feb 2013 16:29:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=tSFjSRPjnA/p3A3vPYzLZL4RtP5F8qkPEMKFumANM0g=; b=VPCa3/hRKuYlj+7ilLj47/NnROu1GWkRIXmIgS4fknTWZPGdFHZoqaKhbLIrc2Z3Wu UCvvUo0PhLr8xm2cV8tJILlFuQoP4cPP7kOWuRv2oW6nWqO9wC1nVvI4odG9OaYBINxM Cp0E5gl6Z91jY5LBT3fEpDw0yXYYxaz1pziVeLAT2L3/RkMIToOdiRbDYQy+8fSdU5z2 FwLDfgkN8PQVPIpBw7+9snq3EhyQUOMEGpbId8HCTjwCqHEZZvq/s0BvA9Hin2wNpSSL /6hkWjNelJDy2Ar9RR633e6lLLj2Hkm1OuSMxb8+orc47RKJh+znFF12Jy9AtSAsVzVC w1/g== MIME-Version: 1.0 X-Received: by 10.60.26.231 with SMTP id o7mr7812788oeg.107.1361492968322; Thu, 21 Feb 2013 16:29:28 -0800 (PST) Received: by 10.60.60.98 with HTTP; Thu, 21 Feb 2013 16:29:28 -0800 (PST) X-Originating-IP: [128.89.253.34] In-Reply-To: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> Date: Thu, 21 Feb 2013 19:29:28 -0500 Message-ID: From: Richard Barnes To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=e89a8fb1f4c4c02f2d04d6454825 X-Gm-Message-State: ALoCoQkVS8VC9CgEA+tyNYBwSc9+XCeaainzmoQ2kDa9/F8IBJNXh0wGzj7KoApprovDPgEzV0TC Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 00:29:30 -0000 --e89a8fb1f4c4c02f2d04d6454825 Content-Type: text/plain; charset=ISO-8859-1 +1 On Thu, Feb 21, 2013 at 7:28 PM, Matt Miller (mamille2) wrote: > This looks good to me. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Feb 21, 2013, at 12:59 PM, Ben Campbell > wrote: > > > Hi Everyone, > > > > We need to do a minor charter update to add the XMPP/WebSockets work. > > > > Here's the proposed new text. This version is the same as before, except > it removes the text for XMPP interworking with SIP/SIMPLE, an adds text for > WebSockets. The new text is the second to last paragraph. > > > > Please send any feedback to the XMPP mailing list as soon as possible. > (If you agree with the text as is, please say that, too :-) ) > > > > Thanks! > > > > Ben. > > > > ----------------- > > > > The Extensible Messaging and Presence Protocol (XMPP) is an > > technology for the near-real-time exchange of messages and presence > > notifications, where data is exchanged over Extensible Markup Language > > (XML) streams. The original XMPP working group published RFCs 3920-3923. > > > > Implementation and deployment experience since that time has resulted > > in errata, clarifications, and suggestions for improvement to the core > > XMPP specifications (RFCs 3920 and 3921). Some technologies on which > > XMPP depends (e.g., Transport Layer Security and the Simple > > Authentication and Security Layer) have undergone modifications of their > > own, which XMPP needs to track. Finally, the group needs to define a > > sustainable solution to internationalization of XMPP addresses, since > > the approach taken in RFC 3920 (based on stringprep profiles) is limited > > to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and > > draft-saintandre-rfc3921bis-* reflect community input so > > far regarding these modifications, but the group needs to complete this > > work, especially with regard to internationalization. Because of the > > scope of changes involved, it is envisioned that these specifications > > will be cycled at Proposed Standard. > > > > Although RFC 3923 defines an end-to-end signing and encryption > > technology for use by XMPP systems, to date it has not been implemented. > > A goal of the group is to develop an implementable method for end-to-end > > encryption, preferably based on well known and widely deployed security > > technologies. > > > > XMPP uses TLS for encryption and the Simple Authentication and Security > > Layer (SASL) for authentication. In the case of a server-to-server > > stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, > > where each peer presents an X.509 certificate. This model introduces > > scaling challenges in multi-domain deployments because RFC 3920 requires > > that a stream cannot be reused for more than one domain, thus > > necessitating multiple TCP connections. The group will work to overcome > > these challenges by defining an optional mechanism for using a single > > connection with multiple identities. It is anticipated that most of the > > work will consist of defining and providing requirements to the TLS and > > SASL working groups. > > > > In addition to the TCP binding defined in RFC 6120, the XMPP community > > has long employed an HTTP binding (XEP-0124 and XEP-0206 published by > > the XMPP Standards Foundation). Given that this binding uses HTTP long > > polling, which has many known issues (RFC 6202), it is reasonable to > > transition to use of the WebSocket protocol (RFC 6455) instead. Work has > > begun on defining a WebSocket subprotocol for XMPP > > (draft-moffitt-xmpp-over-websocket). The group will complete the > > definition of such a subprotocol, and coordinate reviews with the HYBI WG > > where appropriate. > > > > In completing its work, the group will strive to retain backwards > > compatibility with RFCs 3920 and 3921. However, changes that are not > > backwards compatible might be accepted if the group determines that the > > changes are required to meet the group's technical objectives and the > > group clearly documents the reasons for making them. > > _______________________________________________ > > xmpp mailing list > > xmpp@ietf.org > > https://www.ietf.org/mailman/listinfo/xmpp > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > --e89a8fb1f4c4c02f2d04d6454825 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1


On Thu, Feb 21, 2013 at 7:28 PM, Matt Miller (mamille2) <mami= lle2@cisco.com> wrote:
This looks good to me.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

On Feb 21, 2013, at 12:59 PM, Ben Campbell <ben@nostrum.com>
=A0wrote:

> Hi Everyone,
>
> We need to do a minor charter update to add the XMPP/WebSockets work.<= br> >
> Here's the proposed new text. This version is the same as before, = except it removes the text for XMPP interworking with SIP/SIMPLE, an adds t= ext for WebSockets. The new text is the second to last paragraph.
>
> Please send any feedback to the XMPP mailing list as soon as possible.= (If you agree with the text as is, please say that, too :-) )
>
> Thanks!
>
> Ben.
>
> -----------------
>
> The Extensible Messaging and Presence Protocol (XMPP) is an
> technology for the near-real-time exchange of messages and presence > notifications, where data is exchanged over Extensible Markup Language=
> (XML) streams. The original XMPP working group published RFCs 3920-392= 3.
>
> Implementation and deployment experience since that time has resulted<= br> > in errata, clarifications, and suggestions for improvement to the core=
> XMPP specifications (RFCs 3920 and 3921). Some technologies on which > XMPP depends (e.g., Transport Layer Security and the Simple
> Authentication and Security Layer) have undergone modifications of the= ir
> own, which XMPP needs to track. Finally, the group needs to define a > sustainable solution to internationalization of XMPP addresses, since<= br> > the approach taken in RFC 3920 (based on stringprep profiles) is limit= ed
> to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and
> draft-saintandre-rfc3921bis-* reflect community input so
> far regarding these modifications, but the group needs to complete thi= s
> work, especially with regard to internationalization. Because of the > scope of changes involved, it is envisioned that these specifications<= br> > will be cycled at Proposed Standard.
>
> Although RFC 3923 defines an end-to-end signing and encryption
> technology for use by XMPP systems, to date it has not been implemente= d.
> A goal of the group is to develop an implementable method for end-to-e= nd
> encryption, preferably based on well known and widely deployed securit= y
> technologies.
>
> XMPP uses TLS for encryption and the Simple Authentication and Securit= y
> Layer (SASL) for authentication. In the case of a server-to-server
> stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, > where each peer presents an X.509 certificate. This model introduces > scaling challenges in multi-domain deployments because RFC 3920 requir= es
> that a stream cannot be reused for more than one domain, thus
> necessitating multiple TCP connections. The group will work to overcom= e
> these challenges by defining an optional mechanism for using a single<= br> > connection with multiple identities. It is anticipated that most of th= e
> work will consist of defining and providing requirements to the TLS an= d
> SASL working groups.
>
> In addition to the TCP binding defined in RFC 6120, the XMPP community=
> has long employed an HTTP binding (XEP-0124 and XEP-0206 published by<= br> > the XMPP Standards Foundation). =A0Given that this binding uses HTTP l= ong
> polling, which has many known issues (RFC 6202), it is reasonable to > transition to use of the WebSocket protocol (RFC 6455) instead. =A0Wor= k has
> begun on defining a WebSocket subprotocol for XMPP
> (draft-moffitt-xmpp-over-websocket). =A0The group will complete the > definition of such a subprotocol, and coordinate reviews with the HYBI= WG
> where appropriate.
>
> In completing its work, the group will strive to retain backwards
> compatibility with RFCs 3920 and 3921. However, changes that are not > backwards compatible might be accepted if the group determines that th= e
> changes are required to meet the group's technical objectives and = the
> group clearly documents the reasons for making them.
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp

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

--e89a8fb1f4c4c02f2d04d6454825-- From fippo@goodadvice.pages.de Thu Feb 21 22:42:39 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA53A21F8E76 for ; Thu, 21 Feb 2013 22:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pg8sBfttr1q7 for ; Thu, 21 Feb 2013 22:42:38 -0800 (PST) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 5889721F8E6D for ; Thu, 21 Feb 2013 22:42:38 -0800 (PST) Received: from [192.168.2.100] (p549721D2.dip.t-dialin.net [84.151.33.210]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id r1M6gYjg002517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 22 Feb 2013 07:42:35 +0100 Message-ID: <51271356.2090407@goodadvice.pages.de> Date: Fri, 22 Feb 2013 07:42:30 +0100 From: Philipp Hancke User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: xmpp@ietf.org References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:42:40 -0000 Hi, > We need to do a minor charter update to add the XMPP/WebSockets work. I think we should update the paragraph on s2s as well. See below... > Here's the proposed new text. This version is the same as before, except it removes the text for XMPP interworking with SIP/SIMPLE, an adds text for WebSockets. The new text is the second to last paragraph. LGTM btw. [...] > XMPP uses TLS for encryption and the Simple Authentication and Security > Layer (SASL) for authentication. In the case of a server-to-server > stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, > where each peer presents an X.509 certificate. XMPP was not widely deployed that way in 2009 and is not today. s/is deployed/can be deployed/ > This model introduces > scaling challenges in multi-domain deployments because RFC 3920 requires > that a stream cannot be reused for more than one domain, thus > necessitating multiple TCP connections. The group will work to overcome > these challenges by defining an optional mechanism for using a single > connection with multiple identities. I think we have identified the operational problem of "secure delegation" as the issue we need to solve. The overview section from the DNA draft describes it quite well, but is way too long. Mh... The multiple-tcp-connections problem for s2s is a non-issue for me. bidi (xep-0288, currently in LC at the XSF; reviews appreciated) and the piggybacking mechanism from dialback (xep-0220) should solve it when it is clear how to solve delegation. > It is anticipated that most of the > work will consist of defining and providing requirements to the TLS and > SASL working groups. We took a different path, it is safe to remove that sentence. From zash@zash.se Thu Feb 21 22:47:10 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3D721F8EC6 for ; Thu, 21 Feb 2013 22:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q60zep5vLZ4c for ; Thu, 21 Feb 2013 22:47:09 -0800 (PST) Received: from sphyrna.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) by ietfa.amsl.com (Postfix) with ESMTP id 60A7621F8EBC for ; Thu, 21 Feb 2013 22:47:09 -0800 (PST) Received: from [IPv6:2001:470:def1:0:2088:edaf:2a2a:bdc7] (unknown [IPv6:2001:470:def1:0:2088:edaf:2a2a:bdc7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zash) by sphyrna.zash.se (Postfix) with ESMTPSA id 4F48B60088 for ; Fri, 22 Feb 2013 07:47:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=zash.se; s=b; t=1361515627; bh=mxeqtP5LHstnsMo2tyrpcnTOe8NH3dh0quPtMw8tOgY=; h=Date:From:To:Subject:References:In-Reply-To; b=ZuTEWFjvskzJPnlx05tln00cw5DpyMKScx9gmpPvvNY5WgieYGEVWem3F71UTtiMc AYuVTfifIAry/iv/TKTCbDMF0yft8KrP4lBRBmgJ+l7XpvA+BYm/VNb/oO7sAwbRiC Pbsd9FCYmFigTeU3aC6Ezx19jX2Ri/sxdnFe71IEPj2Dqg7fr4Dq/EtEakNUAuBLAT y2NZ+FIUGg1Nv587+W1oR1B98tQk/cYrqiaqCw01Ft9rrxLOqT4itK5Y2j89q490he l9qny/QEUSUG08gcneB7o3uKR9JmFcr2qCQ0ayWBSCrHFdMSGn11Pma4CkXwlA61ri jPYIRy5pw6Y6w== Message-ID: <5127146A.7000505@zash.se> Date: Fri, 22 Feb 2013 07:47:06 +0100 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: xmpp@ietf.org References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> X-Enigmail-Version: 1.5 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2CEEEDARFFHIOBLFSTQAU" Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 06:47:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CEEEDARFFHIOBLFSTQAU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-02-21 20:59, Ben Campbell wrote: > Here's the proposed new text. This version is the same as before, excep= t it removes the text for XMPP interworking with SIP/SIMPLE, an adds text= for WebSockets. The new text is the second to last paragraph. The new paragraph looks good to me. -- Kim "Zash" Alvefur ------enig2CEEEDARFFHIOBLFSTQAU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRJxRqAAoJEK3tmne2etMpLQkP/21yQfnimUEqXX/ASQ0WQpux 7fvZVwPbK1fYPAsJpF4gturzQJMYX7IfliPX3CVeon66DowbN2QPUQnsLrMazV5p gl0MZfI4gXc7yaW5MYQxU8qNATGEKDmh3G8Fwfs6d6lnn5ipi//8oNLYUuQxeyJg v6cXSxTt/ksA4+Crk8c74EaJPLuzjY8AQPj686Ro6AKs8rRAOg159diCVm6NJwgz 5h0I22NJVxPu0ImvXQ/tHRESOJLwRpnKzTj5dzDeJaMedTjNUKT2sPflgnHh4M6b p1Olk/JoZHGMqOZTXsHrbBoEJ/RBbrsKSLdOdOYpcgNc/Om7LL64uLx3D7KqDIVa smdobDOVrG29GJdSI1KPRPBzNRQi/BJVXuJg7MQlw1RiOt8aznjOCSSBuu1hm2kr Ci9I9XLjbHv8tyCxpUFm5wXDgAq5vxp5XyxJqa4h10kIJ/YUKiNGoOj9unOG0qs+ ERytrH5az/ji+JCWfinvvjVhzfL9kDIPaVLIn0xUTYoQLWU0LfJmTv5pMAGIIsCd S3qqMHFBvX8Po7IBihdiCLQqfxoEr30IQaXm1P259T6C9EM02DKhON2xZckIRlr1 wrKrvO8MA1izk+wepmXTIPi9BlJd6YKwkcqw2VqbSEjq4HDv5VDWrZnjIMOnrPdw DCrVz2vcmV69Ow94MV1Y =IYCo -----END PGP SIGNATURE----- ------enig2CEEEDARFFHIOBLFSTQAU-- From dave@cridland.net Fri Feb 22 02:14:54 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8924121F8E71 for ; Fri, 22 Feb 2013 02:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23d+cwpY8SOA for ; Fri, 22 Feb 2013 02:14:53 -0800 (PST) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by ietfa.amsl.com (Postfix) with ESMTP id 91C3B21F867E for ; Fri, 22 Feb 2013 02:14:52 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id ef5so416017obb.39 for ; Fri, 22 Feb 2013 02:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iaEPCjfHZOdY5ZOn3YFGK1ToPym7rUuYSAbBU+QHSB0=; b=IR+pR5Jj67ahxX3hZ0roXOqi/ue0WO0FZLJfYBAK3A/ZplTB9zWVLl+fKrkKIZ8w93 V/XoeJvFxFHYyCgaISuAHpXvV5AXYAeNLhVa/0Me7xpo6vTjEWhpGSWSjCLNsO03IeAe VfwgyQ+Zsg0BmrqGq6KqaXeeGAtzyrZP2Pm1I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=iaEPCjfHZOdY5ZOn3YFGK1ToPym7rUuYSAbBU+QHSB0=; b=NZqnGAzi75OqIiJBgUBOI0zYKknAq4sAebYH/QyWG49ZXdNdLkOm/V/vI6dPybfKbN d9nljwtluNx+Fgkm/liSEAz0D7cxrSPeCje+UqXlDil+rs1iL+e+3zWOIfOM6dZxaVlk 8LOkf5/U+ALWWodcn7tkH1W5QkFhcTf3REKKxjevpwGqSMzQqcvW2S2M1Bdzqgi/tWID OJO7yS3wQ6cLcJKEqpA66WQXTc7WDTd3uwForOj/y1b9eFI3UokUVBxkZmOgUMApQBIB 2iC7s1CsbtlYtt4IH3+6tQEIQI76hWNfAxQkkn2mxHRyhEUqlto5I0OdlWv0iZpMO2wP 7LHA== MIME-Version: 1.0 X-Received: by 10.182.220.10 with SMTP id ps10mr575661obc.21.1361528092265; Fri, 22 Feb 2013 02:14:52 -0800 (PST) Received: by 10.60.125.69 with HTTP; Fri, 22 Feb 2013 02:14:52 -0800 (PST) Received: by 10.60.125.69 with HTTP; Fri, 22 Feb 2013 02:14:52 -0800 (PST) In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> Date: Fri, 22 Feb 2013 10:14:52 +0000 Message-ID: From: Dave Cridland To: Ben Campbell Content-Type: multipart/alternative; boundary=f46d044796fd4a8d1604d64d76a1 X-Gm-Message-State: ALoCoQn0lfSHbpubjitPaJ8q7LByauO0Krj0o5Tp1L12el9W5oJtf7W/1CkNzM1CnXI30LkLgZ+y Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:14:54 -0000 --f46d044796fd4a8d1604d64d76a1 Content-Type: text/plain; charset=ISO-8859-1 On 21 Feb 2013 19:59, "Ben Campbell" wrote: > We need to do a minor charter update to add the XMPP/WebSockets work. > Proposed new text looks fine, but has anyone considered the option of spinning out a new WG to handle this work? It seems to me that a smaller, more focussed WG might get the work done quicker (it worked for IMAP MOVE), and in addition the WG members might be drawn from both HyBi and XMPP circles that way, whereas working on it here might exclude the HyBi community to a degree. If this has already been considered, I'm not going to fight this one. Dave. --f46d044796fd4a8d1604d64d76a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 21 Feb 2013 19:59, "Ben Campbell" <ben@nostrum.com> wrote:
> We need to do a minor charter update to add the XMPP/WebSockets work.<= br> >

Proposed new text looks fine, but has anyone considered the = option of spinning out a new WG to handle this work?

It seems to me that a smaller, more focussed WG might get th= e work done quicker (it worked for IMAP MOVE), and in addition the WG membe= rs might be drawn from both HyBi and XMPP circles that way, whereas working= on it here might exclude the HyBi community to a degree.

If this has already been considered, I'm not going to fi= ght this one.

Dave.

--f46d044796fd4a8d1604d64d76a1-- From ben@nostrum.com Fri Feb 22 05:55:01 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E07D21F8EAF for ; Fri, 22 Feb 2013 05:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkORijOVxWrm for ; Fri, 22 Feb 2013 05:54:54 -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 0A34F21F8E6C for ; Fri, 22 Feb 2013 05:54:51 -0800 (PST) Received: from [10.0.1.14] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1MDslM1046530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2013 07:54:48 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Fri, 22 Feb 2013 07:54:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> To: Dave Cridland X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 13:55:01 -0000 On Feb 22, 2013, at 4:14 AM, Dave Cridland wrote: >=20 > On 21 Feb 2013 19:59, "Ben Campbell" wrote: > > We need to do a minor charter update to add the XMPP/WebSockets = work. > > >=20 > Proposed new text looks fine, but has anyone considered the option of = spinning out a new WG to handle this work? >=20 > It seems to me that a smaller, more focussed WG might get the work = done quicker (it worked for IMAP MOVE), and in addition the WG members = might be drawn from both HyBi and XMPP circles that way, whereas working = on it here might exclude the HyBi community to a degree. >=20 > If this has already been considered, I'm not going to fight this one. Hi Dave, It had been discussed among the chairs and ADs. We were of the opinion = that the work needed expertise from xmpp, and we weren't sure if we = would get the same expertise in a separate working group (or as an AD = sponsored draft). Your point about hybi is true to some extent, = although I think we already get some crossover. We could certainly reconsider that if other's share your opinion. What = do other's think? Thanks! Ben. >=20 > Dave. >=20 From stpeter@stpeter.im Fri Feb 22 08:27:42 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408C421F8EEF for ; Fri, 22 Feb 2013 08:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGoy8V0kOY1b for ; Fri, 22 Feb 2013 08:27:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 15B0B21F8E22 for ; Fri, 22 Feb 2013 08:27:41 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DA8D0403CD; Fri, 22 Feb 2013 09:35:14 -0700 (MST) Message-ID: <51279C78.8040108@stpeter.im> Date: Fri, 22 Feb 2013 09:27:36 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Dave Cridland References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 16:27:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/22/13 3:14 AM, Dave Cridland wrote: > On 21 Feb 2013 19:59, "Ben Campbell" wrote: >> We need to do a minor charter update to add the XMPP/WebSockets >> work. >> > > Proposed new text looks fine, but has anyone considered the option > of spinning out a new WG to handle this work? > > It seems to me that a smaller, more focussed WG might get the work > done quicker (it worked for IMAP MOVE), and in addition the WG > members might be drawn from both HyBi and XMPP circles that way, > whereas working on it here might exclude the HyBi community to a > degree. A separate WG to define a simple WebSocket sub-protocol? - -1 Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJ5x4AAoJEOoGpJErxa2p38sQAJzgAb7nmPcyUfzkM/Xla2BB KCDgwbtJ4iKisn7KYx+ycpFKJmWhRL33+jmjfuXp/9Xm3iGsXvxYJqJAVIkgYWrQ XETpg4Y2guRtXjzpy60XX9Z8L/XjANLpXgQ1MuE/ZG6xLWnW30Db0rYGlI0tOKIl /cqxmp3V0hAR5GF8+JDfzYX8cyYarRq1mqUDePKaRVTUokTLDj3wY4Q37tCrUE0E SS3rJjdLckBPHth7JZjQVBiuhT1RS5ksRtTFkwGxSmAbZbRD974w8NqQ0FR7O88O eRsB2LZ+W8s3qZFyj+ca92tU9f4rj7CGLs6X2kZr0NJg11YAgLXem+KSzUI9FOjI esZ5VPw0bM5omf3I3wppz5a4XWbzch3vh6iy1rHdAzI98mL3csFc3j6EY0OiZE8E tmaPIyS+R+CGMDy6F5780F3ajEEFFQMDMwGN0a3DUFyibYVCn+m1jqcnc/jiH3Wk OiZCqoVDlmaQ+c+MgTCBnhujFt25rJF/FA5nc82qVvAAKX26LcnggeZPMS2GLrN6 Boc7tnNyZiy0Ka6/nFx5C4PUVytDJz9tbLfE4/GQqGBQgY0zGIcqBWzmNyCUGCRI 8visXjN0xMeU3pqXkLuSuHWJqR1wXwfMBykprmgqOY3mYq6A2+QrlN5yj/T95+NO WzKtBrcWk6ypNOhZjzB4 =3srZ -----END PGP SIGNATURE----- From stpeter@stpeter.im Fri Feb 22 14:43:44 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D965221F8DDB for ; Fri, 22 Feb 2013 14:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjJSmXWsm9aY for ; Fri, 22 Feb 2013 14:43:43 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id AB96421F8DB4 for ; Fri, 22 Feb 2013 14:43:38 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 58E51403CD for ; Fri, 22 Feb 2013 15:51:06 -0700 (MST) Message-ID: <5127F48A.8000309@stpeter.im> Date: Fri, 22 Feb 2013 15:43:22 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: XMPP Working Group X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] updated DNA specs X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 22:43:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matt Miller and I have updated our three Internet-Drafts about domain name associations in XMPP: https://datatracker.ietf.org/doc/draft-saintandre-xmpp-dna/ https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype/ https://datatracker.ietf.org/doc/draft-miller-xmpp-posh-prooftype/ The second two received only minor edits, but the first one has been mostly rewritten so that the concepts are much clearer. Your feedback is welcome! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJ/SJAAoJEOoGpJErxa2p2DMP/i6qMEXpejWk6JIte++q7Xnk 7q2+3NKPGs8YvYW94w/T6x/QjQsLJUnf2saFX9+KuPMBig7ikSkJfXupduLUad7J nfSvF6HMgFsT7vHIajCbX81pTCj9MH+z07/IuQcLvLlSaB9FxxdQ+FsZwBp4Bk2D lRSMQb7ihYWHulUGDp6aaNx0Stxkt8k7O1lGMG2nNOjSnHUwqj/1VGJ94T32jXFE G3weD7FOf7zOKuLtjAm19zZRite0xU8hXhgBS4D4PhKnH013WCJlzldRLYSPktFU JqxU++k8JGHtO/8CxGI7Nl0dwew4aEgpNM30RnuUZA6JHhpglFPKTbaqh3HbxQnP sBRHA0EZZ7aAJ8GX0nOubnpCkR5aqm8S12XcuD6axN01NWniD8KQF42BPiLsEZfg b/rp9/kz1EzrerXJX7TaRi4/jXvmWLR6nargk0AcpzYEvVDSTzH874FewWCnT8uK xjCZNZ0DCjUEOiVZk3jFll973iGdv1rOenQE3KtpulTiN39jBzybybgX4EUFE3Uu cAvIf7AKG88x+Qzex/0yauR7SOm702Us0ETEU16Z8CiRM9q5jCdLE0FeLCukYNs9 gd/fHNeJbz75Kd39Ry2/ANn5JgiK5HB+KluB1YxjBHJADrgnarWbCoHQhjuku5jj TR8lwTL1KcdCdsqt8DJN =KUy/ -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Mon Feb 25 08:08:27 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72AF21F9441 for ; Mon, 25 Feb 2013 08:08:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t48sO1diiuWQ for ; Mon, 25 Feb 2013 08:08:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5F21F9440 for ; Mon, 25 Feb 2013 08:08:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 327BFBE1C; Mon, 25 Feb 2013 16:08:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkfrYTQ7syQ9; Mon, 25 Feb 2013 16:08:03 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.51.99]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A78A5BDC7; Mon, 25 Feb 2013 16:08:03 +0000 (GMT) Message-ID: <512B8C63.3020208@cs.tcd.ie> Date: Mon, 25 Feb 2013 16:08:03 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Campbell References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> In-Reply-To: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:08:27 -0000 Hi, I've no objection to this charter but do have a question: Q: loads of us use OTR, but there's no mention of that in the charter - why don't we just spec that in an RFC? Or two RFCs if need be, one for what's done now, one with any changes the WG think are needed and will be deployed. A quick web search leads me to believe that this [1] might be how OTR works, but I could be wrong. Even having an informational RFC as a stable reference would seem to be an improvement. Sorry if there's an obvious answer and I've not got the history. Ta, S. [1] http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html On 02/21/2013 07:59 PM, Ben Campbell wrote: > Hi Everyone, > > We need to do a minor charter update to add the XMPP/WebSockets work. > > Here's the proposed new text. This version is the same as before, except it removes the text for XMPP interworking with SIP/SIMPLE, an adds text for WebSockets. The new text is the second to last paragraph. > > Please send any feedback to the XMPP mailing list as soon as possible. (If you agree with the text as is, please say that, too :-) ) > > Thanks! > > Ben. > > ----------------- > > The Extensible Messaging and Presence Protocol (XMPP) is an > technology for the near-real-time exchange of messages and presence > notifications, where data is exchanged over Extensible Markup Language > (XML) streams. The original XMPP working group published RFCs 3920-3923. > > Implementation and deployment experience since that time has resulted > in errata, clarifications, and suggestions for improvement to the core > XMPP specifications (RFCs 3920 and 3921). Some technologies on which > XMPP depends (e.g., Transport Layer Security and the Simple > Authentication and Security Layer) have undergone modifications of their > own, which XMPP needs to track. Finally, the group needs to define a > sustainable solution to internationalization of XMPP addresses, since > the approach taken in RFC 3920 (based on stringprep profiles) is limited > to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and > draft-saintandre-rfc3921bis-* reflect community input so > far regarding these modifications, but the group needs to complete this > work, especially with regard to internationalization. Because of the > scope of changes involved, it is envisioned that these specifications > will be cycled at Proposed Standard. > > Although RFC 3923 defines an end-to-end signing and encryption > technology for use by XMPP systems, to date it has not been implemented. > A goal of the group is to develop an implementable method for end-to-end > encryption, preferably based on well known and widely deployed security > technologies. > > XMPP uses TLS for encryption and the Simple Authentication and Security > Layer (SASL) for authentication. In the case of a server-to-server > stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, > where each peer presents an X.509 certificate. This model introduces > scaling challenges in multi-domain deployments because RFC 3920 requires > that a stream cannot be reused for more than one domain, thus > necessitating multiple TCP connections. The group will work to overcome > these challenges by defining an optional mechanism for using a single > connection with multiple identities. It is anticipated that most of the > work will consist of defining and providing requirements to the TLS and > SASL working groups. > > In addition to the TCP binding defined in RFC 6120, the XMPP community > has long employed an HTTP binding (XEP-0124 and XEP-0206 published by > the XMPP Standards Foundation). Given that this binding uses HTTP long > polling, which has many known issues (RFC 6202), it is reasonable to > transition to use of the WebSocket protocol (RFC 6455) instead. Work has > begun on defining a WebSocket subprotocol for XMPP > (draft-moffitt-xmpp-over-websocket). The group will complete the > definition of such a subprotocol, and coordinate reviews with the HYBI WG > where appropriate. > > In completing its work, the group will strive to retain backwards > compatibility with RFCs 3920 and 3921. However, changes that are not > backwards compatible might be accepted if the group determines that the > changes are required to meet the group's technical objectives and the > group clearly documents the reasons for making them. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp > > From mamille2@cisco.com Mon Feb 25 08:34:41 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8B421F9391 for ; Mon, 25 Feb 2013 08:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxUsqdN8KnqZ for ; Mon, 25 Feb 2013 08:34:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 08CC121F9388 for ; Mon, 25 Feb 2013 08:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8886; q=dns/txt; s=iport; t=1361810080; x=1363019680; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=q0GK+nhEQ4IVDGf0o6Xx4aNI8lQk1rcdyZbEbKeA0X4=; b=XCazw8UOP6lGrS0U5nXQDTkI5q81Ujtdn19AezxcrdazUqQwqv2uk3h2 CKsujyYrLJB50C2rhmhIIFNCCq9bwtelSF1Cj39QT4gz8HuxVJGagqCQ2 CUcOF0d8Q9E52h2zPW+JNkr3Rj+CuRJuiQyF87O++SJ/hgy4dis4dFlxR s=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGKSK1GtJV2d/2dsb2JhbABFwVWBBRZzgh8BAQEDAQEBAWsLEAIBCBgKJAIlCyUCBA4FCAYGB4dyBgy/Io1HgRYWGwIFgl9hA48jgSaWWYMHgWk+ X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="p7s'?scan'208";a="180885156" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 25 Feb 2013 16:34:39 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGYdng014807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:34:39 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:34:38 -0600 From: "Matt Miller (mamille2)" To: Stephen Farrell Thread-Topic: [xmpp] Proposed XMPP Charter Update Thread-Index: AQHOEG3wgKlUzi3iykKWjJHftGObMZiLKE2AgAAHbQA= Date: Mon, 25 Feb 2013 16:34:38 +0000 Message-ID: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> In-Reply-To: <512B8C63.3020208@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.114.169] Content-Type: multipart/signed; boundary="Apple-Mail=_C6796054-4C7F-4B07-A3DE-BFC236390D27"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:34:41 -0000 --Apple-Mail=_C6796054-4C7F-4B07-A3DE-BFC236390D27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We have talked about OTR, but from what I remember, various folks = haven't been interested in doing the work to bring it in. Peter = Saint-Andre might be able to speak more on that front. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Feb 25, 2013, at 9:08 AM, Stephen Farrell wrote: >=20 > Hi, >=20 > I've no objection to this charter but do have a question: >=20 > Q: loads of us use OTR, but there's no mention of that > in the charter - why don't we just spec that in an RFC? >=20 > Or two RFCs if need be, one for what's done now, one with > any changes the WG think are needed and will be deployed. >=20 > A quick web search leads me to believe that this [1] > might be how OTR works, but I could be wrong. Even having > an informational RFC as a stable reference would seem > to be an improvement. >=20 > Sorry if there's an obvious answer and I've not got the > history. >=20 > Ta, > S. >=20 > [1] http://www.cypherpunks.ca/otr/Protocol-v3-4.0.0.html >=20 > On 02/21/2013 07:59 PM, Ben Campbell wrote: >> Hi Everyone, >>=20 >> We need to do a minor charter update to add the XMPP/WebSockets work.=20= >>=20 >> Here's the proposed new text. This version is the same as before, = except it removes the text for XMPP interworking with SIP/SIMPLE, an = adds text for WebSockets. The new text is the second to last paragraph. >>=20 >> Please send any feedback to the XMPP mailing list as soon as = possible. (If you agree with the text as is, please say that, too :-) ) >>=20 >> Thanks! >>=20 >> Ben. >>=20 >> ----------------- >>=20 >> The Extensible Messaging and Presence Protocol (XMPP) is an >> technology for the near-real-time exchange of messages and presence >> notifications, where data is exchanged over Extensible Markup = Language >> (XML) streams. The original XMPP working group published RFCs = 3920-3923. >>=20 >> Implementation and deployment experience since that time has resulted >> in errata, clarifications, and suggestions for improvement to the = core >> XMPP specifications (RFCs 3920 and 3921). Some technologies on which >> XMPP depends (e.g., Transport Layer Security and the Simple >> Authentication and Security Layer) have undergone modifications of = their >> own, which XMPP needs to track. Finally, the group needs to define a >> sustainable solution to internationalization of XMPP addresses, since >> the approach taken in RFC 3920 (based on stringprep profiles) is = limited >> to Unicode 3.2 characters. Both draft-saintandre-rfc3920bis-* and >> draft-saintandre-rfc3921bis-* reflect community input so >> far regarding these modifications, but the group needs to complete = this >> work, especially with regard to internationalization. Because of the >> scope of changes involved, it is envisioned that these specifications >> will be cycled at Proposed Standard. >>=20 >> Although RFC 3923 defines an end-to-end signing and encryption >> technology for use by XMPP systems, to date it has not been = implemented. >> A goal of the group is to develop an implementable method for = end-to-end >> encryption, preferably based on well known and widely deployed = security >> technologies. >>=20 >> XMPP uses TLS for encryption and the Simple Authentication and = Security >> Layer (SASL) for authentication. In the case of a server-to-server >> stream, XMPP is deployed using TLS and the SASL EXTERNAL mechanism, >> where each peer presents an X.509 certificate. This model introduces >> scaling challenges in multi-domain deployments because RFC 3920 = requires >> that a stream cannot be reused for more than one domain, thus >> necessitating multiple TCP connections. The group will work to = overcome >> these challenges by defining an optional mechanism for using a single >> connection with multiple identities. It is anticipated that most of = the >> work will consist of defining and providing requirements to the TLS = and >> SASL working groups. >>=20 >> In addition to the TCP binding defined in RFC 6120, the XMPP = community >> has long employed an HTTP binding (XEP-0124 and XEP-0206 published by=20= >> the XMPP Standards Foundation). Given that this binding uses HTTP = long=20 >> polling, which has many known issues (RFC 6202), it is reasonable to=20= >> transition to use of the WebSocket protocol (RFC 6455) instead. Work = has >> begun on defining a WebSocket subprotocol for XMPP=20 >> (draft-moffitt-xmpp-over-websocket). The group will complete the=20 >> definition of such a subprotocol, and coordinate reviews with the = HYBI WG=20 >> where appropriate. >>=20 >> In completing its work, the group will strive to retain backwards >> compatibility with RFCs 3920 and 3921. However, changes that are not >> backwards compatible might be accepted if the group determines that = the >> changes are required to meet the group's technical objectives and the >> group clearly documents the reasons for making them. >> _______________________________________________ >> 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 --Apple-Mail=_C6796054-4C7F-4B07-A3DE-BFC236390D27 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDIyNTE2MzQzOFowIwYJKoZIhvcNAQkEMRYEFIX8nocpBq76jUVl56X/j9ON5cLDMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCWLpdzffnX8wuBPFX4qOkjTZmvSVLv7AUtcxaiGRt1 aWfSbc9nRiJfqc26eT/+rlRUeX9WSmDt4Kh+grIUFyoeSxGlPXD5bmWieuPyGItQgTqOLUGNVxRm rbgceHqikUmOGwwNcspiEvsXaxqpaRA4wYCwTRR0CxOlLuxDKOWSMmraXxkg8JGVX0eg9+koxq67 YOqVS90oAzUfe5zIBFij/QlRTr0UBtMTMusAQsu9IEgfyLxXbdca1dpvt+ZXALS5d5yM3SIduYKK V9j0V9IBJUJe9NfMYcs7ICj31vNz5+IF+qR6YxWHMxIgfij0X5ywXfrIEOFd73d/3mwFUozEAAAA AAAA --Apple-Mail=_C6796054-4C7F-4B07-A3DE-BFC236390D27-- From stpeter@stpeter.im Mon Feb 25 08:54:43 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3636321F9525 for ; Mon, 25 Feb 2013 08:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyAzH83BDxP5 for ; Mon, 25 Feb 2013 08:54:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1364B21F9527 for ; Mon, 25 Feb 2013 08:54:41 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8A44A4004E; Mon, 25 Feb 2013 10:02:24 -0700 (MST) Message-ID: <512B9756.2020008@stpeter.im> Date: Mon, 25 Feb 2013 09:54:46 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stephen Farrell References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> In-Reply-To: <512B8C63.3020208@cs.tcd.ie> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:54:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/13 9:08 AM, Stephen Farrell wrote: > > Hi, > > I've no objection to this charter but do have a question: > > Q: loads of us use OTR, but there's no mention of that in the > charter - why don't we just spec that in an RFC? > > Or two RFCs if need be, one for what's done now, one with any > changes the WG think are needed and will be deployed. > > A quick web search leads me to believe that this [1] might be how > OTR works, but I could be wrong. Even having an informational RFC > as a stable reference would seem to be an improvement. > > Sorry if there's an obvious answer and I've not got the history. I have reached out repeatedly to the OTR folks. I shall do so again right now, since there was some discussion on the otr-dev list recently about someone working on an Internet-Draft. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK5dVAAoJEOoGpJErxa2pxfgP/AqTGDwh0r8Ldj9+VHoth1UA ktnipw90/h57cocmrVR5Sq5r8Nrz/NRsqeTAx1NNaRJn+bCypUtdkrmIHPAMi6Vh LDhrBMsrlzf9G0ULYC5ZarbBkeblBYxkzOop3NXUobXJdsYMxS/2Td292fcsQBHn 8cVcci2e06kgifpkBuSX41TqdgFxUwaPlBaFv+wpCs8u9ReNcoqVIBuR4YambvMg odR2+NdhsUWQeOMSPufGnxesO5tAGOykYzNGcXd327AyA8mOECLH1W5QloEpCA2n rvHcnIXUs2mg0GMKzNqFgts4fwxi6tQ8Y3Qdz803NSlZWfbeRgNt8s/zLoshbRsq Zsgg1ifv4ouFoghd88NJmaAfnLyhPuJGAZWzottrcjPItaS2GW2VDUq6fInAscWq 1abKW+DftquSQJhP5l3RPlFjFhlprpUbmflPIMWkhQ674bwt03Sua0UjqdlPwies jNcPNJ9OpbmQSTJeHdqOPj57aaVafbR6v6WK9F9PYcYkoDUHrRfrEXaVD5443tG/ 7prVG1Je4Z3zopiNVPGop+6mkPHKE1tVqyCqq4ifWmZSbGJFYmQ6d5F6LhWA8PYu yQuWm2sz46hzS69WTSQEDrful7nvUcNSOg3jesu2GAdxRRYEpZHPNEJvfZIrOIp3 MJsDT4HL1WoPrIUvNomE =u88F -----END PGP SIGNATURE----- From stpeter@stpeter.im Mon Feb 25 09:06:48 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB80421F95E2 for ; Mon, 25 Feb 2013 09:06:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdeWJSI7vS7s for ; Mon, 25 Feb 2013 09:06:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 08BD721F95D4 for ; Mon, 25 Feb 2013 09:06:48 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2360340564; Mon, 25 Feb 2013 10:14:31 -0700 (MST) Message-ID: <512B9A2D.4040505@stpeter.im> Date: Mon, 25 Feb 2013 10:06:53 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Stephen Farrell References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> <512B9756.2020008@stpeter.im> In-Reply-To: <512B9756.2020008@stpeter.im> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:06:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/13 9:54 AM, Peter Saint-Andre wrote: > I have reached out repeatedly to the OTR folks. I shall do so > again right now, since there was some discussion on the otr-dev > list recently about someone working on an Internet-Draft. Done. I'll let you know if anything concrete (like an effort to publish an Internet-Draft) comes of it this time... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK5otAAoJEOoGpJErxa2pF2AP/jdCDcHQV9QPeBoxXI2AxCA7 JdPONCBxcNCMpTERq5ZGmO0nASIEj768YekDE6+Qr5KVSzpiqwfbIwjUrzmgEL8S lQDmRrTVkqjhOxq5sFJ81n4EEe6vOAdC4754Z0YXFZU6jgH1SeeNReGxM70KLPNW zHs3EhTUaJ4zrsJB2wLBM6mQMNZnRGoNJBkBI7hwkVnehFwbfm2ZH9SGQ45l2Jjo 6yWtuH2jfn3hhB6r1N/UQrktoMIXnALYBZfzWEucuhbDE+dVK7JKyU9tGKinKdV4 P3/pw3UI+UE0Vmh1EHTbUGmlfh9xFExWi2MvPenqotltAd4VJ8hA6ZWyssrbeciV qLTkzC8RVvAyiK7YJ9E7KyypkK1VEpik9OCR0GYIB2BoBrQCfcc8KnuzggyY+4PD 9P5YMoX1jKd2KyIYRDsUU04zHedpzTtFc1ceARjjws/xk8nOw8Y1gDPbe88QECcP 4gFXI0Bn2quYHaYJmiNIy6ZeANveddLaVZ87elXepqT/+kN1seULhff59mIcQHSc b/lo71heX2i6OC8j7nS97+X2VufcvOT7dn3dBWuXIyyswlnnjEflMPX0mBQgFiGY Xe6+lu2uS22sQNisB0E3jJXpAuc+wtdgpHKIv8Q1kg8XVgmRmn9lL/fJMaUMrYUb YM04cTXo4ELMx6c0fenL =XtRi -----END PGP SIGNATURE----- From ben@nostrum.com Mon Feb 25 09:14:59 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D37A21F958B for ; Mon, 25 Feb 2013 09:14:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veHFuMWiHhDV for ; Mon, 25 Feb 2013 09:14: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 3BC1421F958A for ; Mon, 25 Feb 2013 09:14:53 -0800 (PST) Received: from [10.119.74.38] (69.147.243.203.rdns.ubiquityservers.com [69.147.243.203] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1PHEY9A041402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 25 Feb 2013 11:14:35 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <512B9A2D.4040505@stpeter.im> Date: Mon, 25 Feb 2013 11:14:30 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> <512B9756.2020008@stpeter.im> <512B9A2D.4040505@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 69.147.243.203 is authenticated by a trusted mechanism) Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:14:59 -0000 (As individual) On Feb 25, 2013, at 11:06 AM, Peter Saint-Andre = wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On 2/25/13 9:54 AM, Peter Saint-Andre wrote: >=20 >> I have reached out repeatedly to the OTR folks. I shall do so >> again right now, since there was some discussion on the otr-dev >> list recently about someone working on an Internet-Draft. >=20 > Done. I'll let you know if anything concrete (like an effort to > publish an Internet-Draft) comes of it this time... >=20 If we are talking about potential _future_ OTR work, does it make sense = to go ahead with the proposed charter as is, then worry about OTR when = there's a concrete proposal? That is, rather than holding up the = adoption of the currently proposed charter for something that might = happen in the future? Thanks! Ben. From stpeter@stpeter.im Mon Feb 25 09:24:11 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0821F9590 for ; Mon, 25 Feb 2013 09:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXTh4qRd5mva for ; Mon, 25 Feb 2013 09:24:08 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 223B921F9546 for ; Mon, 25 Feb 2013 09:24:08 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F24344060C; Mon, 25 Feb 2013 10:31:51 -0700 (MST) Message-ID: <512B9E3D.5090508@stpeter.im> Date: Mon, 25 Feb 2013 10:24:13 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Ben Campbell References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> <512B9756.2020008@stpeter.im> <512B9A2D.4040505@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:24:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/13 10:14 AM, Ben Campbell wrote: > (As individual) > > On Feb 25, 2013, at 11:06 AM, Peter Saint-Andre > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 2/25/13 9:54 AM, Peter Saint-Andre wrote: >> >>> I have reached out repeatedly to the OTR folks. I shall do so >>> again right now, since there was some discussion on the >>> otr-dev list recently about someone working on an >>> Internet-Draft. >> >> Done. I'll let you know if anything concrete (like an effort to >> publish an Internet-Draft) comes of it this time... >> > > If we are talking about potential _future_ OTR work, does it make > sense to go ahead with the proposed charter as is, then worry about > OTR when there's a concrete proposal? That is, rather than holding > up the adoption of the currently proposed charter for something > that might happen in the future? IMHO, let's get this small recharter done (which is only to add the WebSocket item) and then consider rechartering again if the OTR work surfaces. Initial hints based on my pokage earlier today are promising, but I wouldn't want to hold up the WebSocket work. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK549AAoJEOoGpJErxa2pGNEP/0TBehZt1Qx8N3aCM2OsEYLQ J9N2rcOrDq1xAIRkklbC1AqU/luZrsCywfqd4wPG1z+e0qIEdJ47OQHCLHwuUXta Cl9sFbwUCKPAWmB9YTbA0p+72jUVkNPmvbYBXZd2JE2HffB5UsyFDrexs0Ip1FJi VpmjsY9nKwGWktR/5UTuTaylAJ2h1Br1psZEpnA+GeMdcYImZd4a9zA457OeikQI XLYAPSnU/nHnJMKKFUNs/q/1o7nwv/XUNxIcXS5d1nkhIoTLe+J17BWGqvaqtOtK 5OLHq9ley+EzZH+sj6R/UiO74GCY7inuPRKvBF2eNaZKx6SX/MziWc8sUrPCSpU5 FVsCHo/paDVvPsVSfQZ9ofBhwQBIUBkMrkaslbWtH8vPEuHDymnyjblTcMU1NX00 YI5JmPvPxhiUPJEPR5QgRLN+5uL7UvcxYx/1QyQWqLA4grCJtFMuauldIs8jmmKu M7C7aW/6NTPfZQSvGB9WxJ7HAVLg9eq963qo7nO1CgGqxQyXsJiybe35AYYZcwIr asMwpcWfldPNvs4EqtkxIO71/O7IZh4ohRSlyhE6uZW8K3lLkpYXWy6bIjh3fwPq ODrIg7fUax3Y69VTsRIKhPjy1Dik9FUA0DpXTUOKd++DIFS77jbvlsyl5apsPKmv JpiB8j8wUJjjOagAIfwA =Uvsx -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Mon Feb 25 09:24:15 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09C021F9575 for ; Mon, 25 Feb 2013 09:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqlRcvAdcuCr for ; Mon, 25 Feb 2013 09:24:15 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB3CE21F94F8 for ; Mon, 25 Feb 2013 09:24:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 32161BE20; Mon, 25 Feb 2013 17:23:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alEXFeFYye6O; Mon, 25 Feb 2013 17:23:52 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.45.51.99]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 51A15BDC7; Mon, 25 Feb 2013 17:23:52 +0000 (GMT) Message-ID: <512B9E28.4060804@cs.tcd.ie> Date: Mon, 25 Feb 2013 17:23:52 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Ben Campbell References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> <512B9756.2020008@stpeter.im> <512B9A2D.4040505@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: XMPP Working Group Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:24:15 -0000 On 02/25/2013 05:14 PM, Ben Campbell wrote: > (As individual) > > On Feb 25, 2013, at 11:06 AM, Peter Saint-Andre wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 2/25/13 9:54 AM, Peter Saint-Andre wrote: >> >>> I have reached out repeatedly to the OTR folks. I shall do so >>> again right now, since there was some discussion on the otr-dev >>> list recently about someone working on an Internet-Draft. >> >> Done. I'll let you know if anything concrete (like an effort to >> publish an Internet-Draft) comes of it this time... >> > > If we are talking about potential _future_ OTR work, does it make sense to go ahead with the proposed charter as is, then worry about OTR when there's a concrete proposal? That is, rather than holding up the adoption of the currently proposed charter for something that might happen in the future? Just in case its not clear: I'm not at all suggesting holding anything up. S. > Thanks! > > Ben. > > From zash@zash.se Mon Feb 25 09:24:46 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135A921F946D for ; Mon, 25 Feb 2013 09:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO3NxKpDalOi for ; Mon, 25 Feb 2013 09:24:45 -0800 (PST) Received: from sphyrna.zash.se (ip66.hethane.riksnet.nu [85.11.25.66]) by ietfa.amsl.com (Postfix) with ESMTP id E78A321F9346 for ; Mon, 25 Feb 2013 09:24:44 -0800 (PST) Received: from [IPv6:2001:470:dc92:0:81d7:b6e6:8481:835c] (unknown [IPv6:2001:470:dc92:0:81d7:b6e6:8481:835c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zash) by sphyrna.zash.se (Postfix) with ESMTPSA id D5882603C1 for ; Mon, 25 Feb 2013 18:24:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=zash.se; s=b; t=1361813082; bh=8DxcDESnG8W2XNf/qYHLTGqoGrqU8wZcxay4uLaT74M=; h=Date:From:To:Subject:References:In-Reply-To; b=UrLKWuv9QTMVW0/Td/XM3eq7aGvfV/JijFhq5Ggz1tuBkGUZ7aiL7vkHOG1hy1wf7 TOBWF9xlzLI8H3y30caRpQ1PtkCN75aPCdExvTYjr/2IBklPxzW21It/BedU2g54KQ MDJ+/aKN49yYw+BnBs+2gjaDRRFsJX4xEHm97KratkfNB8K9AVyeUPUXZnSvfsAwpF Ir8tkGUt4C20T8IttMFq6F4t9O1fIyKT5AyAGXrUjv1S0/xRPnNYwW/OwxmpqGHSqj dIxZuWkHek949u2wZgkuXr8AqhJtl+KK/DLwl3yoW//mgw4ZSHR2rOsXoS1GhbEb5P HxZZs5aBQ2iYw== Message-ID: <512B9E59.1040409@zash.se> Date: Mon, 25 Feb 2013 18:24:41 +0100 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: xmpp@ietf.org References: <5B57D373-3ECA-4336-ABD2-A5A76909C2D5@nostrum.com> <512B8C63.3020208@cs.tcd.ie> <512B9756.2020008@stpeter.im> <512B9A2D.4040505@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2EIUXFPBVTRXMMTJONRKO" Subject: Re: [xmpp] Proposed XMPP Charter Update X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 17:24:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2EIUXFPBVTRXMMTJONRKO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2013-02-25 18:14, Ben Campbell wrote: > If we are talking about potential _future_ OTR work, does it make sense= to go ahead with the proposed charter as is, then worry about OTR when t= here's a concrete proposal? That is, rather than holding up the adoption = of the currently proposed charter for something that might happen in the = future? +1 Would that even require require any change to the charter, or could it be covered under the existing paragraph? -- Kim "Zash" Alvefur ------enig2EIUXFPBVTRXMMTJONRKO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJRK55ZAAoJEK3tmne2etMpvucP/Rt1oYAcTpyjcS5AoX0ycBmX /g7Q0k/xBnif1s35Y22NDdeTyQMOHH5rDzwo5qsJYAlfhzJkivCZC6Wx1Qip52t8 4unzIN3UflXnpfE9Pm7cwuJCLR34XCPXWSmRX+uz0J6kH1ljWcEbLWSt55n4/DRS WFmQAiiosOienl/3MeuxcbYPZbTH/l2AtJx1OhJhD3LX/1+oCA09Z4RVjERK+Xqs 4W824auZRw/MUC8bQh7Y2IuH9RPxHB3JBqIYOK73qBiVrlc07+b94Cstw9g7hAAl O1k9NS498jX6A/kHTTtfYmut0+AlsSZzoqUdzV1sKK8tDtybI66KzDetKmaFGoui l+mJ9XvmWNM58EhNth39euRKpnlBIANUd1ZFB3LNzBAj8UV1xzGk20i0jleWwjEQ Tl9NvoxWBLYbis77qHrrdN8Dmk6536aLYHLLD7mBH/lYentSgTLXNrhoP0G3iOKk XkvF9YHSbr+ms+/o2MBTlTAb8Hv5zUHINbjUB1deJX29o5Nzol2afKEImjwQMUz8 627HxItcIlkEsx+C6ics6iLb+Ujzw2aMVeYc6TGUsenlD54iFS6YhEEcPXdJFZyw 4ylwYHSMeh08BdcK5Ikg3L05bGIZBQ3cdrWjOXeTHe4l8Kcx23VOCND2IWO59cc4 CPBG+V3LdTVCG6JZ3BAa =/eIk -----END PGP SIGNATURE----- ------enig2EIUXFPBVTRXMMTJONRKO-- From mamille2@cisco.com Mon Feb 25 10:22:43 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD2F21F8BB7 for ; Mon, 25 Feb 2013 10:22:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpLaI5VkDtle for ; Mon, 25 Feb 2013 10:22:42 -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 C43C121F8454 for ; Mon, 25 Feb 2013 10:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5202; q=dns/txt; s=iport; t=1361816559; x=1363026159; h=from:to:subject:date:message-id:references:mime-version; bh=EKWE5oO5nksMKl14/gC40JcVQeuYWQG8MZL0zYxa6UY=; b=MJ7jUui5Cfgtj+VzoC8QaO26jejkklZUtYlHY9wjxE6OQOqbBl02b6Qy vhL+jxoZoUPOE1+AFR+7prIyV1yKFLC0nxjUpP/Csx8JauRTwRyjvKp3m KWkDwdKymftK4rk/WXVbN25gqRCwIpicf9xntLuakYIz/HXZMftci5Q24 U=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAGGqK1GtJXG+/2dsb2JhbABFg3i9X4EFFnOCHwEBAQMBAQEBaxALAgEZAwECCyQCJQsUBwIIAgQTCAEFh38GBwW/T45dFgoGDQuCWWEDjyOBJocRijSFFIMHgic X-IronPort-AV: E=Sophos;i="4.84,736,1355097600"; d="p7s'?scan'208";a="180940191" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 25 Feb 2013 18:22:39 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1PIMcRm031455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Feb 2013 18:22:38 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 12:22:38 -0600 From: "Matt Miller (mamille2)" To: XMPP Working Group Thread-Topic: I-D Action: draft-miller-xmpp-e2e-05.txt Thread-Index: AQHOE4RQu19CFRQBnkWU/fevUx96dQ== Date: Mon, 25 Feb 2013 18:22:38 +0000 Message-ID: References: <20130225181649.25195.53579.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.114.169] Content-Type: multipart/signed; boundary="Apple-Mail=_219A21FC-BCAF-4B6B-AE3B-3D10B6EB08A1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [xmpp] Fwd: I-D Action: draft-miller-xmpp-e2e-05.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 18:22:43 -0000 --Apple-Mail=_219A21FC-BCAF-4B6B-AE3B-3D10B6EB08A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI ... now with a first pass at signatures. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. Begin forwarded message: > From: > Subject: I-D Action: draft-miller-xmpp-e2e-05.txt > Date: February 25, 2013 11:16:49 AM MST > To: > Reply-To: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : End-to-End Object Encryption and Signatures = for the Extensible Messaging and Presence Protocol (XMPP) > Author(s) : Matthew Miller > Filename : draft-miller-xmpp-e2e-05.txt > Pages : 37 > Date : 2013-02-25 >=20 > Abstract: > This document defines a method of encrypting and signing objects > (often referred to as stanzas) for the Extensible Messaging and > Presence Protocol (XMPP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-miller-xmpp-e2e-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-miller-xmpp-e2e-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > 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 --Apple-Mail=_219A21FC-BCAF-4B6B-AE3B-3D10B6EB08A1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDIyNTE4MjIzOFowIwYJKoZIhvcNAQkEMRYEFITZgmjGWOcmxYRJZLtO2O75ydWkMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQAugvEm3SxwHwwHYZkpUrAO17+rxbaR3GAcT+jcDDVc 3fKoe5ObyDNygu6g/X5UAkveTUOF013YA7tsSsyTHGSv8FAcq6009on54I+5kNQLs8SwfHwcQG5L g05s7PWXt4XSabVANAsvNrJQgMunqvRckoTjdSK31uMmGN7eZSrNuh0NrNoOUEmKWCVz2/IqPSTm 5F7nA/wMRsu6zxZT2KUL7C7ZJeq1+njsJ+qlST3rsg4t6Hxzbxm4OMtm+FHmawRolEno/ddyN0d4 W1qFD2qnG69qhPG6h5izont4nN3uGOR4wRAlZl2L0vf7ZXg+wR1xft/CoPhO4XzzJxvbevIRAAAA AAAA --Apple-Mail=_219A21FC-BCAF-4B6B-AE3B-3D10B6EB08A1-- From stpeter@stpeter.im Mon Feb 25 12:24:58 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD0C21E808A for ; Mon, 25 Feb 2013 12:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lG6x5gTsZagh for ; Mon, 25 Feb 2013 12:24:57 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B677821F91ED for ; Mon, 25 Feb 2013 12:24:57 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 112534004E for ; Mon, 25 Feb 2013 13:32:41 -0700 (MST) Message-ID: <512BC89C.60102@stpeter.im> Date: Mon, 25 Feb 2013 13:25:00 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: XMPP Working Group References: <20130225191215.32347.88755.idtracker@ietfa.amsl.com> In-Reply-To: <20130225191215.32347.88755.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130225191215.32347.88755.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-moffitt-xmpp-over-websocket-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:24:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As seen on the I-D announce list. :-) - -------- Original Message -------- Subject: I-D Action: draft-moffitt-xmpp-over-websocket-02.txt Date: Mon, 25 Feb 2013 11:12:15 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An XMPP Sub-protocol for WebSocket Author(s) : Lance Stout Jack Moffitt Eric Cestari Filename : draft-moffitt-xmpp-over-websocket-02.txt Pages : 7 Date : 2013-02-25 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-moffitt-xmpp-over-websocket There's also a htmlized version available at: http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-moffitt-xmpp-over-websocket-02 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.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRK8ibAAoJEOoGpJErxa2pzC4P/2UaPrCo/XFdolEZpkHUqtSl 2cqo7nqHCDKgq6il5QmDllbYXfgDw54Nw1f3dp3UHC+1Q75dajg24NXspcBYuAfM aHQlputrhUB9Wgvnw31WmE5x1etToKO0DDfdkz9ozp24N7BPNiN0CkIvukPRNoKR Wl7pbUQKqWX/yBzKrLKkeR5zh8xesZJ2A9x5Pz2joFqtyLRWgGug1a3GZ3FKW+mo UNQgsTPcQtCuwhNJUk1YEMBYQuWeEhmq5qSpozFA6OWgR6dnV4bcj3Fr6fKdOp/J O595/9ONmY9eOHRLAq98zIGPzjf2x8w9+pJivJhN8v9CvNf4gRxoowFBTwlEUA47 50Psnfb2ZN2Un6OQCpZLGfELbISdzsoZPOe7xAG02IN5PuyoOJAPt3KzYwNMZ5zI hSVD9jO9qX8SFSath3+GNEfIDC3L8jcRHNSNzyi99Xj6ujHmZ54ImtVGOkf0M41z RbuWnn4KTyn86FQEMqYVPPgLYyCtFhv5YXt98AM1TN+++D+GLBFPaOeXe5gxy6wt r6+WaPhufRWh2cBdXW0VLm//UXOma4oKEiDJv/uoYE7rPi/Z3UMY2h6Z1iiqeIMq hxSI4fX18ulA7rz12FScXxkVx/pRRZsEYtKOzy6embfktTSq/c9xwK5/v2LsYMvH ihU5Zsxz1BfOdCFjPaj+ =SUVS -----END PGP SIGNATURE----- From lance@andyet.net Mon Feb 25 11:22:36 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B47421F92D5 for ; Mon, 25 Feb 2013 11:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16M+NOClloqC for ; Mon, 25 Feb 2013 11:22:35 -0800 (PST) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id A620F21F92EB for ; Mon, 25 Feb 2013 11:22:35 -0800 (PST) Received: by mail-da0-f45.google.com with SMTP id v40so1610408dad.32 for ; Mon, 25 Feb 2013 11:22:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:subject:date:references:to:message-id :mime-version:x-mailer:x-gm-message-state; bh=/YXxHY418DpZwXchI+C/lthEhddVbPz376xCpwf0ITQ=; b=XCiRs3sF0QAeCtqxmqPi7rYEhxG7CuKkgxWufYnsVSyjTMhg4TIGmN6TnbIPIsaCV1 ghU++QtWNRwbAgGrACKxOGL4pEGMPBFO2PG4ei/F2EmnyPaYfKMnOfW48xwkBCMmvTKC B4+P/psBSOAEBMDc1WzhF+uyKA3d7JaHPqNM+o4swg/XxjueAvuY+X5lLr+QmmdAzSDK CUa8x6eoTpI/4eBjbMd+6o0I29/qFKqN/uUaPkTqwRou5l0qJyVfhbLePUW3nY0r6t0S YDRNbTHl+qHmjJMKQFMRPOGm3sTEPKXioAvOzileWXoIsuPPBLvswcv5yuqCfvc6HV+B FbEQ== X-Received: by 10.66.222.35 with SMTP id qj3mr21094170pac.69.1361820155368; Mon, 25 Feb 2013 11:22:35 -0800 (PST) Received: from [10.0.2.192] (71-84-176-17.dhcp.mdfd.or.charter.com. [71.84.176.17]) by mx.google.com with ESMTPS id gg7sm13598056pbc.45.2013.02.25.11.22.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Feb 2013 11:22:34 -0800 (PST) From: Lance Stout Content-Type: multipart/alternative; boundary="Apple-Mail=_3F803F21-736F-49A0-99D2-8010A0FEA7E3" Date: Mon, 25 Feb 2013 11:22:33 -0800 References: <20130225191215.32347.35758.idtracker@ietfa.amsl.com> To: xmpp@ietf.org Message-Id: <5A3D41BD-9A7C-49F9-BC45-9C33378A3540@andyet.net> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnnrcE+5BtrtxxlnAwUWg6lGPH0/Aw+6PodbyzwoI93uhMyGJdGDjEuWOOCG7bqup7lDxVC X-Mailman-Approved-At: Mon, 25 Feb 2013 13:58:59 -0800 Subject: [xmpp] Fwd: New Version Notification for draft-moffitt-xmpp-over-websocket-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 19:23:36 -0000 --Apple-Mail=_3F803F21-736F-49A0-99D2-8010A0FEA7E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, progress on the WebSocket XMPP sub-protocol has started up again. The submitted version was for some house cleaning issues and adding the = IANA registration request for the xmpp sub-protocol. Between now and the meeting in Orlando I'll be continuing with adding = examples and filling out the TODO items left in the draft (follow at = https://github.com/metajack/xmpp-websocket) -- Lance Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-moffitt-xmpp-over-websocket-02.txt > Date: February 25, 2013 11:12:15 AM PST > To: lance@andyet.net > Cc: jack@metajack.im, ecestari@process-one.com >=20 >=20 > A new version of I-D, draft-moffitt-xmpp-over-websocket-02.txt > has been successfully submitted by Lance Stout and posted to the > IETF repository. >=20 > Filename: draft-moffitt-xmpp-over-websocket > Revision: 02 > Title: An XMPP Sub-protocol for WebSocket > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 7 > URL: = http://www.ietf.org/internet-drafts/draft-moffitt-xmpp-over-websocket-02.t= xt > Status: = http://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket > Htmlized: = http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-moffitt-xmpp-over-websocket-02 >=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 > The IETF Secretariat >=20 --Apple-Mail=_3F803F21-736F-49A0-99D2-8010A0FEA7E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI, = progress on the WebSocket XMPP sub-protocol has started up = again.

The submitted version was for some house = cleaning issues and adding the IANA registration request for the xmpp = sub-protocol.

Between now and the meeting in = Orlando I'll be continuing with adding examples and filling out the TODO = items left in the draft (follow at https://github.com/met= ajack/xmpp-websocket)

-- = Lance


Begin forwarded message:

Subject: New Version Notification for = draft-moffitt-xmpp-over-websocket-02.txt
Date: February 25, 2013 = 11:12:15 AM PST
Cc: jack@metajack.im, ecestari@process-one.com
<= /span>


A new version of I-D, = draft-moffitt-xmpp-over-websocket-02.txt
has been successfully = submitted by Lance Stout and posted to the
IETF = repository.

Filename: = draft-moffitt-xmpp-over-websocket
Revision: = 02
Title: = = An XMPP Sub-protocol for WebSocket
Creation date: = 2013-02-25
Group: Individual Submission
Number = of pages: 7
URL: =             http://www.ietf.org/internet-drafts/draft-moffitt-xmpp-over-we= bsocket-02.txt
Status: =          http://datatracker.ietf.org/doc/draft-moffitt-xmpp-over-websocket
= Htmlized:        h= ttp://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-02
Diff= :            http://www.ietf.org/rfcdiff?url2=3Ddraft-moffitt-xmpp-over-websocke= t-02

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 = Secretariat


= --Apple-Mail=_3F803F21-736F-49A0-99D2-8010A0FEA7E3-- From zash@zash.se Mon Feb 25 16:40:29 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D8021E818F for ; Mon, 25 Feb 2013 16:40:29 -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=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpcIC0Z4Z2iK for ; Mon, 25 Feb 2013 16:40:28 -0800 (PST) Received: from sphyrna.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) by ietfa.amsl.com (Postfix) with ESMTP id 123D821E817A for ; Mon, 25 Feb 2013 16:40:28 -0800 (PST) Received: from [IPv6:2001:470:def1:0:81d7:b6e6:8481:835c] (unknown [IPv6:2001:470:def1:0:81d7:b6e6:8481:835c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: zash) by sphyrna.zash.se (Postfix) with ESMTPSA id D7CE561B59 for ; Tue, 26 Feb 2013 01:40:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=zash.se; s=b; t=1361839227; bh=eXCdGJuKQO7BFLCXHrearXddbajPrBshuHV0seeGmM8=; h=Date:From:To:Subject:References:In-Reply-To; b=CWMoMfSR76DzISVngRBfGAh2iicz1G5N3Se8epbDjHHWuqQBqO0sBQFqPaWrd4yzl eWTAadF8Bab/Xg+MWqw8+8hNouUjN/+Yiu2IU4mR1hKuRRXiqQe0Tys14A5wp0Fxrn dAb4p45PwF1VDc/WkxUs1rOkEg9fqLtnyxFNpxSnpaT3uvGt9WEytoOSWubdgCJVc/ ChkBCqx0x5g5CD1MWRuWfnK6FVtkk6lHaoDu4SYH0Y+YYDlnCFwQjVTKR/5Nog0tlJ niByNRFQ6LkKGisdwT33P9yBppHQXcvoFBc3vYAplXWH8KG1WWiEWvoVDD2/AJ6bdF Gk0Qy1XunkftQ== Message-ID: <512C0465.8060509@zash.se> Date: Tue, 26 Feb 2013 01:40:05 +0100 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: XMPP References: <20130225234639.16195.57113.idtracker@ietfa.amsl.com> In-Reply-To: <20130225234639.16195.57113.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc X-Forwarded-Message-Id: <20130225234639.16195.57113.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [xmpp] Fwd: I-D Action: draft-ietf-dane-srv-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:40:29 -0000 Neat, SRV genericness! -------- Original Message -------- Subject: I-D Action: draft-ietf-dane-srv-02.txt Date: Mon, 25 Feb 2013 15:46:39 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: dane@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF. Title : Using DNS-Based Authentication of Named Entities (DANE) TLSA records with SRV and MX records. Author(s) : Tony Finch Filename : draft-ietf-dane-srv-02.txt Pages : 12 Date : 2013-02-25 Abstract: The DANE specification [RFC6698] describes how to use TLSA resource records in the DNS to associate a server's host name with its TLS certificate. The association is secured with DNSSEC. Some application protocols can use SRV records [RFC2782] to indirectly name the server hosts for a service domain. (SMTP uses MX records for the same purpose.) This specification gives generic instructions for how these application protocols locate and use TLSA records. Separate documents give the details that are specific to particular application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dane-srv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dane-srv-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-srv-02 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 From stpeter@stpeter.im Mon Feb 25 16:52:46 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E1021E81C4 for ; Mon, 25 Feb 2013 16:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxNGB1-rbUBn for ; Mon, 25 Feb 2013 16:52:45 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C721E81BF for ; Mon, 25 Feb 2013 16:52:45 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5CCFB4004E; Mon, 25 Feb 2013 18:00:30 -0700 (MST) Message-ID: <512C0764.7040106@stpeter.im> Date: Mon, 25 Feb 2013 17:52:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Kim Alvefur References: <20130225234639.16195.57113.idtracker@ietfa.amsl.com> <512C0465.8060509@zash.se> In-Reply-To: <512C0465.8060509@zash.se> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: XMPP Subject: Re: [xmpp] Fwd: I-D Action: draft-ietf-dane-srv-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 00:52:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/13 5:40 PM, Kim Alvefur wrote: > Neat, SRV genericness! Yes, Matt Miller and I intend to align our XMPP-DNA work with the dane-srv work, but we ran out of time for the I-D cutoff. Expect some work along these lines before too long. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLAdkAAoJEOoGpJErxa2pEGEQAK8tm+dOLjRYhM7na/r1R8h4 pVwtTlC0ldgD3QnqZzcmdhnXHKx0YGC7GsGPDYlfiHje0y++yiitt8DxtobXJFsj BR7h9Xj/WhRMQ323aSXGZI/KgGeLWd7APrHY+07ZFovHMaWGMlMDJ7LYqGl3lDnZ J5/d01xCv0puXkUHbqxBnLJ8ouhek5OhocO1B4bwuH5Ebp4vWluROzQk5Y2q4CIX Vw3IpJkN0SPu1L1p6sfpigXug+tTevJDL8gwX8fJNqOpwwcwLI8lg+XZFXTgLPPa t3/DZZfwQsiyjuj7G5pLuTut0NfAhA6Sobsu1AVIJCMmG1A9zDZGtXWCVIh6t1ah ZazGOF71qqlPgxE0XCcsXrmG31f8rnoPgFboDUWomj/4Ol+PLYEDc/oY98ebZjoa 9dLWfA3uwHPJCFUOZN5AZ0NScM9xClMmoEMgnoHiXBYrhIE58kcrCxbTA4DwwqaL 8RZX/56fAuujre0KESehYhGC1jgqIiLcyNMIFx7lhEwvjh7aWCywjm/s9kpufVkC 8WLrwVHVnOtHqdywzfNBS1cuW2iOarGaAlg7v/IZBzfBxUj/OQ/Ce4Ck3IAL7x8R N9Fp9xZPaaqKEcqou0XguVkUOddIDoObTskb+gjrnQjvIS17zWN8WPYE3s0fqZTE 6ZEtQ6Sv4KsN+zDBZTFR =Fz53 -----END PGP SIGNATURE----- From jon.kristensen@nejla.com Tue Feb 26 06:35:37 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2A921F8AB8 for ; Tue, 26 Feb 2013 06:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_LH_LD=1.215, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P6UwKO9ldER for ; Tue, 26 Feb 2013 06:35:36 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3E23F21F8AB2 for ; Tue, 26 Feb 2013 06:35:35 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id fs13so3866705lab.8 for ; Tue, 26 Feb 2013 06:35:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=YJ/KWyfKi+wCLgg3/ULLdVMwgQUCqW+aKFQ3sSH8XFo=; b=LgR0WV+e8PpXRKteNtoBISyYCfxjSnyKgSQ6eKoOAy6B1Jj/UqF+6qOSTXejuSyqMO Q+CgTSyqfgWZZ/CLBIPcP4YUUvJ10efFCR87FkSCGOyoMibjEEtaxnlsFmrC6KU7ebh0 Hu9nqF0yB4xHv/EPRwoQVD4cHqiWwESo/gA4bk9wWiAhxMLIil1579VC8wZZPdgaA4Ql qJL95HjQ5ZpUoT/7z2FzT2Y2zIZ+BJr5FL4L842y7HAeD4F4tG5ezMfuEvD5XGIPlWcP 6Jxxz2wvlVYNOSaZcXvIOZiJX1/W0Uc5HVmL7vgF15qALNEsVD7lImuvloVzFwhZ9AWl jP/Q== X-Received: by 10.112.43.137 with SMTP id w9mr656027lbl.77.1361889334869; Tue, 26 Feb 2013 06:35:34 -0800 (PST) Received: from localhost.localdomain ([94.234.185.66]) by mx.google.com with ESMTPS id i3sm586781lbn.0.2013.02.26.06.35.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 26 Feb 2013 06:35:34 -0800 (PST) Message-ID: <512CC832.1060702@jonkri.com> Date: Tue, 26 Feb 2013 15:35:30 +0100 From: Jon Kristensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: xmpp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmeC2RB4tqQEg8xHWdjZQpZnpxAObZH+fwaBzT9cTXx3bI2uC6ls+kZzilVkXnofV4ALdbJ Subject: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 14:35:37 -0000 Hello, everyone! I would like to briefly introduce myself to the members of this mailing list, and to inform you of my interest of contributing to the standardization of the use of the Off-the-Record protocol with XMPP. My relevant past experience includes being one of the co-authors of Pontarius XMPP[1], a client XMPP library for Haskell, as well as the prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript application currently called Yabasta[2]. In the process of prototyping Yabasta, I have "designed" an OTR-like protocol[3] that, while based on OTR, differs from OTR in a number of ways. Most importantly, the OTR messages (be it the authenticated key exchange, the protected payloads, or the Socialist Millionaire's Protocol) are expressed with XML instead of with a binary encoding. Also, the prime numbers used are negotiatable, and any XML payloads can be protected (not just message bodies). (I never meant to go "Not invented here" in regards to OTR: my intention was simply to make the protocol easier to understand and to implement, more flexible, and better suitable for XMPP. However, I have since then that straying so far from OTR might not have been the best idea.) Please don't hesitate to contact me if you are working on anything related to the above, or if you have any other questions or concerns. Warm regards, Jon Kristensen [1]: http://hackage.haskell.org/package/pontarius-xmpp/ [2]: https://yabasta.com/ [3]: https://github.com/jonkri/yabasta-protocol/ From rlb@ipv.sx Wed Feb 27 10:30:31 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A29521F890E for ; Wed, 27 Feb 2013 10:30:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.926 X-Spam-Level: X-Spam-Status: No, score=-1.926 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqxwaXoF3Pno for ; Wed, 27 Feb 2013 10:30:25 -0800 (PST) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id DD6E421F8860 for ; Wed, 27 Feb 2013 10:30:24 -0800 (PST) Received: by mail-oa0-f49.google.com with SMTP id j6so1820476oag.22 for ; Wed, 27 Feb 2013 10:30:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=9jCwUuWuC0I1VERuh0reQsP8RGj1q/+cOqNDZpiWgeA=; b=nm0/Pdngyu2rCtmCK8l7/tXHzwTL4j/fKPrVR2UP1esTtlxksW5/cv3RTWFzb846Wg MznC54HyuwjsscdaUjFroBjZrfHdKiJiWi30pQ1iqKbu0/uvXeaavvTdVZg6KE8PHOra iG2lmlwHQOaaIhUADMpm7O9UFUUjl7cAgf0nGY4PAad+3MTOsuotxSBcDzABry/TOT8T 1pIvBYxvRB8pc2KQgkOQS8y4DNy4mmUc28dGD4uzkg4EJXf6XZwbWX7L2Ys7qCNiTrhR lPIYYb4TgOmjEioXKtfWpMREs5y0x/FuCEnITbSfAkRNjvmCzWxKmh0nCfO7SYKcTf23 dN4Q== MIME-Version: 1.0 X-Received: by 10.182.221.105 with SMTP id qd9mr3086441obc.97.1361989818157; Wed, 27 Feb 2013 10:30:18 -0800 (PST) Received: by 10.60.60.98 with HTTP; Wed, 27 Feb 2013 10:30:18 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <512CC832.1060702@jonkri.com> References: <512CC832.1060702@jonkri.com> Date: Wed, 27 Feb 2013 13:30:18 -0500 Message-ID: From: Richard Barnes To: Jon Kristensen Content-Type: multipart/alternative; boundary=f46d0447f2f84ca3d104d6b8f77d X-Gm-Message-State: ALoCoQkFh8l3Xmeyu+Jw2RjMzQZS+74HmxbyinvPM5Mn+0g8JQt6LvxkjNnw9+7LKdvmV8SHs+eb Cc: xmpp@ietf.org Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:30:31 -0000 --f46d0447f2f84ca3d104d6b8f77d Content-Type: text/plain; charset=ISO-8859-1 Any comments on draft-miller-xmpp-e2e? On Tue, Feb 26, 2013 at 9:35 AM, Jon Kristensen wrote: > Hello, everyone! > > I would like to briefly introduce myself to the members of this mailing > list, and to inform you of my interest of contributing to the > standardization of the use of the Off-the-Record protocol with XMPP. > > My relevant past experience includes being one of the co-authors of > Pontarius XMPP[1], a client XMPP library for Haskell, as well as the > prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript > application currently called Yabasta[2]. > > In the process of prototyping Yabasta, I have "designed" an OTR-like > protocol[3] that, while based on OTR, differs from OTR in a number of ways. > Most importantly, the OTR messages (be it the authenticated key exchange, > the protected payloads, or the Socialist Millionaire's Protocol) are > expressed with XML instead of with a binary encoding. Also, the prime > numbers used are negotiatable, and any XML payloads can be protected (not > just message bodies). (I never meant to go "Not invented here" in regards > to OTR: my intention was simply to make the protocol easier to understand > and to implement, more flexible, and better suitable for XMPP. However, I > have since then that straying so far from OTR might not have been the best > idea.) > > Please don't hesitate to contact me if you are working on anything related > to the above, or if you have any other questions or concerns. > > Warm regards, > Jon Kristensen > > [1]: http://hackage.haskell.org/**package/pontarius-xmpp/ > [2]: https://yabasta.com/ > [3]: https://github.com/jonkri/**yabasta-protocol/ > ______________________________**_________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/**listinfo/xmpp > --f46d0447f2f84ca3d104d6b8f77d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Any comments on draft-miller-xmpp-e2e?


On Tue, Feb 26,= 2013 at 9:35 AM, Jon Kristensen <info@jonkri.com> wrote:
Hello, everyone!

I would like to briefly introduce myself to the members of this mailing lis= t, and to inform you of my interest of contributing to the standardization = of the use of the Off-the-Record protocol with XMPP.

My relevant past experience includes being one of the co-authors of Pontari= us XMPP[1], a client XMPP library for Haskell, as well as the prototyping o= f a OTR-based (but (so far) OTR-incompatible) JavaScript application curren= tly called Yabasta[2].

In the process of prototyping Yabasta, I have "designed" an OTR-l= ike protocol[3] that, while based on OTR, differs from OTR in a number of w= ays. Most importantly, the OTR messages (be it the authenticated key exchan= ge, the protected payloads, or the Socialist Millionaire's Protocol) ar= e expressed with XML instead of with a binary encoding. Also, the prime num= bers used are negotiatable, and any XML payloads can be protected (not just= message bodies). (I never meant to go "Not invented here" in reg= ards to OTR: my intention was simply to make the protocol easier to underst= and and to implement, more flexible, and better suitable for XMPP. However,= I have since then that straying so far from OTR might not have been the be= st idea.)

Please don't hesitate to contact me if you are working on anything rela= ted to the above, or if you have any other questions or concerns.

Warm regards,
Jon Kristensen

[1]: http://hackage.haskell.org/package/pontarius-xmpp/ [2]: https://yabasta.com= /
[3]: https://github.com/jonkri/yabasta-protocol/
_______________________________________________
xmpp mailing list
xmpp@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/xmpp

--f46d0447f2f84ca3d104d6b8f77d-- From ben@nostrum.com Wed Feb 27 10:31:01 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD3A21F890E for ; Wed, 27 Feb 2013 10:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJKoCNCPXG1L for ; Wed, 27 Feb 2013 10:31:00 -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 4291221F8860 for ; Wed, 27 Feb 2013 10:31:00 -0800 (PST) Received: from [10.119.79.98] (v398.dal.ubiquity.io [174.34.133.219] (may be forged)) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r1RIUtrJ070170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Feb 2013 12:30:56 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Feb 2013 12:30:46 -0600 Message-Id: To: XMPP Working Group Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Received-SPF: pass (shaman.nostrum.com: 174.34.133.219 is authenticated by a trusted mechanism) Subject: [xmpp] IETF 86 Draft Agenda X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:31:01 -0000 Hi Everyone, We have a 1 hour session for XMPP scheduled at IETF 86 (Orlando). The = draft agenda is available at the following link: http://www.ietf.org/proceedings/86/agenda/agenda-86-xmpp Please send any agenda concerns or other feedback to the list as soon as = possible. Thanks! Ben.= From stpeter@stpeter.im Wed Feb 27 10:34:19 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DD221F8947 for ; Wed, 27 Feb 2013 10:34:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wP5xRgNbLHGg for ; Wed, 27 Feb 2013 10:34:18 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EA5B321F8942 for ; Wed, 27 Feb 2013 10:34:17 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9EE494060C; Wed, 27 Feb 2013 11:42:08 -0700 (MST) Message-ID: <512E51A5.3020400@stpeter.im> Date: Wed, 27 Feb 2013 11:34:13 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jon Kristensen References: <512CC832.1060702@jonkri.com> In-Reply-To: <512CC832.1060702@jonkri.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: xmpp@ietf.org Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 18:34:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/26/13 7:35 AM, Jon Kristensen wrote: > Hello, everyone! > > I would like to briefly introduce myself to the members of this > mailing list, and to inform you of my interest of contributing to > the standardization of the use of the Off-the-Record protocol with > XMPP. Paul Wouters and I plan to work together IRL at the IETF meeting in Orlando on an informational specification for OTRv3 (the current version). Any future version that is more XMPP-friendly would happen in parallel with (or after) that documentation effort. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLlGlAAoJEOoGpJErxa2pN88P/0x/cSJ9f+LOPX9Sbjsf1ANy qEoU0NB8+P3ZMBWB0E2JP+nxBLThVDhbOToUz9mgJsoTwI953lXrOukuJRmEGf1D o1sIxDJC6pcGtpMDkfJRTkCQveB6t1PLZxittr/uERliATPCXU/bOxsBJRCgguc9 P8k3Hgo01uCw/+PQfxXybJaWA6j7uRJNfAUPv5jFrYWUCdYNipMQ7J1PshCpZfE0 i5TJFUN/4Xyi8Ss8zRzyAHqxBE4nVSxLM10MOOSAlJd98dDdDGHxHInYB+frZFZs IoTs36v7dgrY3ugDf2Y/Jb8I7e+nct/Wb2dxAVjxaniOUa8siTF1V0uHNzR6IiWd 2bB0P3LZYj4sV/T8bXIMFY/h/4WLbl2O/+JeoCtua5EZoVbSrr+KZcdjsCQ41E4y R28gtGmEsk8Z8wg3T+DAalvoc+67Bh/F2UgzC+lSwtv4KcNSNVbljYYzuCy0j4A0 j+5aj3m9uJqhdfhvlx6fIJhbZ/Q6e4idzDZpJO/a5QUAjOwyYilQUpdHpgOZrU7V oaAQqeqfZkij/1In2Q/9bL+/uJx1ayf0CdqpMWoOKk8Z/spy3dg8ZEN10WgvkZ0o +NhurvKzquWXUSa4tWtCcE8YP0REekW/9U+OgNrmr1tjulGZROHMAnsfnY/cxM5Y v59tNj/ilF4R/5eJeHZ8 =WRMc -----END PGP SIGNATURE----- From mamille2@cisco.com Wed Feb 27 11:11:25 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242DD21F8930 for ; Wed, 27 Feb 2013 11:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkXmDICavcMl for ; Wed, 27 Feb 2013 11:11:23 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF1921F8611 for ; Wed, 27 Feb 2013 11:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7999; q=dns/txt; s=iport; t=1361992283; x=1363201883; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4ckXwPu8euyhjIIBYR9ZObbE0JUT4GAS9o4c57QaQ2w=; b=X8/CEoAMKQIn7/m4QEJsnQ/2UDp6mnpwTiD1RvSIP9+KBaL29xVUWI6D KUcemicchjy6w6zeErKKSWSqFMV5S27/IyWAPA8corQiYVxU1WqgltG19 ePJHHdusXSnj2oN1l25+lAY1aNA6suO/jGay2V+X0MioB1/pyRRot4bQM E=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAB9ZLlGtJXG8/2dsb2JhbABFwiZ9FnOCHwEBAQMBAQEBaAMLBQsCAQgOFCQCJQslAgQOBQgGh38GDMINjVOBEDECBYJfYQOPJoEmhxOPTIMIgXI1 X-IronPort-AV: E=Sophos;i="4.84,750,1355097600"; d="p7s'?scan'208";a="178892622" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 27 Feb 2013 19:11:23 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r1RJBMNS028765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Feb 2013 19:11:22 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 13:11:22 -0600 From: "Matt Miller (mamille2)" To: Jon Kristensen Thread-Topic: [xmpp] Self Introduction Thread-Index: AQHOFC6MLgMtxyNBOkuDluRd7596QJiOeK0A Date: Wed, 27 Feb 2013 19:11:22 +0000 Message-ID: References: <512CC832.1060702@jonkri.com> In-Reply-To: <512CC832.1060702@jonkri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.86] Content-Type: multipart/signed; boundary="Apple-Mail=_C8E3701B-C37C-4514-B1CD-42402B2720F2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 19:11:25 -0000 --Apple-Mail=_C8E3701B-C37C-4514-B1CD-42402B2720F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [ "switching" venue for wider security review ] [ context for XMPP WG: = http://mail.jabber.org/pipermail/standards/2013-February/027167.html ] Hello Jon, I find this work interesting, but I also have some concerns here. I = don't expect definitive answers to all of them, but think they're worth = discussion to help the working group choose a path forward. I think there is an additional application requirement concern regarding = multiple resources. The XSF has technologies in development to = multiplex chat conversations, namely [CARBONS]. I'm not sure that = E2E-REQ calls it out, but it will be an important consideration for the = very near term. I'm curious how yabasta can accommodate things like = carbons without in a user-transparent manner. from your response on standards@xmpp.org, an effective fork of OTR = doesn't exactly meet the (existing) XMPP WG charter requirement. I'm = not saying that's necessarily bad, but it is something to consider as we = move forward. Not that I have much moral authority here with [XMPP-E2E] = (-; However, my draft is based on a technology with a lot of momentum = behind it, so it is likely to be "widely deployed and implemented" by = the time we get completely done. One of the big detractions from RFC3923 was the multiple paths followed. = It looks like this duplicates that, and not in a necessarily better = route. Various other attempts at this space have tried to deal with a = single path (whole stanzas) to eliminate the complexity. It is nice = there is an existing implementation, but is there enough value in = multiple paths to continue down that road? I have some concerns that there are a lot of cryptographic primitives = here, and it doesn't look very negotiable for those primitives. I'm = hesitant to have this much specialized work happen in a group that does = not have the expertise. Would it be possible (and worthwhile) to = separate this more, and possibly push the primitives through the = security area? Finally, given your original post, seeing the word "forgeability" as a = feature makes me personally very nervous. I don't claim to be an = expert, or much more than a erstwhile enthusiast, but I have a hard time = seeing this being a good idea in general. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [CARBONS] XEP-0280: Message Carbons < = http://xmpp.org/extensions/xep-0280.html > [XMPP-E2E] End-to-End Object Encryption and Signatures for the = Extensible Messaging and Presence Protocol (XMPP) < = http://tools.ietf.org/html/draft-miller-xmpp-e2e-05 > On Feb 26, 2013, at 7:35 AM, Jon Kristensen wrote: > Hello, everyone! >=20 > I would like to briefly introduce myself to the members of this = mailing list, and to inform you of my interest of contributing to the = standardization of the use of the Off-the-Record protocol with XMPP. >=20 > My relevant past experience includes being one of the co-authors of = Pontarius XMPP[1], a client XMPP library for Haskell, as well as the = prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript = application currently called Yabasta[2]. >=20 > In the process of prototyping Yabasta, I have "designed" an OTR-like = protocol[3] that, while based on OTR, differs from OTR in a number of = ways. Most importantly, the OTR messages (be it the authenticated key = exchange, the protected payloads, or the Socialist Millionaire's = Protocol) are expressed with XML instead of with a binary encoding. = Also, the prime numbers used are negotiatable, and any XML payloads can = be protected (not just message bodies). (I never meant to go "Not = invented here" in regards to OTR: my intention was simply to make the = protocol easier to understand and to implement, more flexible, and = better suitable for XMPP. However, I have since then that straying so = far from OTR might not have been the best idea.) >=20 > Please don't hesitate to contact me if you are working on anything = related to the above, or if you have any other questions or concerns. >=20 > Warm regards, > Jon Kristensen >=20 > [1]: http://hackage.haskell.org/package/pontarius-xmpp/ > [2]: https://yabasta.com/ > [3]: https://github.com/jonkri/yabasta-protocol/ > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp --Apple-Mail=_C8E3701B-C37C-4514-B1CD-42402B2720F2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDIyNzE5MTEyMlowIwYJKoZIhvcNAQkEMRYEFJC47irgoS8fcc5PXGdtQXFgEEHHMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBGORR5U5ymhNugAbGvjBMGjlcbkdyIuFTA/PSSsPQJ iLWRThZ94aBi6sukL1QEn/kv5R0rvePhfkUM/hb+ygn4K6EteY/pAsT5iAjYqO0g+9EGJjy4cGPH 6AsYwEjInznrOI6TjG5WUFsVYcDj80fS7FY7LtcKeYfNOqw7x/+R4eHdHx4XRYT7vIioIjq90qLf 5ndU2FMoM7E64vuFfa2kqqlTDfdQvTJS0jX8zDJ5wARU4mUrcVldfP96SMlKJNblNwkc83X3JN0B oGlsX2jUBHjRjEJivMJlRyTtNCosgUdVOAdioE/BE/GWQthUtn557PFSbUrTADLgcPY8KlZQAAAA AAAA --Apple-Mail=_C8E3701B-C37C-4514-B1CD-42402B2720F2-- From jon.kristensen@nejla.com Wed Feb 27 15:20:08 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2870321F8845 for ; Wed, 27 Feb 2013 15:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_LH_LD=1.215, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPUZItXB4uKp for ; Wed, 27 Feb 2013 15:20:06 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id C4D9A21F874E for ; Wed, 27 Feb 2013 15:20:05 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id fe20so1172022lab.1 for ; Wed, 27 Feb 2013 15:20:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=l6R1tDti9LQeJ+qHniOhpOAjGrGwiSnSvk82hg/i+y0=; b=fPZk0u2/xv+imNa8mWy5Fd2ngum2HgLZJXE5K/V5OJ5GJgxXWnq2pkjSF2ggQ9gPO2 0mvpzLBMOR0WKscoc6rCbvBjuL7XJRLP0GQm8LJWYEJxBF1q3t6JX0RHzvOWtzR3XIDa 2K+DOazI5xlRhFtMUZ3Jp+GATtOA/ifmKYDjQCh/Y63pUdZsGzwubURbnZJ5AuFNdXVB bsLR+4JuXV+5WH4+ptPKPZx11s5HXjmWcwlIVK5QonwOSI/rdXA9P3usKUY+13cvlYBb 6+2IvbGvEdAVywjLrJMqyG6JUEVDFc+14ONS3/7ABxL5gvBF2Aouem23/iAhY2RldiS4 w1sA== X-Received: by 10.112.26.33 with SMTP id i1mr2797524lbg.96.1362007204331; Wed, 27 Feb 2013 15:20:04 -0800 (PST) Received: from localhost.localdomain ([94.234.185.66]) by mx.google.com with ESMTPS id k15sm2274218lbd.6.2013.02.27.15.20.03 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Feb 2013 15:20:03 -0800 (PST) Message-ID: <512E94A2.8000900@jonkri.com> Date: Thu, 28 Feb 2013 00:20:02 +0100 From: Jon Kristensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Richard Barnes References: <512CC832.1060702@jonkri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl5sXrv6yt0bBXjvrh4IjygOnEhJ01sjqhYmGIm2lW6TJsc5/38BqRd5XjGLMJxCC6Ruyzp Cc: xmpp@ietf.org Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 23:23:30 -0000 Hi Richard, and thank you for your question! I may be wrong - I only skimmed through it, but the way I understand that specification, it's using public-key cryptography is used to encrypt and decrypt the messages. If this is the case, it would mean that the protocol does not offer repudiability; if Alice sends a message to Bob, Bob can prove that Alice (or, at least, someone with access to Alice's private key) has authored a message. In most off-the-record conversations, this would not be desirable. What OTR does is negotiates a shared secret (symmetric key), which is then used to encrypt and decrypt the messages. What this means is that Bob, having access to the encryption key, could have just as easily produced the message. Hence, Alice can deny that she authored the message in the first place. Furthermore, the negotiation of a shared secret is continuously repeated in OTR in order to allow for forward secrecy. This prevents previous session keys from being compromised if the (long-term) private key happens to get compromised. I think this is another important security feature to keep in mind. Best, Jon Kristensen On 02/27/2013 07:30 PM, Richard Barnes wrote: > Any comments on draft-miller-xmpp-e2e? > From jon.kristensen@nejla.com Wed Feb 27 15:33:13 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19A121F8461 for ; Wed, 27 Feb 2013 15:33:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_LH_LD=1.215, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xl593cnWEph for ; Wed, 27 Feb 2013 15:33:13 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 382D421F841D for ; Wed, 27 Feb 2013 15:33:12 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so1188367lab.0 for ; Wed, 27 Feb 2013 15:33:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=vCsg8/E8KAtAf0kPtFuhXeeeg6wLiEpiz/wOdNh1Jbg=; b=hXbNwetODjcM/sgWAmwxcP05aoNBw6qG4708BiCtwzWa0QAwn4NmXpOFVje2Ug4mRV xatjkLIdYCL9+LeWRpc8C9V6fWZoI/W/VZmvQc1D66J6Wqo95hbHyWcWp723h350H350 7hF+D4eI8vJb7fXIMiAb78XipcG+4pFaYzr0e9LSUColiMb0LCQBWyCm4DdGsjE2osGW +IoTW6ANQ99ZNwt1k2HL2cjShCuuU/GfqeqaGnOZGk2nRKQoJgjZg728K2Y/kp41wdvo mJUFAmMkvr4CSbSn0VIySvOfMCe7Q+u+Cu5ia39y2m4iWkr9boKj/7M/qsUXPRu93qx8 S+lg== X-Received: by 10.112.37.194 with SMTP id a2mr2813394lbk.40.1362007991749; Wed, 27 Feb 2013 15:33:11 -0800 (PST) Received: from localhost.localdomain ([94.234.185.66]) by mx.google.com with ESMTPS id z1sm2282251lbk.2.2013.02.27.15.33.10 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Feb 2013 15:33:11 -0800 (PST) Message-ID: <512E97B5.1030600@jonkri.com> Date: Thu, 28 Feb 2013 00:33:09 +0100 From: Jon Kristensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: Richard Barnes References: <512CC832.1060702@jonkri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQn1VztGF2dc79JZa+i+XI4OfeiN6dU6/7mfmureRL9JGgcXdC5ju29ZtGWAeZshet9PnaIA Cc: xmpp@ietf.org Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 23:33:14 -0000 Also, speaking about repudiability, I forgot to add that OTR also uses a malleable cryptographic algorithm (AES in CTR mode), so that the recipient has the means to trivially alter the ciphertext transcript and encryption key and have the altered transcript appear valid. Jon On 02/27/2013 07:30 PM, Richard Barnes wrote: > Any comments on draft-miller-xmpp-e2e? > From jon.kristensen@nejla.com Wed Feb 27 17:35:09 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A48F21F8814 for ; Wed, 27 Feb 2013 17:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.716 X-Spam-Level: X-Spam-Status: No, score=-1.716 tagged_above=-999 required=5 tests=[AWL=1.883, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVaYCUlUMXqs for ; Wed, 27 Feb 2013 17:35:07 -0800 (PST) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4365D21F90BD for ; Wed, 27 Feb 2013 16:52:00 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id gm6so966928lbb.12 for ; Wed, 27 Feb 2013 16:51:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=pF514UD9beznRCphtNJucIG+GZ3abbSvZjQP5XERv/g=; b=KK9dvH61DQEyo5q527+eEKrCW8Fkm6IlQXzknHZg/262+O/mJMOju80NFoBU9OHa5U SRODiDAS1pOKb0WC1/kd/h+HdWuS5TzvkLEu/mo6Stfa5uZWSOoMavPx3rZZvx7vMDXH PVdF64o9lT+vC170I2C7RzdKjatCXsnzzyCgUntbcSECYBhTbbtgRbP20lRmnqj061OR TmrMx8T/zFP5LYIfEqup1ZGwsyE3IvWxjuiHG0+AtpJt5IxIEK7zlYmGy6vkmO2Z2MEo rQnhBlV9/CboxRrOsCEdaLJs2lcb1wiIjZF7w9eyIpIl/vML8vkh/CFp78KuBKbkHSJK rheg== X-Received: by 10.152.144.138 with SMTP id sm10mr3725465lab.53.1362012714437; Wed, 27 Feb 2013 16:51:54 -0800 (PST) Received: from localhost.localdomain ([94.234.185.66]) by mx.google.com with ESMTPS id t17sm3665713lam.9.2013.02.27.16.51.51 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 27 Feb 2013 16:51:53 -0800 (PST) Message-ID: <512EAA27.5000702@jonkri.com> Date: Thu, 28 Feb 2013 01:51:51 +0100 From: Jon Kristensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <512CC832.1060702@jonkri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkS+0q0stPPh4TYBUGHN0e+n8AoJxPfJw+mt2hxfEawjhCFGP9AY8fZPTGAKnqjSHmm8rJH Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 01:35:10 -0000 Hi Matt! I just realized that there is another thing about myself that I should probably bring up. My overall vision is to generalize on the OTR protocol and build systems that exposes as little information as possible to intermediate entities, including the XMPP server. In fact, I'm opposed to the concepts of cloud computing and software as a service as a whole. I'm aiming to build client solutions that are independently capable and privacy-aware. In effect, I consider the XMPP server primarily a proxy, authenticator, and stanza router. This renders quite a few XMPP extensions incompatible with what I'm trying to do. With this idea in mind, I will value properties (like repudiability and forward secrecy) that may not be valued by other developers. We may very well find that the properties that makes an end-to-end security protocol perfect for me, will make it overly complex for others. On the other hand, we may also find that the features that I value could be interesting for other implementations as well. Either way, I look forward to the discussions, and hope that there is room for my vision within the XMPP community. Anyway... In the case of OTR/Yabasta, the secure channels are negotiated between only two resources (and, what's worse, the symmetric key is continously changing in order to allow for forward secrecy), so no other client would be able to decrypt the forwarded message. Thus, [CARBONS] would seem to be incompatible with the current version of OTR/Yabasta. I'm currently not sure of whether or not it would be possible to extend OTR/Yabasta with transparent support for multiple resources. I will take a look at that. The authenticated key exchange of OTR "mathematically" requires four messages (six if we want confirmation by empty IQ result stanzas). This is unfortunate, but seems necessary for the Diffie-Hellman key exchange (allowing for forward secrecy) as well as the hiding of the long-term public keys from a passive attacker. I'm looking into ways of making this more effective. There's not that much difference between OTR and Yabasta from a cryptography point of view, so it should not be difficult to review its security. You also mentioned forgeability. I'm currently investigating what the benefits are of this feature, and I will present my findings when I'm done. Thanks for your reply! Best, Jon Kristensen On 02/27/2013 08:11 PM, Matt Miller (mamille2) wrote: > [ "switching" venue for wider security review ] > [ context for XMPP WG: http://mail.jabber.org/pipermail/standards/2013-February/027167.html ] > > Hello Jon, > > I find this work interesting, but I also have some concerns here. I don't expect definitive answers to all of them, but think they're worth discussion to help the working group choose a path forward. > > I think there is an additional application requirement concern regarding multiple resources. The XSF has technologies in development to multiplex chat conversations, namely [CARBONS]. I'm not sure that E2E-REQ calls it out, but it will be an important consideration for the very near term. I'm curious how yabasta can accommodate things like carbons without in a user-transparent manner. > > from your response on standards@xmpp.org, an effective fork of OTR doesn't exactly meet the (existing) XMPP WG charter requirement. I'm not saying that's necessarily bad, but it is something to consider as we move forward. Not that I have much moral authority here with [XMPP-E2E] (-; However, my draft is based on a technology with a lot of momentum behind it, so it is likely to be "widely deployed and implemented" by the time we get completely done. > > One of the big detractions from RFC3923 was the multiple paths followed. It looks like this duplicates that, and not in a necessarily better route. Various other attempts at this space have tried to deal with a single path (whole stanzas) to eliminate the complexity. It is nice there is an existing implementation, but is there enough value in multiple paths to continue down that road? > > I have some concerns that there are a lot of cryptographic primitives here, and it doesn't look very negotiable for those primitives. I'm hesitant to have this much specialized work happen in a group that does not have the expertise. Would it be possible (and worthwhile) to separate this more, and possibly push the primitives through the security area? > > Finally, given your original post, seeing the word "forgeability" as a feature makes me personally very nervous. I don't claim to be an expert, or much more than a erstwhile enthusiast, but I have a hard time seeing this being a good idea in general. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > [CARBONS] XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html > > [XMPP-E2E] End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) < http://tools.ietf.org/html/draft-miller-xmpp-e2e-05 > > > On Feb 26, 2013, at 7:35 AM, Jon Kristensen wrote: > >> Hello, everyone! >> >> I would like to briefly introduce myself to the members of this mailing list, and to inform you of my interest of contributing to the standardization of the use of the Off-the-Record protocol with XMPP. >> >> My relevant past experience includes being one of the co-authors of Pontarius XMPP[1], a client XMPP library for Haskell, as well as the prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript application currently called Yabasta[2]. >> >> In the process of prototyping Yabasta, I have "designed" an OTR-like protocol[3] that, while based on OTR, differs from OTR in a number of ways. Most importantly, the OTR messages (be it the authenticated key exchange, the protected payloads, or the Socialist Millionaire's Protocol) are expressed with XML instead of with a binary encoding. Also, the prime numbers used are negotiatable, and any XML payloads can be protected (not just message bodies). (I never meant to go "Not invented here" in regards to OTR: my intention was simply to make the protocol easier to understand and to implement, more flexible, and better suitable for XMPP. However, I have since then that straying so far from OTR might not have been the best idea.) >> >> Please don't hesitate to contact me if you are working on anything related to the above, or if you have any other questions or concerns. >> >> Warm regards, >> Jon Kristensen >> >> [1]: http://hackage.haskell.org/package/pontarius-xmpp/ >> [2]: https://yabasta.com/ >> [3]: https://github.com/jonkri/yabasta-protocol/ >> _______________________________________________ >> xmpp mailing list >> xmpp@ietf.org >> https://www.ietf.org/mailman/listinfo/xmpp From mamille2@cisco.com Wed Feb 27 18:34:18 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F74621F8960 for ; Wed, 27 Feb 2013 18:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsMOalKE4Gr9 for ; Wed, 27 Feb 2013 18:34:17 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CB11A21F8930 for ; Wed, 27 Feb 2013 18:34:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5273; q=dns/txt; s=iport; t=1362018856; x=1363228456; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=INZDxILxlNFgtoYAC66LiquSOVRY2+m90SAZUpiQA4U=; b=LCPz68TXbMQMcSbwFJMYGfRUZMvcqo1McgSSw2t9JzrVyMH3GfmVTyvs fEe06XI0qPbls6eUnDkLd4JYWfdfKQmQDwHhZTgyNepaFZH6mfM9b9/va OQxz9YavuUP9aZaYpdoqwgZFY2FAHB775+il6qJk1QyV92PDNnhMXU5WR w=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAMTALlGtJXG9/2dsb2JhbABFwih9FnOCHwEBAQMBeQULAgEIDhQkAjAlAgQOBQgGh38GwW6OYzEHgl9hA48mgSaCNJQrgwiCJw X-IronPort-AV: E=Sophos;i="4.84,752,1355097600"; d="p7s'?scan'208";a="182055781" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 28 Feb 2013 02:34:16 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1S2YGTL023217 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Feb 2013 02:34:16 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Wed, 27 Feb 2013 20:34:16 -0600 From: "Matt Miller (mamille2)" To: Jon Kristensen Thread-Topic: [xmpp] Self Introduction Thread-Index: AQHOFC6MLgMtxyNBOkuDluRd7596QJiObTQAgABQ8wCAADZDAA== Date: Thu, 28 Feb 2013 02:34:14 +0000 Message-ID: References: <512CC832.1060702@jonkri.com> <512E94A2.8000900@jonkri.com> In-Reply-To: <512E94A2.8000900@jonkri.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.145.171] Content-Type: multipart/signed; boundary="Apple-Mail=_D04F9C96-B142-472B-BA0A-0AB4C3564467"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 02:34:18 -0000 --Apple-Mail=_D04F9C96-B142-472B-BA0A-0AB4C3564467 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 27, 2013, at 4:20 PM, Jon Kristensen wrote: > Hi Richard, and thank you for your question! >=20 > I may be wrong - I only skimmed through it, but the way I understand = that specification, it's using public-key cryptography is used to = encrypt and decrypt the messages. If this is the case, it would mean = that the protocol does not offer repudiability; if Alice sends a message = to Bob, Bob can prove that Alice (or, at least, someone with access to = Alice's private key) has authored a message. In most off-the-record = conversations, this would not be desirable. What OTR does is negotiates = a shared secret (symmetric key), which is then used to encrypt and = decrypt the messages. What this means is that Bob, having access to the = encryption key, could have just as easily produced the message. Hence, = Alice can deny that she authored the message in the first place. >=20 Well, strictly speaking, the messages are protected with a symmetric = key. That symmetric key, which is exchanged separately from the = message(s), is currently protected by a public key. I suppose we could = work out a key request model that utilized a different key agreement if = that is important enough. > Furthermore, the negotiation of a shared secret is continuously = repeated in OTR in order to allow for forward secrecy. This prevents = previous session keys from being compromised if the (long-term) private = key happens to get compromised. I think this is another important = security feature to keep in mind. >=20 The session key could be rotated with every message if implementations = desire it. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_D04F9C96-B142-472B-BA0A-0AB4C3564467 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDIyODAyMzQxNVowIwYJKoZIhvcNAQkEMRYEFBZYKUAnlYg7el9gaXcqIXUB4qVTMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBXYh80BF4rcJkXEDWrZ6GgIpXrUSmDiIM/UHiFzUms FPQhI2UY1FJx1SsvpAMbLcxJvE5XxmtOpQJWGvpR7v0d1sX6c8tzde5Btt8e/kQ3cV6sXeHy359n zaO6ha91C23+PPLipiJYaGt1DpFSWeGFZcYUXZQoMq9ATTpD7ulrjOMZhM7uklmQ9WaNAMVyem8X zARuMXftJf4BEb0N7WsuVn4jW5nAx4CfxB2fSUa8/dLsJ8pmq98kcV2Mng9uGA1EMefdRal0DcNC 5dEARRg8+vqVVr+FgKzaQTZe8i2hMwCnCUlO+ZwUsFAodNWG6x0r7h08imXE7ew9BClrCNKAAAAA AAAA --Apple-Mail=_D04F9C96-B142-472B-BA0A-0AB4C3564467-- From rlb@ipv.sx Wed Feb 27 19:11:06 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9801E21F89E5 for ; Wed, 27 Feb 2013 19:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIuUklpwm-Vc for ; Wed, 27 Feb 2013 19:11:05 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB321F8A42 for ; Wed, 27 Feb 2013 19:11:00 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so2697479oag.40 for ; Wed, 27 Feb 2013 19:10:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4ta8ffmcOCPdHs1FgW+4Zkt1//ZuJbfTvWgO8W4SoPY=; b=SChki1PTQgah8q/J4EVNO6/rcsDi4fMEBY3yftVV0JZ7jqeFU7vhYuHBXXwb/XFx7t r2xpeoZabmlpD2l0TKmMzrUWh1R+v9BJVSUGPzEr+M1nAvAv1ux+wrg/Zdt+JjWW4Phx ozNs2cBq+B8CT/FsWhlra/64ebEZDKRb0GbNWeK4YTWcA5b4+eXvqYmvZ8Dab7tKga8o PfEf0BNej35yHkK/I7SJcBG2kxwSBusMl4qdVH6ABt/slzOgi5ZagyLFE7Sl8iOJ5exM WYAR0jhWzmBmNGk90aEEwzQC0zR6y+nAMMgdQGINyYvOOqE9C5GzvkkXzzdotvz0r6ZG m7UQ== MIME-Version: 1.0 X-Received: by 10.182.40.71 with SMTP id v7mr4302514obk.85.1362021057835; Wed, 27 Feb 2013 19:10:57 -0800 (PST) Received: by 10.60.60.98 with HTTP; Wed, 27 Feb 2013 19:10:57 -0800 (PST) X-Originating-IP: [108.18.40.68] In-Reply-To: References: <512CC832.1060702@jonkri.com> <512E94A2.8000900@jonkri.com> Date: Wed, 27 Feb 2013 22:10:57 -0500 Message-ID: From: Richard Barnes To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=f46d04446c11544b8a04d6c03d0f X-Gm-Message-State: ALoCoQno1ns3ykLcJJV8JRUBN0oKNabEds2oNTWct6hTaVqFlsd+w0dGckvBR60kk7vRQtlHmwHb Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 03:11:06 -0000 --f46d04446c11544b8a04d6c03d0f Content-Type: text/plain; charset=ISO-8859-1 It appears there is some conversation to be had about requirements. But it sounds to me like there's a large degree of consistency here. As Matt says, a lot of what Jon is talking about can be supported as options within an overall e2e system, so that, say, implantations that want "malleability" can use CTR, while those with other priorities can use authenticated encryption (say GCM). And of course, the whole point of the e2e model is to reduce the level of control and access that servers have. On Wednesday, February 27, 2013, Matt Miller (mamille2) wrote: > > On Feb 27, 2013, at 4:20 PM, Jon Kristensen > > > wrote: > > > Hi Richard, and thank you for your question! > > > > I may be wrong - I only skimmed through it, but the way I understand > that specification, it's using public-key cryptography is used to encrypt > and decrypt the messages. If this is the case, it would mean that the > protocol does not offer repudiability; if Alice sends a message to Bob, Bob > can prove that Alice (or, at least, someone with access to Alice's private > key) has authored a message. In most off-the-record conversations, this > would not be desirable. What OTR does is negotiates a shared secret > (symmetric key), which is then used to encrypt and decrypt the messages. > What this means is that Bob, having access to the encryption key, could > have just as easily produced the message. Hence, Alice can deny that she > authored the message in the first place. > > > > Well, strictly speaking, the messages are protected with a symmetric key. > That symmetric key, which is exchanged separately from the message(s), is > currently protected by a public key. I suppose we could work out a key > request model that utilized a different key agreement if that is important > enough. > > > Furthermore, the negotiation of a shared secret is continuously repeated > in OTR in order to allow for forward secrecy. This prevents previous > session keys from being compromised if the (long-term) private key happens > to get compromised. I think this is another important security feature to > keep in mind. > > > > The session key could be rotated with every message if implementations > desire it. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > --f46d04446c11544b8a04d6c03d0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It appears there is some conversation to be had about requirements. But it = sounds to me like there's a large degree of consistency here.=A0
As Matt says, a lot of what Jon is talking about can be suppor= ted as options=A0within an overall e2e system, so that, say,=A0 implantatio= ns that want "malleability" can use CTR, while those with other p= riorities can use authenticated encryption (say GCM).=A0

And of course, the whole point of the e2e = model is to reduce the level of control and access that servers have.=A0



On Wednesday, February 27, 2013, Matt Miller= (mamille2) wrote:

On Feb 27, 2013, at 4:20 PM, Jon Kristensen <info@jonkri.= com>
=A0wrote:

> Hi Richard, and thank you for your question!
>
> I may be wrong - I only skimmed through it, but the way I understand t= hat specification, it's using public-key cryptography is used to encryp= t and decrypt the messages. If this is the case, it would mean that the pro= tocol does not offer repudiability; if Alice sends a message to Bob, Bob ca= n prove that Alice (or, at least, someone with access to Alice's privat= e key) has authored a message. In most off-the-record conversations, this w= ould not be desirable. What OTR does is negotiates a shared secret (symmetr= ic key), which is then used to encrypt and decrypt the messages. What this = means is that Bob, having access to the encryption key, could have just as = easily produced the message. Hence, Alice can deny that she authored the me= ssage in the first place.
>

Well, strictly speaking, the messages are protected with a symmetric key. = =A0That symmetric key, which is exchanged separately from the message(s), i= s currently protected by a public key. =A0I suppose we could work out a key= request model that utilized a different key agreement if that is important= enough.

> Furthermore, the negotiation of a shared secret is continuously repeat= ed in OTR in order to allow for forward secrecy. This prevents previous ses= sion keys from being compromised if the (long-term) private key happens to = get compromised. I think this is another important security feature to keep= in mind.
>

The session key could be rotated with every message if implementations desi= re it.


- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.

--f46d04446c11544b8a04d6c03d0f-- From stpeter@stpeter.im Wed Feb 27 19:26:40 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA7B21F89E5 for ; Wed, 27 Feb 2013 19:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qleuOQ6mpPx for ; Wed, 27 Feb 2013 19:26:39 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2774D21F8698 for ; Wed, 27 Feb 2013 19:26:39 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A1CA14060C; Wed, 27 Feb 2013 20:34:26 -0700 (MST) Message-ID: <512ECE68.70001@stpeter.im> Date: Wed, 27 Feb 2013 20:26:32 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Richard Barnes References: <512CC832.1060702@jonkri.com> <512E94A2.8000900@jonkri.com> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 03:26:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/27/13 8:10 PM, Richard Barnes wrote: > It appears there is some conversation to be had about requirements. > It's funny you should say that, because Matt and I were talking just today about how we might need to update the old requirements document: https://tools.ietf.org/id/draft-saintandre-xmpp-e2e-requirements-01.txt Feedback is welcome. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLs5oAAoJEOoGpJErxa2pDqUQAJj/EnjpsdT+ubrKuVrlpZCY J5tyZ9a3zO2di/zFzzNTxkmJYWXfBzsgj1Gubm/JjI2r3NdRsltBAHt6Pvq2fdPe axFpKL+90+fMBzXtixnTji6x6SCBuUciPdjgIHvyIIfjhT9mZXt/I6BAQ3JkrCn5 8kDABPZAoEltGihTKznuP+ljnHQSNe4Sue08eTqQUSaIXfPszemdWOguMsylbT+o MAP+MKOQMLeF0yfjiSEtX5rvYA0Cm+T/08AiZlpvum405XeJol+2ygmedgrmlwWh Gud0pCycdEVtJZ+d/Ec4yTa5RN0y9Bz6Ns3po9PPHeuYEtZpRIcTOnqm0sC51XcZ aBubXu5F4QMc1cwT7m2ve/IMytnTKI1zAi9etGH5nYB2QLTtkDZwFlBgnmFlYQjV ECdhovw2P8/wsjOvGsE70boLfKVFz7MtVnxFdjX9Q/uj/52OikUF3NOp2BvnLiRx 8LYZRqOCU1jw9ZrXlsA2n0D8nZtavVkKOVLROHl/cYowINFKNE/f2lICK1oSm+zd xPV260lcaU6ikdFh6m777EvQd3OFIuBITzTx/R1PBidUhLPWONJ7KIgye5YmPBLk SnwyDHm+7mbgyzV9aVw9kflJjxfkKEIULBSGhW5lpMKsglsHz9qcorvBOgRhjg9H duceAxz7wlBD2IBiS7dc =bRGa -----END PGP SIGNATURE----- From jon.kristensen@nejla.com Thu Feb 28 14:14:55 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E814D21F8749 for ; Thu, 28 Feb 2013 14:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.304 X-Spam-Level: X-Spam-Status: No, score=-0.304 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_LH_LD=1.215, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZRsU3XAOPeOX for ; Thu, 28 Feb 2013 14:14:55 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB4B21F8738 for ; Thu, 28 Feb 2013 14:14:54 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id ec20so2321570lab.37 for ; Thu, 28 Feb 2013 14:14:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=J27kuMSva9BKKSMq05XDL3X3tU5XP2l0mYkkT3PT6K0=; b=fZsHVvJ6P+lrfme/znrlSoo1Nc6Y8JtejXiulOLtF5AiF7rUaU8FjyEI7cGHGhFmSU 7oBJ1k5kvoByq2dQwMKn0B5kNmOaA1+VnaEdwxKuB28i4VIDEJFKw309WKTvXwHdxSpM 7rxtLmqb7H217MjeRy2zz5grAT8y3RXHL7mg2CNbHMPEgT4ELDDehpReEr0zXbpUBp5b aGXy9XUE83e0sdQcACMx0caBLfp7ItHgMlAEL9FaQyxsJV8AsqdHASDuymJw6kH/CRpm XxxkzYF/Rnm8v5IrZ9ElOmI3a7ETeNfSHBQrZ4zvNuv70J8IltPN0XM8FRLIC4QX6mxZ p/iw== X-Received: by 10.152.128.98 with SMTP id nn2mr7047639lab.17.1362089693959; Thu, 28 Feb 2013 14:14:53 -0800 (PST) Received: from localhost.localdomain ([94.234.185.66]) by mx.google.com with ESMTPS id pk1sm5476059lab.0.2013.02.28.14.14.52 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Feb 2013 14:14:53 -0800 (PST) Message-ID: <512FD6DB.40304@jonkri.com> Date: Thu, 28 Feb 2013 23:14:51 +0100 From: Jon Kristensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130219 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <512CC832.1060702@jonkri.com> <512E94A2.8000900@jonkri.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnq3Lh8Th9MAakSfHE3Wz2aiEJVHXLq6gEwxkoYW2arcGHzG1Qq7+V1NyERTt6uR/elRuWR Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:14:56 -0000 On 02/28/2013 03:34 AM, Matt Miller (mamille2) wrote: > Well, strictly speaking, the messages are protected with a symmetric > key. That symmetric key, which is exchanged separately from the > message(s), is currently protected by a public key. I suppose we could > work out a key request model that utilized a different key agreement > if that is important enough. Just to confirm: Are you saying that the current key agreement method is inherently incompatible with repudiability? > The session key could be rotated with every message if implementations > desire it. Would rotating the key in this way enable forward secrecy? Best, Jon Kristensen From rlb@ipv.sx Thu Feb 28 14:30:26 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D38B21F86B8 for ; Thu, 28 Feb 2013 14:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.744 X-Spam-Level: X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1QBjMjEyWtI for ; Thu, 28 Feb 2013 14:30:26 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id CD6CF21F85B2 for ; Thu, 28 Feb 2013 14:30:25 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so4626405oag.5 for ; Thu, 28 Feb 2013 14:30:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TNYf2t+54aD9qFYTCixniJ43Wyvg9XsAWNwhamTyL3s=; b=lIvYhSdJobFya5HvAgeygcgJAc4cXG4I6RbgKcby09ksy9WvOrj3BoUAGZ1x1Jtygs kiJMMWLKpSIHMRMjcWbWWw1FzHttakdTjB5LrN3zeOArVzTQD4QskUiIGub+LgoflJxW VXy9MSlzWXbW+9zvVJaFGYXF6A7Q3y5YooL2yNFpOUTkL4Mw/mFCkLe0cE9lCc1nFRWw v8sk/mbssvNdX0kwcZ/cladj88r4UxXpwNP9gb4898F7qOkW5VaFrnRwH4rAxHwtzv4E eUbVCVojUYOtRYm2878oBkV9lJDZ+FUfnmaEvGEdEtrgrgvYNRQ/MWHqX4lCx5/1He+B HAHQ== MIME-Version: 1.0 X-Received: by 10.60.13.1 with SMTP id d1mr7106872oec.55.1362090625391; Thu, 28 Feb 2013 14:30:25 -0800 (PST) Received: by 10.60.10.101 with HTTP; Thu, 28 Feb 2013 14:30:25 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <512FD6DB.40304@jonkri.com> References: <512CC832.1060702@jonkri.com> <512E94A2.8000900@jonkri.com> <512FD6DB.40304@jonkri.com> Date: Thu, 28 Feb 2013 17:30:25 -0500 Message-ID: From: Richard Barnes To: Jon Kristensen Content-Type: multipart/alternative; boundary=e89a8ff25008e0f22e04d6d06fd1 X-Gm-Message-State: ALoCoQl07sDmwGP2lA7F4JnEZiOA69hoU+tTFnHmxwsPgyxIjAxKOtvAdfm3MfztALNz2AZPWqKT Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 22:30:26 -0000 --e89a8ff25008e0f22e04d6d06fd1 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 28, 2013 at 5:14 PM, Jon Kristensen wrote: > On 02/28/2013 03:34 AM, Matt Miller (mamille2) wrote: > >> Well, strictly speaking, the messages are protected with a symmetric key. >> That symmetric key, which is exchanged separately from the message(s), is >> currently protected by a public key. I suppose we could work out a key >> request model that utilized a different key agreement if that is important >> enough. >> > > Just to confirm: Are you saying that the current key agreement method is > inherently incompatible with repudiability? Could you clarify what you mean by "repudiability"? Do you mean that, post-hoc, it is impossible to tell which of the parties holding a symmetric key generated a given stanza? The current system is explicitly *compatible* with this notion of repudiability. As Matt says, in the current scheme, the sender makes up a random symmetric key and wraps it in the recipient's public key. The message is then encrypted under the symmetric key. So the sender and the receiver share a symmetric key, and either of them can modify the message to be whatever they want. > The session key could be rotated with every message if implementations >> desire it. >> > > Would rotating the key in this way enable forward secrecy? > No. Compromise of the recipient's private key would expose all of the session keys. If you want forward secrecy, you need to do DH. --Richard --e89a8ff25008e0f22e04d6d06fd1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 28, 2013 at 5:14 PM, Jon Kristensen <info@jonkri.com> wrote:
On 02/28/2013 03:34 AM, Matt Miller (mamille2) wrote:
Well, strictly speaking, the messages are protected with a symmetric key. T= hat symmetric key, which is exchanged separately from the message(s), is cu= rrently protected by a public key. I suppose we could work out a key reques= t model that utilized a different key agreement if that is important enough= .

Just to confirm: Are you saying that the current key agreement method is in= herently incompatible with repudiability?

C= ould you clarify what you mean by "repudiability"? =A0Do you mean= that, post-hoc, it is impossible to tell which of the parties holding a sy= mmetric key generated a given stanza?

The current system is explicitly *compatible* with this= notion of repudiability. =A0As Matt says, in the current scheme, the sende= r makes up a random symmetric key and wraps it in the recipient's publi= c key. =A0The message is then encrypted under the symmetric key. =A0So the = sender and the receiver share a symmetric key, and either of them can modif= y the message to be whatever they want.

=A0
The session key could be rotated with every message if implementations desi= re it.

Would rotating the key in this way enable forward secrecy?
=

No. =A0Compromise of the recipient's private key wo= uld expose all of the session keys. =A0If you want forward secrecy, you nee= d to do DH.

--Richard

=A0
--e89a8ff25008e0f22e04d6d06fd1-- From mamille2@cisco.com Thu Feb 28 15:22:01 2013 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0686C21F8801 for ; Thu, 28 Feb 2013 15:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB8VrhjpI0kr for ; Thu, 28 Feb 2013 15:21:59 -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 6859F21F87CE for ; Thu, 28 Feb 2013 15:21:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5946; q=dns/txt; s=iport; t=1362093714; x=1363303314; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k1GNDMMrs+g5QEZVTibnLK/EL6D84zgHoReEjZs0KWY=; b=FLSeTDR0Ts8gLs08TYLBRaAuoRYHiMxHBhSc1GMTNHsDzY5tBmdFixmE 9U8VT5Ifxmxyk7RoW4sClsBuFOavFm94YWqiNErTSV7Sx8ayc3jCbQgj2 yEW8YNPMcULg86O6rZIGn+RMV5h3h1IEVYaSviq52MnGWJA1YK46QnOqy 4=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACDmL1GtJV2Z/2dsb2JhbABFwjN+FnOCHwEBAQMBeQULAgEIDgoKJAIwJQIEDgUIBod/BsFmjmMWGweCX2EDjyaBJpZfgwiCJw X-IronPort-AV: E=Sophos;i="4.84,757,1355097600"; d="p7s'?scan'208";a="182441626" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 28 Feb 2013 23:21:52 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r1SNLpTf004586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Feb 2013 23:21:51 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Thu, 28 Feb 2013 17:21:51 -0600 From: "Matt Miller (mamille2)" To: Richard Barnes Thread-Topic: [xmpp] Self Introduction Thread-Index: AQHOFC6MLgMtxyNBOkuDluRd7596QJiObTQAgABQ8wCAADZDAIABSdyAgAAEWYCAAA5fgA== Date: Thu, 28 Feb 2013 23:21:51 +0000 Message-ID: References: <512CC832.1060702@jonkri.com> <512E94A2.8000900@jonkri.com> <512FD6DB.40304@jonkri.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.88] Content-Type: multipart/signed; boundary="Apple-Mail=_31356AF9-C838-4222-8DB1-F886BC6754E1"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [xmpp] Self Introduction X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 23:22:01 -0000 --Apple-Mail=_31356AF9-C838-4222-8DB1-F886BC6754E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 28, 2013, at 3:30 PM, Richard Barnes wrote: > On Thu, Feb 28, 2013 at 5:14 PM, Jon Kristensen = wrote: >=20 >> On 02/28/2013 03:34 AM, Matt Miller (mamille2) wrote: >>=20 >>> Well, strictly speaking, the messages are protected with a symmetric = key. >>> That symmetric key, which is exchanged separately from the = message(s), is >>> currently protected by a public key. I suppose we could work out a = key >>> request model that utilized a different key agreement if that is = important >>> enough. >>>=20 >>=20 >> Just to confirm: Are you saying that the current key agreement method = is >> inherently incompatible with repudiability? >=20 >=20 > Could you clarify what you mean by "repudiability"? Do you mean that, > post-hoc, it is impossible to tell which of the parties holding a = symmetric > key generated a given stanza? >=20 > The current system is explicitly *compatible* with this notion of > repudiability. As Matt says, in the current scheme, the sender makes = up a > random symmetric key and wraps it in the recipient's public key. The > message is then encrypted under the symmetric key. So the sender and = the > receiver share a symmetric key, and either of them can modify the = message > to be whatever they want. >=20 >=20 >=20 >> The session key could be rotated with every message if = implementations >>> desire it. >>>=20 >>=20 >> Would rotating the key in this way enable forward secrecy? >>=20 >=20 > No. Compromise of the recipient's private key would expose all of the > session keys. If you want forward secrecy, you need to do DH. >=20 For whatever value this adds, if an attacker: 1) has compromised the recipient's private key 2) has observed all of the encrypted traffic between the sender and the = recipient 3) can communicate with the sender as if it were the recipient (to get = the next session key) 4) convinces the sender the public portion of the compromised private = key is still valid[1] Then all of the past and future session keys are exposed. If any two of = those conditions don't hold then some set of session keys are not = exposed. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [1] This condition has been left as "an exercise for the implementation" = to determine, so might not be worth any consideration.= --Apple-Mail=_31356AF9-C838-4222-8DB1-F886BC6754E1 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDIyODIzMjE1MVowIwYJKoZIhvcNAQkEMRYEFIBTlN0e7UMC/b16QMGBkdvHoo22MIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBQWjpGTMwjC2nuG3rADAUwrcsOAYkOaOOa7aUlzERb wg76AG6pcguY0x29HFUJz8jT3Y+ufs9SYQkgzhJEboPr5maHsXTUro3/dmBd4Jnltyg0Ywqdadlh GZuRf9yFW7jyDLQKKwB4ESzxmAuF66qBSRmrLrCWSEAMxewBQ14kGsXEU9RNNn4jnm6MUyfCan4B XPZg6BcnewCJcUNU9atCRFJQxQA4l9G1jOp0C73lHMB4r1tf2hMQsENwCsz1V0sZQhS4IFNjC/tO +supk19tqhUHhDy5g98+N9lGfUhlmV+8+0F40Jm6ireraXu7rU3SX9O42MH7/pxMu6hdpWNiAAAA AAAA --Apple-Mail=_31356AF9-C838-4222-8DB1-F886BC6754E1--