From nobody Mon Dec 7 12:52:20 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428F11A87A0 for ; Mon, 7 Dec 2015 12:52:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6w5uYdiDih9 for ; Mon, 7 Dec 2015 12:52:17 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id A68C21A8740 for ; Mon, 7 Dec 2015 12:52:17 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A90DC180471; Mon, 7 Dec 2015 12:50:17 -0800 (PST) To: peter@andyet.com, ben@nostrum.com, alissa@cooperw.in, barryleiba@computer.org, jhildebr@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151207205017.A90DC180471@rfc-editor.org> Date: Mon, 7 Dec 2015 12:50:17 -0800 (PST) Archived-At: Cc: xmpp@ietf.org, stpeter@stpeter.im, rfc-editor@rfc-editor.org Subject: [xmpp] [Editorial Errata Reported] RFC7622 (4560) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 20:52:19 -0000 The following errata report has been submitted for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7622&eid=4560 -------------------------------------- Type: Editorial Reported by: Peter Saint-Andre Section: 3.5 Original Text ------------- | 18| | Leading space in resourcepart | Corrected Text -------------- [nothing] Notes ----- Example 18 is wrong because a leading space is currently allowed by RFC 7622 (at least, it is not disallowed by the OpaqueString profile defined in RFC 7613). It is true that leading and trailing spaces are disallowed by the Nickname profile, but we do not reference that here. This example should be removed in any updates to RFC 7622. Instructions: ------------- This erratum 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. -------------------------------------- RFC7622 (draft-ietf-xmpp-6122bis-24) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Publication Date : September 2015 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Sat Dec 12 09:13:39 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CF91A895E; Sat, 12 Dec 2015 09:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRPHC1Cdz8wp; Sat, 12 Dec 2015 09:13:31 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id BDC401A895D; Sat, 12 Dec 2015 09:13:31 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id CDC37180003; Sat, 12 Dec 2015 09:11:16 -0800 (PST) To: stpeter@stpeter.im, peter@andyet.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151212171116.CDC37180003@rfc-editor.org> Date: Sat, 12 Dec 2015 09:11:16 -0800 (PST) Archived-At: Cc: barryleiba@computer.org, iesg@ietf.org, xmpp@ietf.org, rfc-editor@rfc-editor.org Subject: [xmpp] [Errata Verified] RFC7622 (4560) X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Dec 2015 17:13:33 -0000 The following errata report has been verified for RFC7622, "Extensible Messaging and Presence Protocol (XMPP): Address Format". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=7622&eid=4560 -------------------------------------- Status: Verified Type: Editorial Reported by: Peter Saint-Andre Date Reported: 2015-12-07 Verified by: Barry Leiba (IESG) Section: 3.5 Original Text ------------- | 18| | Leading space in resourcepart | Corrected Text -------------- [nothing] Notes ----- Example 18 is wrong because a leading space is currently allowed by RFC 7622 (at least, it is not disallowed by the OpaqueString profile defined in RFC 7613). It is true that leading and trailing spaces are disallowed by the Nickname profile, but we do not reference that here. This example should be removed in any updates to RFC 7622. -------------------------------------- RFC7622 (draft-ietf-xmpp-6122bis-24) -------------------------------------- Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Publication Date : September 2015 Author(s) : P. Saint-Andre Category : PROPOSED STANDARD Source : Extensible Messaging and Presence Protocol Area : Applications and Real-Time Stream : IETF Verifying Party : IESG From nobody Thu Dec 17 12:45:43 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411661B30A2 for ; Thu, 17 Dec 2015 12:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.521 X-Spam-Level: X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ytosZIbzE68 for ; Thu, 17 Dec 2015 12:45:39 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7D31A8935 for ; Thu, 17 Dec 2015 12:45:39 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id y66so49467915oig.0 for ; Thu, 17 Dec 2015 12:45:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rwZ2fNaX4O6koiLm5ZqJCzXSCTQ/0qC2cVEVbFeWd5c=; b=Qq07kQBwqOpVpI4ySJlIAMhS1sJBtME7r7SrfSyP/AOTSCWSupuWJ+dwWY5UR1gIRK QA231IKmVPNOLtttqPZyx8tNE9VIlui0KX0PeUomld4+N6ldeZoCWIxjv4rreqdPC8Zt QLAkGd4mv8NSMReV0d1LLbC2jj6N9EmvKR4A0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=rwZ2fNaX4O6koiLm5ZqJCzXSCTQ/0qC2cVEVbFeWd5c=; b=KcofGYIQyJJMJw+OS7Bfe5puhkwow5ifsl8x3koMV1Lxknl/Xu6VPWOgdYBohWR+A1 Owm5ogr2pLEOpmHGDRI6Uz7K33X2YMxwh/KrftCzsHhbk/RtBWanBvzp/drSYemLThiO JEVl5ps6G5Yu/QcQyXiDti5QbOCq9YYOv5zOTT3nsrmcjz4BNgZaG6pts7j0nCfPprbJ ZR2gKCYzTUToq8b9shj/mOiYpSBgGYIqoMEomRDPLADZpcewcdjdmCUNwvfWWUTbTw6Y RhONbakSrVTLCYWVyRgv57/uxbpwP80eGXyMlfA8xvFeDraqApvqe0SH6zfHZDTz9YND 260g== X-Gm-Message-State: ALoCoQkal/EjOSaylxFj7lop7zE09aM5uFNKrKPKu4UifMRB1av/kayqMC0ludzwj6FUb8siEVYxvdIoMhDRKLrl+VFnV6e/g95oFOHLI+bPFewRka58ONQ= MIME-Version: 1.0 X-Received: by 10.202.80.4 with SMTP id e4mr9624934oib.139.1450385138788; Thu, 17 Dec 2015 12:45:38 -0800 (PST) Received: by 10.60.6.134 with HTTP; Thu, 17 Dec 2015 12:45:38 -0800 (PST) In-Reply-To: <562AA40E.40407@nostrum.com> References: <562AA40E.40407@nostrum.com> Date: Thu, 17 Dec 2015 20:45:38 +0000 Message-ID: From: Dave Cridland To: Adam Roach Content-Type: multipart/alternative; boundary=001a113d7514fc49a705271e1a27 Archived-At: Cc: XMPP Working Group Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 20:45:41 -0000 --001a113d7514fc49a705271e1a27 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23 October 2015 at 22:18, Adam Roach wrote: > XMPP folks: > > Martin and I put together a proposal for an approach that allows for > end-to-end encrypted XMPP conversations, including in the presence of MUC= . > Although not a completely implementable spec, this should give a good ide= a > about the direction we have in mind: > > https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 > > Anyone interested in this work should give it a read and provide feedback= . > In particular, I'm curious if anyone interested in implementing this kind > of thing has requirements can't be addressed with the high-level approach > we're describing. > I'm nothing if not prompt in my reviews. :-) Overall, I'm thinking this deserves more investigation, although =C2=A78 re= ally needs pulling out and turning into a (much longer) XEP. It may need killing with fire; right now it's simply far too sparse to properly judge. But on the assumption that this is orthogonal to the remainder of the spec, the actual e2e protocol looks essentially OK to me. A key factor will be supporting Pubsub (XEP-0060), and (probably) advertising keys over PEP (XEP-0163) rather than presence - and since PEP *is* PubSub, that leads into a fascinating discussion of recursion. We need to look at Carbons (XEP-0280) and MAM (XEP-0313), and how these fit in, too= . I'm in two minds as to the right venue for discussion of the bulk of this, however. Part of me feels that the IETF has the better understanding of cryptography and commsec, but with all the other proposals we've ever had, bar one, being discussed in the XSF I'd be inclined to suggest you brought it there. This also has the advantage that the majority of the client developers are, more or less, based within the XSF rather than here, so I think that if there's traction to be had, it'll be had within the XSF. Finally, this gives you the golden opportunity to travel to Belgium at the end of January and discuss this in person at the XSF's Summit - which I'd love to see happen, and I promise to buy you both a beer or two if you do. Dave. --001a113d7514fc49a705271e1a27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 3 October 2015 at 22:18, Adam Roach <adam@nostrum.com> wrote:=
XMPP folks:

Martin and I put together a proposal for an approach that allows for end-to= -end encrypted XMPP conversations, including in the presence of MUC. Althou= gh not a completely implementable spec, this should give a good idea about = the direction we have in mind:

https://tools.ietf.org/html/draft-thomson-xm= pp-secure-00

Anyone interested in this work should give it a read and provide feedback. = In particular, I'm curious if anyone interested in implementing this ki= nd of thing has requirements can't be addressed with the high-level app= roach we're describing.

I'm not= hing if not prompt in my reviews. :-)

Overall, I&#= 39;m thinking this deserves more investigation, although =C2=A78 really nee= ds pulling out and turning into a (much longer) XEP. It may need killing wi= th fire; right now it's simply far too sparse to properly judge. But on= the assumption that this is orthogonal to the remainder of the spec, the a= ctual e2e protocol looks essentially OK to me.

A key factor will be supporting Pubsub (XEP-0060), and (probably) advertis= ing keys over PEP (XEP-0163) rather than presence - and since PEP *is* PubS= ub, that leads into a fascinating discussion of recursion. We need to look = at Carbons (XEP-0280) and MAM (XEP-0313), and how these fit in, too.
<= div>
I'm in two minds as to the right venue for discussio= n of the bulk of this, however.

Part of me feels t= hat the IETF has the better understanding of cryptography and commsec, but = with all the other proposals we've ever had, bar one, being discussed i= n the XSF I'd be inclined to suggest you brought it there. This also ha= s the advantage that the majority of the client developers are, more or les= s, based within the XSF rather than here, so I think that if there's tr= action to be had, it'll be had within the XSF.

Finally, this gives you the golden opportunity to travel to Belgium at the= end of January and discuss this in person at the XSF's Summit - which = I'd love to see happen, and I promise to buy you both a beer or two if = you do.

Dave.
--001a113d7514fc49a705271e1a27--