From nobody Mon Mar 3 02:04:54 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB7201A0D69 for ; Mon, 3 Mar 2014 02:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3V9ZH8RSSGx for ; Mon, 3 Mar 2014 02:04:50 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7DC1A0D8D for ; Mon, 3 Mar 2014 02:04:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=855; q=dns/txt; s=iport; t=1393841088; x=1395050688; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=iRJ+KqscsPNzA9EaFkiGEFLj562KMgIj2TLyZje1JYc=; b=MHCTJdk0hAp0HqtrmxjUvNBJtIIUOokqPMEJXZjwC6oPH80CYIiMs7mV KqRThsKO9gMl4VgJj+FdOoXQHSlHehCIEape1mAvPcENqvEbNZssdPF/4 aRmvP4zefsZtunFmALijtwm95srumdhJEhDKAcKSOwW2n6oN2E7l2axkj k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcJANdSFFOtJV2Y/2dsb2JhbABaFoJwO1enYQSaBxZ0gip6PRYYAwIBAgFLDQYCAQGHdQ2cRK9vF5MYBIkTjymSK4Mtgio X-IronPort-AV: E=Sophos;i="4.97,576,1389744000"; d="scan'208";a="24445981" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP; 03 Mar 2014 10:04:47 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s23A4lD1013892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 3 Mar 2014 10:04:47 GMT Received: from MAMILLE2-M-T03K.local (10.86.252.184) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 3 Mar 2014 04:04:47 -0600 Message-ID: <531453BF.1070404@cisco.com> Date: Mon, 3 Mar 2014 10:04:47 +0000 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP Group X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.86.252.184] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/wxa_fmKpf9fuHP397yhDM3keCR0 Subject: [xmpp] Slides for E2E 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, 03 Mar 2014 10:04:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 My slides for XMPP E2E are available at < https://outer-planes.net/~linuxwolf/ietf/ietf89-xmppwg-e2e.pdf >. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFFO/AAoJEDWi+S0W7cO1ig0H/3dqmb4H+UUPo/+WC25SuXDu LYcoSkBWDZ9MWSZ9xSrnLUN4afSlA1lvjMzkw8Qo+yTePZDESbNjIL6Fjd16QywM k0LLEwYm7kJdyL+T+ippq0+xm6Asry3JrYZZHmS4Tv8L0aohgV2hiDRPv/zDM0oD A79tXR/djG9MmFhiu/rtUgr1E7WWn34UxBpF9MNLPsjnZUIOd2peDmqz1+bOE0Ym KAZTmZQS3nG1bzVUy/VG8CkCSQY9Tc+duvwC/kxkj0sc/GxBWLfvGiahP3GyE8Qu C4hzLXoHgAGVf+YEaiFM4dtOWqVH0RJBCHUiVGJaOXw4m1EFe/CQ+zvWQsTEO2c= =IpTz -----END PGP SIGNATURE----- From nobody Mon Mar 3 03:56:22 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E70C1A003A for ; Mon, 3 Mar 2014 03:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2X7BHONH58bE for ; Mon, 3 Mar 2014 03:56:19 -0800 (PST) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) by ietfa.amsl.com (Postfix) with ESMTP id 19AEE1A001A for ; Mon, 3 Mar 2014 03:56:18 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id p61so1853083wes.25 for ; Mon, 03 Mar 2014 03:56:15 -0800 (PST) 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=+LNMO2suLnVjmH4x9lIfWVQDco1ha6Qh8y38LXNf0JQ=; b=grvx7RhbK8GDrYtDmjAKTMEW8GuPd5e35UXlZoCqHXEt9lovCcVKoiuLn+ZNmvIenS QVDNrAS9WdKvk/DPUDLvTQXuIdKe8GSt0Do7GAepQYgNih6cyFOfZ3QUAyTu16n+iLtR S80YEDP/Omru5o+9wpWFNApm9xTPfoVFKis5CE7TiMxbxH107+0Yoa4ihalDMpEN39aM x/6QOSpx9qhcp1nKDOQxBrS/OxJa/yeh5lj+QRON1rxQms24ZhSxvrC3YHYo+sC/K2+3 +7QGaOUPnk/AXZmg3OjwjBnug461kKyNpxus8IhXNgKsxPTvn97WBm/pVRIsfJNPEL7B zlZw== X-Gm-Message-State: ALoCoQnRowxX2XsENR+WxRrjA8V4FKbn/sfQUwfDY7giFo7u9Hm79BItt5+NTsasPZP427MoX7D8 MIME-Version: 1.0 X-Received: by 10.194.87.195 with SMTP id ba3mr7240550wjb.53.1393847775780; Mon, 03 Mar 2014 03:56:15 -0800 (PST) Received: by 10.194.40.232 with HTTP; Mon, 3 Mar 2014 03:56:15 -0800 (PST) X-Originating-IP: [194.127.8.12] In-Reply-To: <531453BF.1070404@cisco.com> References: <531453BF.1070404@cisco.com> Date: Mon, 3 Mar 2014 12:56:15 +0100 Message-ID: From: Simon Tennant To: Matt Miller Content-Type: multipart/alternative; boundary=089e0102ee248bf9b104f3b2797f Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/qmEXshSxi2luDWrNirgaiq3bX44 Cc: XMPP Group Subject: Re: [xmpp] Slides for E2E 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, 03 Mar 2014 11:56:22 -0000 --089e0102ee248bf9b104f3b2797f Content-Type: text/plain; charset=UTF-8 Matt - you should go into slide making full time. Your slides are always amusing. S. On 3 March 2014 11:04, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > My slides for XMPP E2E are available at < > https://outer-planes.net/~linuxwolf/ietf/ietf89-xmppwg-e2e.pdf >. > > > - -- > - - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.22 (Darwin) > Comment: GPGTools - https://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBCgAGBQJTFFO/AAoJEDWi+S0W7cO1ig0H/3dqmb4H+UUPo/+WC25SuXDu > LYcoSkBWDZ9MWSZ9xSrnLUN4afSlA1lvjMzkw8Qo+yTePZDESbNjIL6Fjd16QywM > k0LLEwYm7kJdyL+T+ippq0+xm6Asry3JrYZZHmS4Tv8L0aohgV2hiDRPv/zDM0oD > A79tXR/djG9MmFhiu/rtUgr1E7WWn34UxBpF9MNLPsjnZUIOd2peDmqz1+bOE0Ym > KAZTmZQS3nG1bzVUy/VG8CkCSQY9Tc+duvwC/kxkj0sc/GxBWLfvGiahP3GyE8Qu > C4hzLXoHgAGVf+YEaiFM4dtOWqVH0RJBCHUiVGJaOXw4m1EFe/CQ+zvWQsTEO2c= > =IpTz > -----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 --089e0102ee248bf9b104f3b2797f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Matt - you should go into slide making full time.
=
Your slides are always amusing.

S.


On 3 March 2014 11:04, Matt= Miller <mamille2@cisco.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

My slides for XMPP E2E are available at <
https://outer-planes.net/~linuxwolf/ietf/ietf89-xmppwg-e2= e.pdf >.


- --
- - m&m

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

iQEcBAEBCgAGBQJTFFO/AAoJEDWi+S0W7cO1ig0H/3dqmb4H+UUPo/+WC25SuXDu
LYcoSkBWDZ9MWSZ9xSrnLUN4afSlA1lvjMzkw8Qo+yTePZDESbNjIL6Fjd16QywM
k0LLEwYm7kJdyL+T+ippq0+xm6Asry3JrYZZHmS4Tv8L0aohgV2hiDRPv/zDM0oD
A79tXR/djG9MmFhiu/rtUgr1E7WWn34UxBpF9MNLPsjnZUIOd2peDmqz1+bOE0Ym
KAZTmZQS3nG1bzVUy/VG8CkCSQY9Tc+duvwC/kxkj0sc/GxBWLfvGiahP3GyE8Qu
C4hzLXoHgAGVf+YEaiFM4dtOWqVH0RJBCHUiVGJaOXw4m1EFe/CQ+zvWQsTEO2c=3D
=3DIpTz
-----END PGP SIGNATURE-----

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



--
Simon Tennant | buddycloud.com | +49 17 85= 45 0880 | office hours: g= oo.gl/tQgxP
--089e0102ee248bf9b104f3b2797f-- From nobody Mon Mar 3 10:45:16 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8C91A034F for ; Mon, 3 Mar 2014 10:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUs6SdOc4Gc1 for ; Mon, 3 Mar 2014 10:45:13 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F321A0342 for ; Mon, 3 Mar 2014 10:45:13 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s23Iiv9V008397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Mar 2014 12:44:59 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 3 Mar 2014 18:44:57 +0000 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/atJiKM97WGw1c5JdWj9y483E4tQ Subject: [xmpp] Meeting Slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:45:15 -0000 Hi, The slides for tomorrow's meeting are available at = http://www.ietf.org/proceedings/89/xmpp.html Thanks! Ben.= From nobody Mon Mar 3 12:55:26 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6161A009E for ; Mon, 3 Mar 2014 12:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzQmB6wc2SVm for ; Mon, 3 Mar 2014 12:55:24 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 57AB11A0057 for ; Mon, 3 Mar 2014 12:55:24 -0800 (PST) Received: from dhcp-a54d.meeting.ietf.org (unknown [31.133.165.77]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5629403C4; Mon, 3 Mar 2014 13:55:20 -0700 (MST) Message-ID: <5314EC38.6010606@stpeter.im> Date: Mon, 03 Mar 2014 20:55:20 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell , XMPP Working Group References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/IbNSwp0B27MjF9LILex4DWG2CkM Subject: Re: [xmpp] Meeting Slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 20:55:26 -0000 On 3/3/14, 6:44 PM, Ben Campbell wrote: > Hi, > > The slides for tomorrow's meeting are available at http://www.ietf.org/proceedings/89/xmpp.html Ben, I've made a slight update to the websocket slides (more information about implementation status is dribbling in)... https://stpeter.im/files/ietf89-xmpp-websocket.pdf Peter From nobody Tue Mar 4 00:54:48 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F841A0440 for ; Tue, 4 Mar 2014 00:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD5VuYDyumhK for ; Tue, 4 Mar 2014 00:54:44 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E601A0417 for ; Tue, 4 Mar 2014 00:54:44 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s248sbuC075467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 02:54:40 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <5314EC38.6010606@stpeter.im> Date: Tue, 4 Mar 2014 08:54:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3E26FDE4-8C38-48C4-BD70-D1A65C0ACD3D@nostrum.com> References: <5314EC38.6010606@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/aOrJwtRx4PdQr3pZUunjemXkaWU Cc: XMPP Working Group Subject: Re: [xmpp] Meeting Slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 08:54:46 -0000 Uploaded, thanks! On Mar 3, 2014, at 8:55 PM, Peter Saint-Andre = wrote: > On 3/3/14, 6:44 PM, Ben Campbell wrote: >> Hi, >>=20 >> The slides for tomorrow's meeting are available at = http://www.ietf.org/proceedings/89/xmpp.html >=20 > Ben, I've made a slight update to the websocket slides (more = information about implementation status is dribbling in)... >=20 > https://stpeter.im/files/ietf89-xmpp-websocket.pdf >=20 > Peter >=20 >=20 From nobody Tue Mar 4 00:55:54 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205541A041A for ; Tue, 4 Mar 2014 00:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVvLSE474zhQ for ; Tue, 4 Mar 2014 00:55:51 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6B1A0413 for ; Tue, 4 Mar 2014 00:55:50 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s248tjxk075567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2014 02:55:47 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Message-Id: <654CA6EB-54BB-473C-A5BF-5FAF7573C577@nostrum.com> Date: Tue, 4 Mar 2014 08:55:44 +0000 To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/55bKX54RsVdrnLjCBaTGreMDahY Subject: [xmpp] Revised Presentation X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 08:55:52 -0000 Hi, There's a revised version of the XMPP/WebSocket presentation in the = repository. If you downloaded it prior to receiving this message, please = grab it again. Thanks! Ben.= From nobody Tue Mar 4 01:04:52 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB111A0426 for ; Tue, 4 Mar 2014 01:04:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSslD_qGhmBm for ; Tue, 4 Mar 2014 01:04:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 562A71A03CD for ; Tue, 4 Mar 2014 01:04:50 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2494iaI076439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2014 03:04:46 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Message-Id: Date: Tue, 4 Mar 2014 09:04:43 +0000 To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/YX-4sRetHF6MH7EAo-6C1zkbTw8 Subject: [xmpp] Note Taker and Jabber Scribe X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 09:04:52 -0000 Hi, In the interest of an expeditious start to our meeting this afternoon, = the chairs are soliciting volunteers for the following: Note Takers -- capture issues, resolutions, decisions, and action items. = You can capture detailed discussion at your discretion. (We MUST have at = least one note taker to proceed, and SHOULD have two.) Jabber Scribe -- Relay speaker names, slide numbers, etc to the xmpp = room. Take any comments from online participants to the mike. (If we = can't find people to do this in the XMPP group, we should be sad :-) ) All volunteers will receive applause, praises from the chairs, and the = gratitude of everyone else in the room who you saved from being drafted. = (Be advised, the chairs will institute a draft if we do not have = sufficient volunteers :-) ) Thanks! Ben.= From nobody Tue Mar 4 03:05:39 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 080AF1A029F for ; Tue, 4 Mar 2014 03:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4fiO3XzfRIyh for ; Tue, 4 Mar 2014 03:05:35 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A91A0450 for ; Tue, 4 Mar 2014 03:05:34 -0800 (PST) Received: from dhcp-ab36.meeting.ietf.org (unknown [31.133.171.54]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13DC2403C4; Tue, 4 Mar 2014 04:05:30 -0700 (MST) Message-ID: <5315B379.2060600@stpeter.im> Date: Tue, 04 Mar 2014 11:05:29 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell References: <5314EC38.6010606@stpeter.im> <3E26FDE4-8C38-48C4-BD70-D1A65C0ACD3D@nostrum.com> In-Reply-To: <3E26FDE4-8C38-48C4-BD70-D1A65C0ACD3D@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/VOnPBsBP9qtPaP1uUstFgIEBmYE Cc: XMPP Working Group Subject: Re: [xmpp] Meeting Slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:05:37 -0000 Unfortunately I had updated my slides but hadn't actually uploaded the corrected PDF file to https://stpeter.im/files/ietf89-xmpp-websocket.pdf I have done that now. Sorry about the confusion. Peter On 3/4/14, 8:54 AM, Ben Campbell wrote: > Uploaded, thanks! > > On Mar 3, 2014, at 8:55 PM, Peter Saint-Andre wrote: > >> On 3/3/14, 6:44 PM, Ben Campbell wrote: >>> Hi, >>> >>> The slides for tomorrow's meeting are available at http://www.ietf.org/proceedings/89/xmpp.html >> >> Ben, I've made a slight update to the websocket slides (more information about implementation status is dribbling in)... >> >> https://stpeter.im/files/ietf89-xmpp-websocket.pdf >> >> Peter >> >> > From nobody Tue Mar 4 03:10:57 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A211A029F for ; Tue, 4 Mar 2014 03:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB17TyZnTs7f for ; Tue, 4 Mar 2014 03:10:54 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 634231A06A8 for ; Tue, 4 Mar 2014 03:10:54 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s24BAlHn093844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 05:10:49 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <5315B379.2060600@stpeter.im> Date: Tue, 4 Mar 2014 11:10:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5314EC38.6010606@stpeter.im> <3E26FDE4-8C38-48C4-BD70-D1A65C0ACD3D@nostrum.com> <5315B379.2060600@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/-vzn2g5SYt2KuK3xHzwWoMqxuPM Cc: XMPP Working Group Subject: Re: [xmpp] Meeting Slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:10:56 -0000 Uploaded again :-)=20 Please confirm that the version at = http://www.ietf.org/proceedings/89/xmpp.html is current and correct. Thanks! Ben. On Mar 4, 2014, at 11:05 AM, Peter Saint-Andre = wrote: > Unfortunately I had updated my slides but hadn't actually uploaded the = corrected PDF file to https://stpeter.im/files/ietf89-xmpp-websocket.pdf >=20 > I have done that now. >=20 > Sorry about the confusion. >=20 > Peter >=20 > On 3/4/14, 8:54 AM, Ben Campbell wrote: >> Uploaded, thanks! >>=20 >> On Mar 3, 2014, at 8:55 PM, Peter Saint-Andre = wrote: >>=20 >>> On 3/3/14, 6:44 PM, Ben Campbell wrote: >>>> Hi, >>>>=20 >>>> The slides for tomorrow's meeting are available at = http://www.ietf.org/proceedings/89/xmpp.html >>>=20 >>> Ben, I've made a slight update to the websocket slides (more = information about implementation status is dribbling in)... >>>=20 >>> https://stpeter.im/files/ietf89-xmpp-websocket.pdf >>>=20 >>> Peter >>>=20 >>>=20 >>=20 >=20 From nobody Tue Mar 4 03:12:21 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 832EF1A06DD for ; Tue, 4 Mar 2014 03:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrH47iXyAERH for ; Tue, 4 Mar 2014 03:12:18 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3D21A02F9 for ; Tue, 4 Mar 2014 03:12:18 -0800 (PST) Received: from dhcp-ab36.meeting.ietf.org (unknown [31.133.171.54]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B10B7403C4; Tue, 4 Mar 2014 04:12:14 -0700 (MST) Message-ID: <5315B50C.6000404@stpeter.im> Date: Tue, 04 Mar 2014 11:12:12 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell References: <5314EC38.6010606@stpeter.im> <3E26FDE4-8C38-48C4-BD70-D1A65C0ACD3D@nostrum.com> <5315B379.2060600@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ipn9lYbal2Ct1Cc-F153bEyBMfs Cc: XMPP Working Group Subject: Re: [xmpp] Meeting Slides X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:12:19 -0000 On 3/4/14, 11:10 AM, Ben Campbell wrote: > Uploaded again :-) > > Please confirm that the version at http://www.ietf.org/proceedings/89/xmpp.html is current and correct. Confirmed! From nobody Tue Mar 4 03:13:39 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B345A1A02F9 for ; Tue, 4 Mar 2014 03:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55iX8MZ8WFLt for ; Tue, 4 Mar 2014 03:13:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F491A029F for ; Tue, 4 Mar 2014 03:13:37 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s24BDVBW094074 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2014 05:13:33 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <654CA6EB-54BB-473C-A5BF-5FAF7573C577@nostrum.com> Date: Tue, 4 Mar 2014 11:13:30 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <55D05C45-59D0-471F-A8CD-DFA26405B831@nostrum.com> References: <654CA6EB-54BB-473C-A5BF-5FAF7573C577@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/nZLA31_Wz6M32YFud7NjniSclFE Subject: Re: [xmpp] Revised Presentation X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:13:39 -0000 One more time ;-)=20 If you downloaded it prior to this email, please re-download. Thanks! Ben. On Mar 4, 2014, at 8:55 AM, Ben Campbell wrote: > Hi, >=20 > There's a revised version of the XMPP/WebSocket presentation in the = repository. If you downloaded it prior to receiving this message, please = grab it again. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Tue Mar 4 03:19:05 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5E71A06EC for ; Tue, 4 Mar 2014 03:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqxwCRMJhFqr for ; Tue, 4 Mar 2014 03:18:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A501A02CE for ; Tue, 4 Mar 2014 03:18:49 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s24BIh19094522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2014 05:18:45 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: Date: Tue, 4 Mar 2014 11:18:43 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <352BED7E-67B4-4668-AFAB-B815334F4840@nostrum.com> References: To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/EFxOssxDy9NmCyyYUDTfagG6yYM Subject: Re: [xmpp] Note Taker and Jabber Scribe X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:18:57 -0000 Olle has agreed to xmpp scribe. Yay Olle! We're still looking for note takers. There's still glory there for the = taking :-) Thanks! Ben. On Mar 4, 2014, at 9:04 AM, Ben Campbell wrote: > Hi, >=20 > In the interest of an expeditious start to our meeting this afternoon, = the chairs are soliciting volunteers for the following: >=20 > Note Takers -- capture issues, resolutions, decisions, and action = items. You can capture detailed discussion at your discretion. (We MUST = have at least one note taker to proceed, and SHOULD have two.) >=20 > Jabber Scribe -- Relay speaker names, slide numbers, etc to the xmpp = room. Take any comments from online participants to the mike. (If we = can't find people to do this in the XMPP group, we should be sad :-) ) >=20 > All volunteers will receive applause, praises from the chairs, and the = gratitude of everyone else in the room who you saved from being drafted. = (Be advised, the chairs will institute a draft if we do not have = sufficient volunteers :-) ) >=20 > Thanks! >=20 > Ben. > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Tue Mar 4 07:31:45 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4B61A0134 for ; Tue, 4 Mar 2014 07:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3HlIPTxTh7t for ; Tue, 4 Mar 2014 07:31:26 -0800 (PST) Received: from server209.appriver.com (server209e.appriver.com [8.31.233.120]) by ietfa.amsl.com (Postfix) with ESMTP id CC9BA1A0085 for ; Tue, 4 Mar 2014 07:31:25 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/4/2014 10:31:22 AM X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-90/SG:2 3/4/2014 10:31:15 AM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.886315 p=-0.983444 Source White X-Signature-Violations: 0-0-0-2561-c X-Note-419: 15.6003 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/4/2014 10:31:18 AM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.8) with ESMTPS id 77109719 for xmpp@ietf.org; Tue, 04 Mar 2014 10:31:21 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 4 Mar 2014 09:31:21 -0600 From: Jonathan Lennox To: "xmpp@ietf.org" Thread-Topic: See-other-uri and insecure web sockets Thread-Index: AQHPN77LcHY6vVtde0udKwxOfVd74A== Date: Tue, 4 Mar 2014 15:31:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.226] Content-Type: text/plain; charset="Windows-1252" Content-ID: <072AADE4CEFC0A4FAF55D4B4CDE77544@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/tR-O2jDTkH9WjDCqLjaijR42tRQ Subject: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:31:34 -0000 As requested =97 I reviewed the text forbidding see-other-uri downgrading i= n the current version of draft-ietf-xmpp-websocket, and I=92m happy with it= . What I was responding to at the mic was a comment that StPeter made during = his presentation, suggesting that in addition, a future version of the draf= t would recommend that see-other-uri received over an insecure (ws or http)= connection should be ignored. I think this is a bad idea =97 I don=92t see any reason why see-other-uri s= hould be any less trusted than anything else received over an insecure conn= ection. And indeed, I think that most servers (if they have a ws listener = at all) would want to respond to insecure XMPP connections by sending a see= -other-uri pointing at their wss uri!= From nobody Tue Mar 4 07:37:47 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA191A007D for ; Tue, 4 Mar 2014 06:29:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySDBd1WUY_Di for ; Tue, 4 Mar 2014 06:29:48 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFC41A019E for ; Tue, 4 Mar 2014 06:29:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: xmpp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140304142946.19089.13960.idtracker@ietfa.amsl.com> Date: Tue, 04 Mar 2014 06:29:46 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/oIl9k_ml27m477U_6Z8AaKkSITY X-Mailman-Approved-At: Tue, 04 Mar 2014 07:37:39 -0800 Subject: [xmpp] Milestones changed for xmpp WG X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:29:49 -0000 Changed milestone "Define a solution for internationalization of XMPP addresses (Update of RFC 6122)", set due date to June 2014 from September 2012. Changed milestone "Define a solution for server-to-server connection reuse.", set due date to July 2014 from March 2012. Changed milestone "Define a solution for end-to-end encryption.", set due date to January 2015 from August 2012. URL: http://datatracker.ietf.org/wg/xmpp/charter/ From nobody Tue Mar 4 08:19:17 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E495F1A021C for ; Tue, 4 Mar 2014 08:19:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQUVCVNuYjik for ; Tue, 4 Mar 2014 08:19:14 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49ADF1A01C5 for ; Tue, 4 Mar 2014 08:19:14 -0800 (PST) Received: from [10.0.1.2] ([130.129.111.162]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s24GJ6g8052031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 4 Mar 2014 10:19:10 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [130.129.111.162] claimed to be [10.0.1.2] From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Message-Id: Date: Tue, 4 Mar 2014 16:19:05 +0000 To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/qRUGeUxKo4hmnARHxM_iB4C5qLc Subject: [xmpp] Chair Slides Updated X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:19:16 -0000 Hi, There's now an updated version of today's chair slides in the = repository. It fixes the IETF meeting number and the date and time. = There are no other changes. Thanks! Ben.= From nobody Tue Mar 4 08:44:42 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7AA21A01CD for ; Tue, 4 Mar 2014 08:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TdVPnJg_Cod for ; Tue, 4 Mar 2014 08:44:32 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0BA1A0191 for ; Tue, 4 Mar 2014 08:44:32 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id a1so5211254wgh.34 for ; Tue, 04 Mar 2014 08:44:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=D/8mIAxzn2OUwo6I5WA9Wll0qCdiXfWBwH4+ol7HpfQ=; b=dmrD7D4R2O2RGmRgfJ9NgyzYqAwROF3HZus21JRZKgmCDRcSH9aiDNwTQ1pFf9rsBa 5iOyXtiQ/O4sfgx4sR1AbMo18N+/smbY/48RLfwJa3Xvv2aSAOwYcg1mK95VDiPsztyk i3ebh2FIEzEomUWGpVEnjg/25g+QUm/abJgbc6/VtGoXoNoHOOit0aoBxTfb/FePiahs 49PoMSqAu7x8TzYUNIV732JM/AS8E0+fSGLvQtJLDc9kx+VeAhylyUF0JC3f3dnFGUyy +7JneUo+wNRFkhChVaiLoUR5DUlWux56dHfHysQeO22MjPBgMUwTTgYh/Z/EkMAAoUyc /4mQ== MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr769396wjd.3.1393951468431; Tue, 04 Mar 2014 08:44:28 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.217.96.196 with HTTP; Tue, 4 Mar 2014 08:44:28 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Mar 2014 16:44:28 +0000 X-Google-Sender-Auth: UJbWaFnXXXjQWtlv_NrPAIHtAoc Message-ID: From: Kevin Smith To: Jonathan Lennox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/SX0CWOBDRGBOgcgFgPMC5QzgInU Cc: "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:44:38 -0000 On Tue, Mar 4, 2014 at 3:31 PM, Jonathan Lennox wrote: > As requested -- I reviewed the text forbidding see-other-uri downgrading = in the current version of draft-ietf-xmpp-websocket, and I'm happy with it. > > What I was responding to at the mic was a comment that StPeter made durin= g his presentation, suggesting that in addition, a future version of the dr= aft would recommend that see-other-uri received over an insecure (ws or htt= p) connection should be ignored. It feels to me like there are potentially auth mechanism downgrade attacks associated here, if people were to do the Wrong Thing. So I think at least a note is worthwhile. The document does, though, tell everyone to do wss, so this is arguably not an issue. > > I think this is a bad idea -- I don't see any reason why see-other-uri sh= ould be any less trusted than anything else received over an insecure conne= ction. And indeed, I think that most servers (if they have a ws listener a= t all) would want to respond to insecure XMPP connections by sending a see-= other-uri pointing at their wss uri! I think this scenario is somewhat unlikely - in this case the discovery would have pointed to was (either hard-coded or over 156 or whatever). /K From nobody Tue Mar 4 10:02:46 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96491A02C6 for ; Tue, 4 Mar 2014 10:02:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Dl-4qLCnlQ for ; Tue, 4 Mar 2014 10:02:38 -0800 (PST) Received: from server209.appriver.com (server209f.appriver.com [8.31.233.121]) by ietfa.amsl.com (Postfix) with ESMTP id 952171A02C4 for ; Tue, 4 Mar 2014 10:02:38 -0800 (PST) X-Note-AR-ScanTimeLocal: 3/4/2014 1:02:32 PM X-Policy: GLOBAL - vidyo.com X-Policy: GLOBAL - vidyo.com X-Primary: jonathan@vidyo.com X-Note: This Email was scanned by AppRiver SecureTide X-Virus-Scan: V- X-Note-SnifferID: 0 X-Note: TCH-CT/SI:0-64/SG:2 3/4/2014 1:02:22 PM X-GBUdb-Analysis: 0, 162.209.16.213, Ugly c=0.934231 p=-0.986365 Source White X-Signature-Violations: 0-0-0-2938-c X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total X-Note: SCH-CT/SI:0-1345/SG:1 3/4/2014 1:02:26 PM X-Note: Spam Tests Failed: X-Country-Path: ->UNITED STATES->LOCAL X-Note-Sending-IP: 162.209.16.213 X-Note-Reverse-DNS: mail1.vidyo.com X-Note-Return-Path: jonathan@vidyo.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID X-Note: Headers Injected Received: from [162.209.16.213] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 103037478; Tue, 04 Mar 2014 13:02:32 -0500 Received: from 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62]) by 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77%13]) with mapi id 14.03.0146.000; Tue, 4 Mar 2014 12:02:31 -0600 From: Jonathan Lennox To: "kevin@kismith.co.uk" Thread-Topic: [xmpp] See-other-uri and insecure web sockets Thread-Index: AQHPN77LcHY6vVtde0udKwxOfVd74JrRhxsAgAAVyoA= Date: Tue, 4 Mar 2014 18:02:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.187.226] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3431059EB382C34090BC0B0E37802FC1@vidyo.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/6gYi31EEzUycHMapH-1ppJUf4cI Cc: "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:02:41 -0000 On Mar 4, 2014, at 4:44 PM, Kevin Smith wrote: >> I think this is a bad idea -- I don't see any reason why see-other-uri s= hould be any less trusted than anything else received over an insecure conn= ection. And indeed, I think that most servers (if they have a ws listener = at all) would want to respond to insecure XMPP connections by sending a see= -other-uri pointing at their wss uri! >=20 > I think this scenario is somewhat unlikely - in this case the > discovery would have pointed to was (either hard-coded or over 156 or > whatever). Well, you need to do *something* if someone tries to connect to , but I guess responding with 301 or 404 to th= e HTTP handshake, prior to protocol handover, would be better than switchin= g to xmpp and then using see-other-uri. From stefan@strigler.de Tue Mar 4 09:34:41 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B7C1A0240 for ; Tue, 4 Mar 2014 09:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, 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 efqCspfYoQM3 for ; Tue, 4 Mar 2014 09:34:39 -0800 (PST) Received: from mail.strigler.de (jwchat.org [188.40.80.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF431A01FE for ; Tue, 4 Mar 2014 09:34:37 -0800 (PST) Received: (qmail 29372 invoked from network); 4 Mar 2014 17:34:33 -0000 Received: from unknown (HELO ?10.153.1.55?) (stefan@strigler.de@127.0.0.1) by 0 with ESMTPA; 4 Mar 2014 17:34:33 -0000 From: Stefan Strigler Content-Type: multipart/signed; boundary="Apple-Mail=_8D0B4261-A41E-43F6-82C0-096BEFC116E9"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Tue, 4 Mar 2014 18:34:32 +0100 References: <530D1EDA.2030509@stpeter.im> To: xmpp@ietf.org Message-Id: <236C2BC5-71DE-4F37-9841-97F8881766B7@strigler.de> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ZeoENWNO-tXFIBVqmmr47MWHXt0 X-Mailman-Approved-At: Tue, 04 Mar 2014 10:07:17 -0800 Subject: [xmpp] Fwd: JSJac + WebSocket X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:37:27 -0000 --Apple-Mail=_8D0B4261-A41E-43F6-82C0-096BEFC116E9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 =46rom my perspective to updated draft looks very good and promising. = JSJaC (and MongooseIM) will be updated soon to reflect the changes. Greets, Stefan=20 Begin forwarded message: > From: Peter Saint-Andre > Subject: JSJac + WebSocket > Date: 25. Februar 2014 23:53:14 MEZ > To: Stefan Strigler > Cc: "lance@andyet.net" >=20 > Hallo Stefan, Lance reports that Prosody and a few client libraries = have been updated to reflect the WebSocket consensus: >=20 > = http://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/?include_text=3D= 1 >=20 > Do you have a sense of when you might be able to update JSJaC? And it = would be great if you could post to the xmpp@ietf.org list to say "the = latest version looks good" so that we can show consensus. :-) >=20 > Thanks! >=20 > Peter >=20 --Apple-Mail=_8D0B4261-A41E-43F6-82C0-096BEFC116E9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITHjCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGPzCCBSeg AwIBAgIDCNY8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTQwMTMxMTkzOTE5WhcNMTUwMjAxMTUxODM5WjBbMRkwFwYDVQQNExBzbEczVDREMXp2aVZYSjc1 MRswGQYDVQQDDBJzdGVmYW5Ac3RyaWdsZXIuZGUxITAfBgkqhkiG9w0BCQEWEnN0ZWZhbkBzdHJp Z2xlci5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMmE5oYn5B+m3JE2UCNExjH3 tE5hcJGFnSx8+fF/Jdv6r4K5awiBSeWLJBy5AhMKmvKKeqrKEqzI8gO4W+GIdm6zAKbE1pjb+v9q AfFRUP3r/JhbKMVvXFdrZwGsatZY/66paM3G7F8/j4JA9kzGwv0WI94ynPOTV2atVnj3V9hKlg1W GFli+eIlgzn5FmYwMddE050uu+9ViwEWGizRxFHkNdOKQe2YeigAv0AUCRTPPuMg7DMJrQi2HVI0 ZcQmKI1PlkPvqm/fOK+vA7itrR3XX/Cz405jRVk2T9lYN2/nKBf7i5A5GC9/xkFffaYtiZRY5IST 6NOs+Y3MM5FRBMMCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUgLea5uWbSoWS6QsLbVGcSbZdGkEwHwYD VR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESc3RlZmFuQHN0cmlnbGVy LmRlMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASowLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBp c3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9m IHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBw dXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYG A1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4G CCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIv Y2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2Vy dHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAZ2IhnDlZnE+udFK0Rw/fYlWkQkFGOAmjL35qoV1X 88wWKYrQIrG7wuO4dwkNOKl6w/vyoXL4eUV0T/WmqPFsWLBHJVKLTKKgKciyV7cSH7ut/wikwc2v uYajNB5uFDVxsTeddm1w5UUboBycfbfcjjt5h8XtCFwb/wvnXhQ6uF8YOeqodE28aRyi1TqWjPnn 12LX9vIAagjPrsgl6Ll8tmZwmb8ZfM+AFCudKunlDAyVmbn49pnSXx9FKdu4Qra45pw8kPtkGHIG EJv8FhWWivCCnKhp/gaxUSnFK+p8MTYEE17kscd3Bjly0J1fPYutzRLy5gdYANAsy8A5qF7zdDCC Bp8wggSHoAMCAQICAT0wDQYJKoZIhvcNAQELBQAwUzELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xLDAqBgNVBAMTI1N0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcy MB4XDTA2MDkxNzE5NDYzN1oXDTM2MDkxNzE5NDYzN1owfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25p bmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG 9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTM jjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZZ7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TS hYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2 XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqouaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1 ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+n WFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHsDOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+EN cPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0a ErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2 +K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8novgdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYr moYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAVIwggFOMBIGA1UdEwEB/wQIMAYBAf8CAQIwDgYD VR0PAQH/BAQDAgEGMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD0EGu8jAfBgNVHSMEGDAWgBRL xbRAa60cs6UcZW5GNomHBQwOtjBvBggrBgEFBQcBAQRjMGEwKgYIKwYBBQUHMAGGHmh0dHA6Ly9v Y3NwLnN0YXJ0c3NsLmNvbS9jYS1nMjAzBggrBgEFBQcwAoYnaHR0cDovL2FpYS5zdGFydHNzbC5j b20vY2VydHMvY2EtZzIuY2VyMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL2NhLWcyLmNybDBDBgNVHSAEPDA6MDgGBFUdIAAwMDAuBggrBgEFBQcCARYiaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjANBgkqhkiG9w0BAQsFAAOCAgEAM55Ty65ULAKJsJVW BoK0R3lwl0gPCtBNN2tVXwhPLoYEWYO3CtzdqBKIwTKHi+FaiznrqnHd8/sUqvObsZ8z3PnAAW4k W+ILskLyv3as1o45g3BGFZNKMwqlogZPnnOFuB5oMpEB3b4WPvM4CUgkHX6hpIQFHNf1P4hOYwCL 3NzO+5xXieiiHt1WpxAQ7LRc5UISUqPKUs4S/KRGAVqbnR2p2xaIGQycBvhguqRPD0pyBAB5iyl8 KEXkq+saB6VA6zHcAobYdNIEWAs+OQDq5E8pSKyJfBJc8127YwawhTCiHLZnMVxNLFXNmE/TgglC /pu/yyjzXV6KRm3vA1i+h5hVMBi8HbfLeVs11UsUt8QAOxegzM9OcDU+vCX3X/AZSckNx0Yk7/09 tAWzUqklbDlrKSMrmj4S0df0r9puD3qweZSWAOv1P3hWdaLfIHud1ziKD3w/fSxvUnneJxfNtqP3 R0lwGfF/qKLaAV+bYgPvYXxqn1fybrGHL/oXO0qkXc2E23LOrIvhIUbNYSli4rnzaEDBz/pXKKTl JbdyKf6elg2TSTiauOi4LwxY+3EP1kpDLswOX6ejT740J1ZqI41E7GnaUTeIW52o6zu64yYTiQTd 5HHeNc2u2UPZYeNvcvMuU2yVmCeBG5R+K4kFShEIMoOJqpgjpZcjGEuwhhkxggNvMIIDawIBATCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMI1jwwCQYFKw4DAhoFAKCCAa8wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzA0MTczNDMyWjAjBgkqhkiG 9w0BCQQxFgQUkGG4IkH/Vf2wVsx4UGgv4rnoFDkwgaUGCSsGAQQBgjcQBDGBlzCBlDCBjDELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMI1jwwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAwjWPDANBgkqhkiG9w0BAQEFAASCAQB9kmj/Gy9yn52//9QH vcBB8WZI/4v0Od3fy1S1z7LHymiBTpk836ITrtEBDXboPy2uvrivq7gmP1Ml2thh1HUufPyLocJD x+Vk2DDU9dpd4winIazWIbKINiu6W4XvUARIZ4K1kCHLuEsMv0NF3NnHCNyi+wGodJivAqdXE+Hf /At23oDzZAyecsxtJ5mnM2yKlz8G1mEk75gHzWMlFKi2CWN/18K1lkR4oWZk+HXPBpxTh2kebgac 13sa2I1mxbvHUxkbBI1e5Ymdf3iUVQAuA5VGljO6LodHAgM85lEW46+3N2f8uFHmHtnqOZOhnLFt ujXQEaSRseca/PjOEcvXAAAAAAAA --Apple-Mail=_8D0B4261-A41E-43F6-82C0-096BEFC116E9-- From nobody Tue Mar 4 10:10:28 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC931A0232 for ; Tue, 4 Mar 2014 10:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4ai_cPpUgdx for ; Tue, 4 Mar 2014 10:10:22 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 53DBF1A0187 for ; Tue, 4 Mar 2014 10:10:22 -0800 (PST) Received: from dhcp-ab36.meeting.ietf.org (unknown [31.133.171.54]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E145403C4; Tue, 4 Mar 2014 11:10:18 -0700 (MST) Message-ID: <53161709.1070908@stpeter.im> Date: Tue, 04 Mar 2014 18:10:17 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <530D1EDA.2030509@stpeter.im> <236C2BC5-71DE-4F37-9841-97F8881766B7@strigler.de> In-Reply-To: <236C2BC5-71DE-4F37-9841-97F8881766B7@strigler.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/jPwv8oBNBQS64z74Uqbnvom_3C4 Subject: Re: [xmpp] Fwd: JSJac + WebSocket X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:10:25 -0000 On 3/4/14, 5:34 PM, Stefan Strigler wrote: > From my perspective to updated draft looks very good and promising. > JSJaC (and MongooseIM) will be updated soon to reflect the changes. Hi Stefan, thanks for letting us know! Peter From nobody Tue Mar 4 17:42:57 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9111A0107 for ; Tue, 4 Mar 2014 17:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7yhTY1Io--g for ; Tue, 4 Mar 2014 17:42:52 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A52841A00FD for ; Tue, 4 Mar 2014 17:42:52 -0800 (PST) Received: from aither.local (unknown [86.176.103.76]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8A699403C4; Tue, 4 Mar 2014 18:42:48 -0700 (MST) Message-ID: <53168116.7080107@stpeter.im> Date: Wed, 05 Mar 2014 01:42:46 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Jonathan Lennox , "kevin@kismith.co.uk" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/kGjeQxE9NMaAk-i-iM_97jdkvBs Cc: "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 01:42:54 -0000 On 3/4/14, 6:02 PM, Jonathan Lennox wrote: > > On Mar 4, 2014, at 4:44 PM, Kevin Smith wrote: > >>> I think this is a bad idea -- I don't see any reason why see-other-uri should be any less trusted than anything else received over an insecure connection. And indeed, I think that most servers (if they have a ws listener at all) would want to respond to insecure XMPP connections by sending a see-other-uri pointing at their wss uri! >> >> I think this scenario is somewhat unlikely - in this case the >> discovery would have pointed to was (either hard-coded or over 156 or >> whatever). > > Well, you need to do *something* if someone tries to connect to , but I guess responding with 301 or 404 to the HTTP handshake, prior to protocol handover, would be better than switching to xmpp and then using see-other-uri. Yes, I think that's the better approach - the earlier the better. Peter From nobody Tue Mar 4 17:43:36 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 468101A0107 for ; Tue, 4 Mar 2014 17:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S2JjwFlSRY73 for ; Tue, 4 Mar 2014 17:43:32 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DE3C71A00FD for ; Tue, 4 Mar 2014 17:43:31 -0800 (PST) Received: from aither.local (unknown [86.176.103.76]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0AD7F403C4; Tue, 4 Mar 2014 18:43:27 -0700 (MST) Message-ID: <5316813E.3020901@stpeter.im> Date: Wed, 05 Mar 2014 01:43:26 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: kevin@kismith.co.uk, Jonathan Lennox References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/D-RVsXjbUoLA5CwTMY9p3NQdzNo Cc: "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 01:43:33 -0000 On 3/4/14, 4:44 PM, Kevin Smith wrote: > On Tue, Mar 4, 2014 at 3:31 PM, Jonathan Lennox wrote: >> As requested -- I reviewed the text forbidding see-other-uri downgrading in the current version of draft-ietf-xmpp-websocket, and I'm happy with it. >> >> What I was responding to at the mic was a comment that StPeter made during his presentation, suggesting that in addition, a future version of the draft would recommend that see-other-uri received over an insecure (ws or http) connection should be ignored. > > It feels to me like there are potentially auth mechanism downgrade > attacks associated here, if people were to do the Wrong Thing. So I > think at least a note is worthwhile. > > The document does, though, tell everyone to do wss, so this is > arguably not an issue. Personally I see no harm in a bit of text that reinforces the point. Peter From nobody Wed Mar 5 01:34:08 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716441A000D for ; Wed, 5 Mar 2014 01:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAG2qpBszoNM for ; Wed, 5 Mar 2014 01:34:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2ED1A00F2 for ; Wed, 5 Mar 2014 01:30:14 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s259TtLH090836 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 03:29:58 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <53168116.7080107@stpeter.im> Date: Wed, 5 Mar 2014 09:29:55 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <999EB1E4-DC95-4343-AD1C-6606447755D2@nostrum.com> References: <53168116.7080107@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/oPifSPWP7YYkU8J1Rn_L9KhniqE Cc: Jonathan Lennox , "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:34:06 -0000 On Mar 5, 2014, at 1:42 AM, Peter Saint-Andre = wrote: >>=20 >> Well, you need to do *something* if someone tries to connect to = , but I guess responding with = 301 or 404 to the HTTP handshake, prior to protocol handover, would be = better than switching to xmpp and then using see-other-uri. >=20 > Yes, I think that's the better approach - the earlier the better. Does that mean we don't need see-other-uri at all?= From nobody Wed Mar 5 01:39:57 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3EB1A000D for ; Wed, 5 Mar 2014 01:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKjTgSW-R1we for ; Wed, 5 Mar 2014 01:39:51 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6851A01C2 for ; Wed, 5 Mar 2014 01:39:51 -0800 (PST) Received: from dhcp-ab36.meeting.ietf.org (unknown [31.133.171.54]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EE62F403AE; Wed, 5 Mar 2014 02:39:46 -0700 (MST) Message-ID: <5316F0E1.1030109@stpeter.im> Date: Wed, 05 Mar 2014 09:39:45 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell References: <53168116.7080107@stpeter.im> <999EB1E4-DC95-4343-AD1C-6606447755D2@nostrum.com> In-Reply-To: <999EB1E4-DC95-4343-AD1C-6606447755D2@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/d40JC_woXa41RaFrY--LlZwFXfQ Cc: Jonathan Lennox , "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 09:39:54 -0000 On 3/5/14, 9:29 AM, Ben Campbell wrote: > > On Mar 5, 2014, at 1:42 AM, Peter Saint-Andre wrote: > >>> >>> Well, you need to do *something* if someone tries to connect to , but I guess responding with 301 or 404 to the HTTP handshake, prior to protocol handover, would be better than switching to xmpp and then using see-other-uri. >> >> Yes, I think that's the better approach - the earlier the better. > > Does that mean we don't need see-other-uri at all? No, it means that if the client tries to go to an http or ws URI, it is best for the service to redirect to an https or wss URI using standard HTTP methods, not XMPP methods. We still need the see-other-uri for more advanced scenarios in the XMPP context - typically, telling the client about an alternative or fallback WebSocket endpoint, just like see-other-host from RFC 6120 but for WebSocket endpoints instead of TCP endpoints. Peter From nobody Wed Mar 5 02:36:26 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F541A03BB for ; Wed, 5 Mar 2014 02:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUcLx7tVO69j for ; Wed, 5 Mar 2014 02:36:22 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 339661A0391 for ; Wed, 5 Mar 2014 02:36:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1632; q=dns/txt; s=iport; t=1394015779; x=1395225379; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=m4emK564q1hGW5pi3AkjNwmbx+0r5atAywwkGPAMK6U=; b=ZBvGe+usZLEvCEPTo4WaVYqZx15CE8GwgGtTJyIEOhwJfGXLl05olgPY LtHB0WIO7BjjqIjFpGGw4pgNQydTtMHf+ui441ohdg+crd1he+tzEx/fV G84U7YYwILZGS8VrOZMzCLMLa9ax0DLIomDNSSh3tPb+j3J8rrPd5sc4S E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAB39FlOtJXG8/2dsb2JhbABagwY7V8ELgRkWdIIlAQEBBAEBAWsKARALGAkWDwkDAgECARUwBgEMAQUCAQGHdQ3NWheOHjMHhDgBA4kTjyqSK4Mtgio X-IronPort-AV: E=Sophos;i="4.97,592,1389744000"; d="scan'208";a="25050229" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-2.cisco.com with ESMTP; 05 Mar 2014 10:36:18 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s25AaIkH032085 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 10:36:18 GMT Received: from MAMILLE2-M-T03K.local (10.86.252.75) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Mar 2014 04:36:17 -0600 Message-ID: <5316FE1E.9060803@cisco.com> Date: Wed, 5 Mar 2014 10:36:14 +0000 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Ben Campbell , Peter Saint-Andre References: <53168116.7080107@stpeter.im> <999EB1E4-DC95-4343-AD1C-6606447755D2@nostrum.com> In-Reply-To: <999EB1E4-DC95-4343-AD1C-6606447755D2@nostrum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.86.252.75] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/xvh3PaHrtQdRpNlZj-Dp-pTpMKo Cc: Jonathan Lennox , "xmpp@ietf.org" Subject: Re: [xmpp] See-other-uri and insecure web sockets X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 10:36:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/5/14, 9:29 AM, Ben Campbell wrote: > > On Mar 5, 2014, at 1:42 AM, Peter Saint-Andre > wrote: > >>> >>> Well, you need to do *something* if someone tries to connect to >>> , but I guess >>> responding with 301 or 404 to the HTTP handshake, prior to >>> protocol handover, would be better than switching to xmpp and >>> then using see-other-uri. >> >> Yes, I think that's the better approach - the earlier the >> better. > > Does that mean we don't need see-other-uri at all? > _______________________________________________ xmpp mailing list > xmpp@ietf.org https://www.ietf.org/mailman/listinfo/xmpp > There are (and will be) cases where a redirect cannot be done until after the XMPP-over-Websocket handshake is started (well after an HTTP redirect is possible). We still need this. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTFv4eAAoJEDWi+S0W7cO16GIIAIFnyroLUbZpRIq5oi+hFwHZ 2NSMTIksa+PIHl8DXcTb0dVsBeKTUpUN9vHMu3U3iO5yDAP9we4M1uKbsXZE6RoD 8w51z0AMrcKueYL9XvtC+sMm1eJVauQid4Vy7JxqgFzq5eTgLy5dsj1nCzssKjVQ wHZnXGAvaZwGI4W3010RZ7SVEbLBzLwkIPGslZTnzLCX462yJbl+4gvr9UOx7GKG /R/E/zb53vBkQIkmiUMh7CgfBcmi0QCd1p0hzF+dnozUYp0zHJpYyOH0LiiJn0DI F1/NU0vE1uQ5GN7NZWNauMoiOIOlvqwcRDqAMswH0uUgmYiSMT/6YESpDROTOJ4= =NMXg -----END PGP SIGNATURE----- From nobody Thu Mar 6 06:20:08 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567011A039A for ; Thu, 6 Mar 2014 06:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RIQ3lMnD6en for ; Thu, 6 Mar 2014 06:20:05 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 131721A03C4 for ; Thu, 6 Mar 2014 06:19:40 -0800 (PST) Received: from dhcp-ab36.meeting.ietf.org (unknown [31.133.171.54]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AD7DC40460; Thu, 6 Mar 2014 07:19:35 -0700 (MST) Message-ID: <531883F5.7000800@stpeter.im> Date: Thu, 06 Mar 2014 14:19:33 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/pJwBnaCTGB69EirhJgRNtfsutBU Subject: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:20:06 -0000 In the SAAG session just now, Daniel Kahn Gillmor just brought up an interesting issue about end-to-end message encryption in XMPP, and Matt Miller had an interesting reply. If we wanted to randomly change around the size of XMPP messages pre-encryption, we could easily add an XMPP extension to the payload and make the XML character data whatever size we please. Peter From nobody Thu Mar 6 06:28:34 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D661A03E3 for ; Thu, 6 Mar 2014 06:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYe-4TrP1eG0 for ; Thu, 6 Mar 2014 06:28:30 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id C99C51A03DB for ; Thu, 6 Mar 2014 06:28:30 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id wp18so2619770obc.35 for ; Thu, 06 Mar 2014 06:28:26 -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=ufZQaFozTBmpJFHgOixOanUcIiEVIb4i3aSWFfGSbDM=; b=hDOON4G+KYvrN9GSqUfm9VA1cunBjJ6rS1+JqeFkYoWRwV9eUV+G6Yh8pIBzvKG6Sy XhOthA/Er7QE6iQTB0xbN7fnKw9iT6Gd9PmgBGZK9gSj3j6NlVy3yE12l8sezDtNIWgR Gugb1Op/xGLRg1rNsOz6AdDgFSurPV3rYOzWA= 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=ufZQaFozTBmpJFHgOixOanUcIiEVIb4i3aSWFfGSbDM=; b=FvSn5fcmAeDKPyqBVYszoDdNhsrzRBVYgKLp/vVRqD/gcYWZv5A1gK2RyiksuyQWYS 2HRgUcTucz2udLVzLoa/Ii+a8o6bzYLyvDrrTIzzOMb0+oACBlT8b+L1t+9RQhSrd0I4 +Vyf53hUBBYEQp2OGUb16HWwdC7sWn8SGPU9rEty+XsBv7nAtfvo/DMJsnZv3stG0bxC FFAmpoacVjed4y+bBEaEF4zCwZ08W1dexg9yCaOIzZZcs9sYfhnHTz5F24GuEVayD8Mh uH3FIsKk7ft1s8TFe2jYowSHvEcAzK4d3gJnk/edZXd3hTBOC6+yFORVyBh1zIkgaGsW vATg== X-Gm-Message-State: ALoCoQlScDKqQbh88b0N9ZR1a4KQrU0eTVUxlcdQZDYNbqkNtoreyrfLkAkebY9in/jdL6eFrbQW MIME-Version: 1.0 X-Received: by 10.60.44.135 with SMTP id e7mr1489934oem.63.1394116106841; Thu, 06 Mar 2014 06:28:26 -0800 (PST) Received: by 10.60.58.41 with HTTP; Thu, 6 Mar 2014 06:28:26 -0800 (PST) In-Reply-To: <531883F5.7000800@stpeter.im> References: <531883F5.7000800@stpeter.im> Date: Thu, 6 Mar 2014 14:28:26 +0000 Message-ID: From: Dave Cridland To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001a11333b205313da04f3f0f376 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/pB113_80Xt9IvsAQv-HSbpRz1BM Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:28:31 -0000 --001a11333b205313da04f3f0f376 Content-Type: text/plain; charset=ISO-8859-1 You're saying to include, pre-encrypt, something like 123465 in the plaintext order to defeat message size analysis of the ciphertext? --001a11333b205313da04f3f0f376 Content-Type: text/html; charset=ISO-8859-1
You're saying to include, pre-encrypt, something like <spacer:junk xmlns:spacer='urn:...'>123465</spacer> in the plaintext order to defeat message size analysis of the ciphertext?
--001a11333b205313da04f3f0f376-- From nobody Thu Mar 6 06:35:43 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9831A0140 for ; Thu, 6 Mar 2014 06:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlUMcutUnoBi for ; Thu, 6 Mar 2014 06:35:40 -0800 (PST) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id ACF721A0137 for ; Thu, 6 Mar 2014 06:35:39 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id k14so3235869wgh.35 for ; Thu, 06 Mar 2014 06:35:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=HlwHsp5pE70Bo7daC+pNzxj6Mxe8lTJd//x59OOw+oM=; b=Z7dourzti9oUbKy3KTm0FAWESGmO1E6pnKkjKS5zfIXaH0uoTQpQLJ5LUxObsNLZwA E9Bbw4HMYViEsDmK6ds0+Ka5N+UL+FdFWt7EkDhAI6u3RR+eyrv3XWoV8XarrgdeOXpU U7oCDrsbHkDcEcNosRpo0zxh2tQOfUqP40YWIBYXBiWXYUM6FbRigGq9iBpaSaOObyOR TL6qnJWtIJ4i7e8SLtRWKq+aXu3CepuQuoE62ymKiJ9g4giH3bcn1NDEYl/cHJQgkCQM AxdR/J6xdQT+bh/LRIZRPSBJnf1MA1vcZQRldYf33sJp3YWCm7KlBedFcpL5msW9IssM Cnww== X-Gm-Message-State: ALoCoQnV/9Q3KA4d009BQoRKkejm3tOH/KxERT8AmY4FIe2CCYnkO2yXwC3QIs4H2xYUbuTNarV2 X-Received: by 10.194.92.164 with SMTP id cn4mr10825951wjb.74.1394116535372; Thu, 06 Mar 2014 06:35:35 -0800 (PST) Received: from [192.168.1.87] (host81-155-184-37.range81-155.btcentralplus.com. [81.155.184.37]) by mx.google.com with ESMTPSA id f7sm17809338wjb.7.2014.03.06.06.35.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 06:35:33 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_D07EBC21-F23B-4A42-BEA7-081D2D0A17F1"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ashley Ward In-Reply-To: Date: Thu, 6 Mar 2014 14:35:31 +0000 Message-Id: References: <531883F5.7000800@stpeter.im> To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/9SaeckZHodB-tWx1olPQTbZ7XUk Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:35:41 -0000 --Apple-Mail=_D07EBC21-F23B-4A42-BEA7-081D2D0A17F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 6 Mar 2014, at 14:28, Dave Cridland wrote: > You're saying to include, pre-encrypt, something like 123465 in the plaintext order to = defeat message size analysis of the ciphertext? It=92s XML - you could always just use comments or = whitespace. =97 Ash --Apple-Mail=_D07EBC21-F23B-4A42-BEA7-081D2D0A17F1 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGUTCCBTmg AwIBAgIDB4u8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwOTExMTQ1NzExWhcNMTQwOTEzMDY1ODQyWjBnMRkwFwYDVQQNExBTQTJmOEtoalJZajFlMTcz MSEwHwYDVQQDDBhhc2hsZXkud2FyZEBzdXJldmluZS5jb20xJzAlBgkqhkiG9w0BCQEWGGFzaGxl eS53YXJkQHN1cmV2aW5lLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhrR088 72GtgQEkA7wVTAnJSq88pqQMh/6vm9yBPswKf9WGP7vvbELG9QVhrBT4xy3dfwiOi6pP8uLX8IXj AySoGy/c/NYCiRszaRb69Mtbg+SC21sAnHciSomaLOvQTvH4YOwaA8MYVsLGiXqM5bOnKPCnc12o R8pJsc8e2tnFYLarOfZU0Ls/FeSjG/WYYFCvWtey8BZ8UBSGtw8LMwdAy5GC0EnDN6bzrMsTncJj HcNQP/q5h7LEN8HJOX6gGZruzVoLxjvvVUNh78ozUWipsXjT+qAIv8iewxs1yUC3/yzI2+EringM 42honZshSYEVvc+bB/D68aISgxex25cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU9whoXudvZQzZ9KfV pdmpntf7d6owHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYYXNo bGV5LndhcmRAc3VyZXZpbmUuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAgap/JvdT9yikc7GD 7d675gyrXiHoxVUJXqf62lWNLf2t/7z552zV/q20oT9i4dXg8/0l92jStU9d7KybGN/sh9/oCCkT C35lX8Ua60iFPom2OA3t+70/HXdRmMAmDYDTUkzaZwe2ZxCZVELc/4MVo6FQIhuvgwGk+i+5X65y 9n0Plbgo3qQ8FpEC3vp4H1rDY9CyxyteTafG9pKnDiqzNm8S0rVPoiWVxkNsUhbmwJU/0MEQyFG2 TY/qoVPptKAldpP15s8hL2K26Xc0X7+btoXFOibxWnNUNf/qbELdhFMffUQY3IXnLvdL/QwD/Rot mRi23JILM5rNxmqSE1V60TGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAweLvDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDAzMDYxNDM1MzJaMCMGCSqGSIb3DQEJBDEWBBSXda178LvrVmj94cUGYhfwDob/ TjCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAweLvDCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB4u8MA0G CSqGSIb3DQEBAQUABIIBAJ5noAR6tDN0aRDjwuwHloPDtnC3FcqXeeMc8vTpYBVXQI0KjCZ6ZZnu /u0NkmoIYKxfQcy3DQChbInriSm8I3+w+lN6w1Cc95u0KgVeevPEX1gzPMCSFcqdB3S9SNPB8qv7 hARTO17WXBzuVhkCap00DlI5FxVTRBvL1Emy6OTwHviw0pimZzbgqt+y5Cy+MlD9zY+clfXqk7op hBH61YX7I7ppDSyGmYUzf5+WYXthElPs8g+j9GzVa4+r5uheNAqrVYg8wILSyBzYy0z+u6NuBU+h 4Peq0VBRTxigrvpk5D3XV2i99hYGX9i/lx7bXG4u+PX0IqOQVa3MNvOlwaAAAAAAAAA= --Apple-Mail=_D07EBC21-F23B-4A42-BEA7-081D2D0A17F1-- From nobody Thu Mar 6 06:41:11 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580741A037B for ; Thu, 6 Mar 2014 06:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kZB3DKA89c3 for ; Thu, 6 Mar 2014 06:41:07 -0800 (PST) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 79E751A042D for ; Thu, 6 Mar 2014 06:41:01 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id q58so3183611wes.26 for ; Thu, 06 Mar 2014 06:40:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JoUL+DDNtYFdFKiLHVAzb90sh9Po3Sn0WqRTHADZOhc=; b=KjOMOucfjHW02en8iL9eFvoHiene81YX72ceM1mMrd3cdoPI26tXHgRQKHefhxVXNv NtecYwHf7QfXiiJONLupKSuBioeFXPdmXlDXy3/WCXyjLkYt1ztdC1EHr0Bn5sbGy+wT C4wK07FpvfcqvlBI/Abuz3iqT/zfrJzSiAhE97zVNb32OPKQOSnP1BME1XU5ZoOwrrJx 01LN9mupRhzBvnS0YIGB9fwCpmB16Q5lTScNaL/2r0AwFIKU2mdqcnDhcwKTY5mb5wA/ yX+1N7351ZZEna9s+X+hz08R0qToUgsfLy+mFIf6Da17GDXkhKzS5IPG7nhJqD6dclfH IdGQ== MIME-Version: 1.0 X-Received: by 10.194.61.210 with SMTP id s18mr10873238wjr.10.1394116857118; Thu, 06 Mar 2014 06:40:57 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.217.96.196 with HTTP; Thu, 6 Mar 2014 06:40:57 -0800 (PST) In-Reply-To: References: <531883F5.7000800@stpeter.im> Date: Thu, 6 Mar 2014 14:40:57 +0000 X-Google-Sender-Auth: r02aJlS0d2meQp85jyN3bPL_A64 Message-ID: From: Kevin Smith To: Ashley Ward Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/TTNDTxO3-Nx7jnkSWpCzuSiyO_c Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:41:08 -0000 On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward wrote: > On 6 Mar 2014, at 14:28, Dave Cridland wrote: > >> You're saying to include, pre-encrypt, something like 123465 in the plaintext order to defeat message size analysis of the ciphertext? > > It's XML - you could always just use comments or whitespace. Comments are slightly problematic, on account of being illegal. /K From nobody Thu Mar 6 06:42:05 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A5F1A037F for ; Thu, 6 Mar 2014 06:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGLv1fTrP7vr for ; Thu, 6 Mar 2014 06:42:00 -0800 (PST) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C47521A0428 for ; Thu, 6 Mar 2014 06:41:56 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id uz6so2649991obc.13 for ; Thu, 06 Mar 2014 06:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YK71y44z7lKVnUVZwciPJ8tBrQrEUOvHx96PrigNKOk=; b=QjcX9ui1RkFdDgEUtgGtnemO6qKer5psAPR9+EQbi7Az4BInYlaOtQt11A53Cst3St 6UZN6Jn4Ty/uLLg/64Hzl7UAZUwV5ZRrch7CjhpDlhTRgunT4Evad7dqaTuxcO5ZRmMv GzufRU/bR4UG+lkuyR6vb+izmGOTQ5ZztfJZA= 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=YK71y44z7lKVnUVZwciPJ8tBrQrEUOvHx96PrigNKOk=; b=LLTI+q/GsoBcVVytb0Cveyr6bF+bRLyIbyOP8OC0RJTZwMjFpPg0PmBu+Tn8IHmHGr OzsXJ0IxyaitgSPtppmROJODJevFtniNK3ESVbmR7UGxq4ol4leNdFAq/PuMrX1hNMuz lPHfSF+HTvLk9LNnqYpbYw1i3MGZJQahpS+PHfhqtG5Ht3T2DgKmXMvhFoXdM6iBCPkh hMHeEXJEjfZdqzbtCG64fllI813K017N8K8b4kfFYmAKqjjGJBY9nV0pbZMxtBuRAf3G tsvIqjSiO8ExVpnryzgix9A452Vj3GXc48W1Le/04fsTh9rGZck9kKxWwu2WfpKLWuxD obKA== X-Gm-Message-State: ALoCoQl5PEQYWielSwEKASypU4wpKNp804TVY7syOobvNarFRoKYfa26KonYLLlhL6KnowTohphf MIME-Version: 1.0 X-Received: by 10.60.77.35 with SMTP id p3mr5984893oew.46.1394116912866; Thu, 06 Mar 2014 06:41:52 -0800 (PST) Received: by 10.60.58.41 with HTTP; Thu, 6 Mar 2014 06:41:52 -0800 (PST) In-Reply-To: References: <531883F5.7000800@stpeter.im> Date: Thu, 6 Mar 2014 14:41:52 +0000 Message-ID: From: Dave Cridland To: Kevin Smith Content-Type: multipart/alternative; boundary=047d7b33d2445dfe2704f3f123ac Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/73ne18AG833TL3XAtwZmzl3o32A Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:42:01 -0000 --047d7b33d2445dfe2704f3f123ac Content-Type: text/plain; charset=ISO-8859-1 On 6 March 2014 14:40, Kevin Smith wrote: > On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward > wrote: > > On 6 Mar 2014, at 14:28, Dave Cridland wrote: > > > >> You're saying to include, pre-encrypt, something like xmlns:spacer='urn:...'>123465 in the plaintext order to defeat > message size analysis of the ciphertext? > > > > It's XML - you could always just use comments or whitespace. > > Comments are slightly problematic, on account of being illegal. > Only on the wire, where they'd not appear in the plaintext. --047d7b33d2445dfe2704f3f123ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 6= March 2014 14:40, Kevin Smith <kevin@kismith.co.uk> wrote= :
On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward <ashley.ward@surevine.com> wrote: > On 6 Mar 2014, at 14:28, Dave Cridland <dave@cridland.net> wrote:
>
>> You're saying to include, pre-encrypt, something like <spac= er:junk xmlns:spacer=3D'urn:...'>123465</spacer> in the pl= aintext order to defeat message size analysis of the ciphertext?
>
> It's XML - you could always just use <!-- --> comments= or whitespace.

Comments are slightly problematic, on account of being illegal.

Only on the wire, where they'd not appear in t= he plaintext.=A0
--047d7b33d2445dfe2704f3f123ac-- From nobody Thu Mar 6 06:44:51 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5BD1A042D for ; Thu, 6 Mar 2014 06:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh0WuurCnyQ2 for ; Thu, 6 Mar 2014 06:44:45 -0800 (PST) Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 98D3F1A03D5 for ; Thu, 6 Mar 2014 06:44:44 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q58so3203651wes.20 for ; Thu, 06 Mar 2014 06:44:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=9c2TGxKFxclC0+LvZvvYl0EJWsCX1qzktFuWqCLqnVg=; b=JO8PRQlFW9WJ/lMz4zrSlyFGThliL6DhwSbWQ4z1+fL7e3/zcynMAvsvN9/K7qqmBo Ou83EfvClSjyjzQDwMK6Hc9NqzpqiM3FweVlJ2kyaVjFq3IFNsYB3MYmMyDnuU/Ecjzn tU9aNfp07GBzkyHGCVWI8lMuXBL+wxdAmGpSMbKML9XHLlHL6PdRL5vjIn0q+7PX2eeN p6ZJgkWH+sw8LsxqKEoLtNyPV13V9sFVJOZH3rbXYs6hQjW8zHVGUtmBjOfuUQyHEE4S rFAE8s5DsgFeAkBspgmf53KiHq5Yl5zVgAyNE6OlJ3LgoksZswK1T0r3lpvsLkx5YMi6 3Hrw== X-Gm-Message-State: ALoCoQmUc1GrmZVOKhqnPtd92tuF4/ePSVEZiVrUAQRdcnXuL1cznrMrn372BaoKFDH/VYVTASAI X-Received: by 10.194.174.100 with SMTP id br4mr10441262wjc.83.1394117077320; Thu, 06 Mar 2014 06:44:37 -0800 (PST) Received: from [192.168.1.87] (host81-155-184-37.range81-155.btcentralplus.com. [81.155.184.37]) by mx.google.com with ESMTPSA id ux5sm17915309wjc.6.2014.03.06.06.44.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Mar 2014 06:44:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_92C5FACE-FC35-49D0-BEC9-53C9EC95D9D3"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ashley Ward In-Reply-To: Date: Thu, 6 Mar 2014 14:44:33 +0000 Message-Id: <26D173CC-25CE-45AF-8F5A-27AF576558A0@surevine.com> References: <531883F5.7000800@stpeter.im> To: kevin@kismith.co.uk X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/6Bs02OeLwZ1E-HW34tPOmbQr39M Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:44:47 -0000 --Apple-Mail=_92C5FACE-FC35-49D0-BEC9-53C9EC95D9D3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 6 Mar 2014, at 14:40, Kevin Smith wrote: > On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward = wrote: >> On 6 Mar 2014, at 14:28, Dave Cridland wrote: >>=20 >>> You're saying to include, pre-encrypt, something like 123465 in the plaintext order to = defeat message size analysis of the ciphertext? >>=20 >> It's XML - you could always just use comments or whitespace. >=20 > Comments are slightly problematic, on account of being illegal. True - I often forget that XMPP isn=92t entirely XML compliant! =97 Ash= --Apple-Mail=_92C5FACE-FC35-49D0-BEC9-53C9EC95D9D3 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMjTCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIGUTCCBTmg AwIBAgIDB4u8MA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTMwOTExMTQ1NzExWhcNMTQwOTEzMDY1ODQyWjBnMRkwFwYDVQQNExBTQTJmOEtoalJZajFlMTcz MSEwHwYDVQQDDBhhc2hsZXkud2FyZEBzdXJldmluZS5jb20xJzAlBgkqhkiG9w0BCQEWGGFzaGxl eS53YXJkQHN1cmV2aW5lLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKhrR088 72GtgQEkA7wVTAnJSq88pqQMh/6vm9yBPswKf9WGP7vvbELG9QVhrBT4xy3dfwiOi6pP8uLX8IXj AySoGy/c/NYCiRszaRb69Mtbg+SC21sAnHciSomaLOvQTvH4YOwaA8MYVsLGiXqM5bOnKPCnc12o R8pJsc8e2tnFYLarOfZU0Ls/FeSjG/WYYFCvWtey8BZ8UBSGtw8LMwdAy5GC0EnDN6bzrMsTncJj HcNQP/q5h7LEN8HJOX6gGZruzVoLxjvvVUNh78ozUWipsXjT+qAIv8iewxs1yUC3/yzI2+EringM 42honZshSYEVvc+bB/D68aISgxex25cCAwEAAaOCAt4wggLaMAkGA1UdEwQCMAAwCwYDVR0PBAQD AgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU9whoXudvZQzZ9KfV pdmpntf7d6owHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwIwYDVR0RBBwwGoEYYXNo bGV5LndhcmRAc3VyZXZpbmUuY29tMIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCC ASowLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlz IGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZhbGlkYXRp b24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkg Zm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFy dHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29t L2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3Nw LnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL2Fp YS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqG GGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAgap/JvdT9yikc7GD 7d675gyrXiHoxVUJXqf62lWNLf2t/7z552zV/q20oT9i4dXg8/0l92jStU9d7KybGN/sh9/oCCkT C35lX8Ua60iFPom2OA3t+70/HXdRmMAmDYDTUkzaZwe2ZxCZVELc/4MVo6FQIhuvgwGk+i+5X65y 9n0Plbgo3qQ8FpEC3vp4H1rDY9CyxyteTafG9pKnDiqzNm8S0rVPoiWVxkNsUhbmwJU/0MEQyFG2 TY/qoVPptKAldpP15s8hL2K26Xc0X7+btoXFOibxWnNUNf/qbELdhFMffUQY3IXnLvdL/QwD/Rot mRi23JILM5rNxmqSE1V60TGCA28wggNrAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAweLvDAJBgUrDgMCGgUAoIIBrzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNDAzMDYxNDQ0MzRaMCMGCSqGSIb3DQEJBDEWBBSklMJzA/haT1o1IcZmeflf0eoV MTCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20g THRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAweLvDCB pwYLKoZIhvcNAQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB4u8MA0G CSqGSIb3DQEBAQUABIIBAIHZHJmPRsccDRs7OJz8iHHGUv313sMVQDyA7c6hDp8Kc6upZcBGOJ45 RMwzP57pcK+mT8HycHwQt0S+SzqZjw/EBJP9l7wZ4hAUKEs8CaNUXF/o5peNPIYlWEBy2I8OPb8f G+7UDHd0la+zoUlJN4rNNpKKZPweyZaqaPxGhG/izjX9NDkNnDeJAHYvApTch8C2wnzMTph6Wp6N FjTgZ8JZ87Lx/Ttg3AfuWGu6gdLBFbfTAlSHhpkiqyugsp+gVjg+boaJ6B4ZU1KhCmoFdGLs8oaH pCrh/Ay48Wur2DmXIZ8wU69O1VnSjPbX6jwvjvVhVhih1ckSZX9AWesmpuQAAAAAAAA= --Apple-Mail=_92C5FACE-FC35-49D0-BEC9-53C9EC95D9D3-- From nobody Thu Mar 6 06:46:44 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE811A000D for ; Thu, 6 Mar 2014 06:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tuVfVfT8S2O for ; Thu, 6 Mar 2014 06:46:39 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 089341A0041 for ; Thu, 6 Mar 2014 06:46:37 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id p61so3199919wes.11 for ; Thu, 06 Mar 2014 06:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dpmR58OR2hycjetCsE/LE7O/ereCgcIc0afWH8D+yeY=; b=agdZ9kCySTh3o4WISbvCE+QSER4m26gZhPh33CuWSGciDYI7jSG7TJ4qnAcWPX32sN /IfuhkBKCHeQsnCrt/ieasuRelINoZRs7p3FtZlPNcyHxTmKbHH4EM/YEqU9P2Ey54s/ ZlYfrYu6cMRPG/OP8xNHQBC0cTZncsI+YjZZxpy0UNEFoiPbh/APjPKzvvosSG2tavAr dKanHCszr/q5oSFV7esDi/pxdxEInQIkC1xCSoU6wJY3dX204EbHXECgX+gEceeWR6OF 4vW8+ZQRbuM5ehW5PsSJ8emOi86G6jLleUcjXGh+MjZ6w6De1dAeNypmE7CBrLf/NWkr vIZQ== MIME-Version: 1.0 X-Received: by 10.194.24.35 with SMTP id r3mr10729021wjf.68.1394117193648; Thu, 06 Mar 2014 06:46:33 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.217.96.196 with HTTP; Thu, 6 Mar 2014 06:46:33 -0800 (PST) In-Reply-To: References: <531883F5.7000800@stpeter.im> Date: Thu, 6 Mar 2014 14:46:33 +0000 X-Google-Sender-Auth: 1J8eYSPdIuyrQrawtJMoTUiuDCM Message-ID: From: Kevin Smith To: Dave Cridland Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/-GNXPFheOPTNsqL8MHxsAipZpuU Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:46:41 -0000 On Thu, Mar 6, 2014 at 2:41 PM, Dave Cridland wrote: > On 6 March 2014 14:40, Kevin Smith wrote: >> >> On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward >> wrote: >> > On 6 Mar 2014, at 14:28, Dave Cridland wrote: >> > >> >> You're saying to include, pre-encrypt, something like > >> xmlns:spacer='urn:...'>123465 in the plaintext order to defeat >> >> message size analysis of the ciphertext? >> > >> > It's XML - you could always just use comments or whitespace. >> >> Comments are slightly problematic, on account of being illegal. > > > Only on the wire, where they'd not appear in the plaintext. Presumably if we're encrypting stanza contents, we'd like the stanza contents to still be legal stanza contents once decrypted. I don't see a reason to start fiddling around with the rules so we could shove comments in here and only here. The shove-stuff-in-a-junk-namespace seems easier and less contentious. /K From nobody Thu Mar 6 06:49:30 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25811A0070 for ; Thu, 6 Mar 2014 06:49:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ552ldr-_r9 for ; Thu, 6 Mar 2014 06:49:27 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 1752F1A00DD for ; Thu, 6 Mar 2014 06:49:26 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so3285844wgh.24 for ; Thu, 06 Mar 2014 06:49:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zB6otW02k+wvRX3OicsBqTff1TxRjwYxf1dCm7sYiwg=; b=bVjn+l09Gr8Cih+cDf7rqLp7P2pbUfQJkJ4ALJTv+Zfuc4suJCim/suOJtMIb4kblf ca5yqOZpRH+fg6PgDeMIdYooKoKgMEpRZRSMIBSpVU2cCsyrVUybjyK+uQq/+GeJ9I4x 6k1bihPov3E4lhPhaC97RCkXPAAQDJWfKOjgHspzfvm7AXeedCPp3ljodeQ1tDGC4Bv7 gybm+gS+aKoYzYymSCw98C/dnm+imKPsP0f4mu5UzMXA7cCZGZh4UFn37Pjr+vJToadS 3ey5Ph1TSfBWeczyTp1SREDr7ANqk67XvOfaVb3f2guV4JeJjv5Xn+kzEpuIqd5e20pP psPA== MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr10673154wjd.3.1394117362753; Thu, 06 Mar 2014 06:49:22 -0800 (PST) Sender: k.i.smith@gmail.com Received: by 10.217.96.196 with HTTP; Thu, 6 Mar 2014 06:49:22 -0800 (PST) In-Reply-To: <26D173CC-25CE-45AF-8F5A-27AF576558A0@surevine.com> References: <531883F5.7000800@stpeter.im> <26D173CC-25CE-45AF-8F5A-27AF576558A0@surevine.com> Date: Thu, 6 Mar 2014 14:49:22 +0000 X-Google-Sender-Auth: A7HxSBSMI8RFCQG7XBQQV8geCY0 Message-ID: From: Kevin Smith To: Ashley Ward Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/IAlrr2EkZfwWyP0rB277zYAz40A Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kevin@kismith.co.uk List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:49:28 -0000 On Thu, Mar 6, 2014 at 2:44 PM, Ashley Ward wrote: > On 6 Mar 2014, at 14:40, Kevin Smith wrote: >> On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward wrote: >>> On 6 Mar 2014, at 14:28, Dave Cridland wrote: >>> >>>> You're saying to include, pre-encrypt, something like 123465 in the plaintext order to defeat message size analysis of the ciphertext? >>> >>> It's XML - you could always just use comments or whitespace. >> >> Comments are slightly problematic, on account of being illegal. > > True - I often forget that XMPP isn't entirely XML compliant! The stream isn't a real XML document (stream restarts break this) but not allowing comments doesn't stop it being XML, just a subset. /K From nobody Thu Mar 6 07:12:53 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562961A0092 for ; Thu, 6 Mar 2014 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oDgMLGYMOpG for ; Thu, 6 Mar 2014 07:12:47 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 750AA1A0079 for ; Thu, 6 Mar 2014 07:12:47 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id x3so3010509qcv.39 for ; Thu, 06 Mar 2014 07:12:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:mime-version:content-type:content-transfer-encoding; bh=gsbj3ICEzm0r0Pn8X7TaVVqSNZnWqv3dTBPq9/YbF1c=; b=dctbA7joRza4FhYMdWMgaN45BzpNvZh8WeNyvTZk8DkSoUo8khkBdj1Uhv5f6CBOP4 rCDr4xQNpnbDpM+Z5+2UYKBBj9hdPkctlWp93EPY4Bo7WO0Jf1y9pCjCn8/tPTljneeg BbaIC/4GXxXXe6W7D3IA3kSH0bIuSqAleGkfz3FAfV+HMmsqTnuOtTx5PsbEfjzskXoT inxRmfca9pYUnygXgZ6wX+eovimQlEujHA+vzkc6TTvNGX7CM/cZRUqGFfmId0th0JTv c6DKGuXhvByMUi0VObuFas9/Wg1e8qZAyVZCvDXdKnZ1ziZzhStD829H8i96PecVvSSo iQzA== X-Gm-Message-State: ALoCoQm5bRgFXkwPkocSxGjJjVASg4a3DJ67JIDCPXdvCBfpPYtPVs87Qq+AYg9y5Vl3+aNvGYw5 X-Received: by 10.224.22.65 with SMTP id m1mr2663466qab.103.1394118763402; Thu, 06 Mar 2014 07:12:43 -0800 (PST) Received: from [192.168.2.4] (pool-173-79-106-67.washdc.fios.verizon.net. [173.79.106.67]) by mx.google.com with ESMTPSA id m11sm7978402qge.13.2014.03.06.07.12.38 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 06 Mar 2014 07:12:42 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Thu, 06 Mar 2014 10:12:33 -0500 From: Carl Wallace To: Message-ID: Thread-Topic: comments on draft-miller-xmpp-e2e-06 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/m_zxS8NkQPWoo8u0bLWpagiJyXc Subject: [xmpp] comments on draft-miller-xmpp-e2e-06 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:12:50 -0000 Section 1 - This may be in the reqs draft, but seems worth stating here that some end points for a given recipient may share keys, some may use different keys, some may have no keys and some may not support encryption or signature verification at all. Section 3 - What should the sender do if some end points for a recipient indicate lack of support for encryption? Are error responses helpful independent of confirmation that some end points support encryption? Is the intent for messages to only be sent to end points that advertise support? - Why not include an end point's key in its info results and enable return of the encrypted SMK (or even CEK) with the encrypted payload (to save a round trip). Given a single message could trigger a number of requests for the SMK, the option to include the encrypted CEK in the payload may be worthwhile. Including the encrypted CEK would help with storage too. - Why is the SID required to be unique for a {sender, recipient, SMK} tuple? This would allow for the same SID to be used to name every SMK used with a recipient. Suggest unique for each recipient (i.e., SMK's are uniquely identified by recipient+SID for a given sender). - Discuss how multiple recipients are handled - s/optionallly/optionally - It would be nice to have a summary of new state information the sender and recipient are required to manage (like SMKs) and significant new operations (like authorization of key requests where a given recipient may use a number of different public keys) - Should include an example of a reply to an encrypted message. Should/must the same SMK be used in replies? - Is there any reason pre-placed SMK values cannot be used instead of SMK values retrieved automatically from the sender? Section 4 - How is the public key used to verify signatures published to the recipients? If not included in the payload, should be available a la the SMK. This would be useful, at a minimum, when the signer uses a certificate from a PKI the recipient trusts. - s/Playload/payload - Include some text indicating users MUST be able to determine if a message was authenticated - Should data be presented to the user when the timestamp is not acceptable? There are guidelines for invalid signatures, but not for unacceptable timestamps. Same comment on 3.3.5 too. - May want to distinguish between successful authentication vs successful verification Section 5 - Should describe how the entity requesting a key gets the SID - Should make it more clear that a new CEK is generated in order to encrypt the SMK, then the CEK is encrypted under the public key. Section 9 - The requirement for the sender to be online would seem like sufficient grounds for including encrypted CEKs in the payload. Section 11 - Offline storage may be another reason to include encrypted CEKs in a payload. Perhaps the solution should be to encrypt for each of a recipient's known keys plus an SMK that could be used by end points using a different, not-yet-known-to-the-sender key. - Need to address authorization for SMK release. - Include some guidance on SMK lifetime. From nobody Thu Mar 6 08:41:50 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803B51A00EC for ; Thu, 6 Mar 2014 08:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mj6G_ofNxwD for ; Thu, 6 Mar 2014 08:41:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE6F1A00E8 for ; Thu, 6 Mar 2014 08:41:48 -0800 (PST) Received: from dhcp-a684.meeting.ietf.org (unknown [31.133.166.132]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 926384045D; Thu, 6 Mar 2014 09:41:43 -0700 (MST) Message-ID: <5318A545.60203@stpeter.im> Date: Thu, 06 Mar 2014 16:41:41 +0000 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dave Cridland References: <531883F5.7000800@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/vY1-5VAmAuMxQxdY93keLs9gARw Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:41:49 -0000 On 3/6/14, 2:28 PM, Dave Cridland wrote: > You're saying to include, pre-encrypt, something like xmlns:spacer='urn:...'>123465 in the plaintext order to defeat > message size analysis of the ciphertext? Yes, that's what I'm saying. Peter From nobody Fri Mar 7 03:23:25 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1902F1A0294 for ; Fri, 7 Mar 2014 03:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sc0xRfbQHuo for ; Fri, 7 Mar 2014 03:23:19 -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 7F4A31A01E0 for ; Fri, 7 Mar 2014 03:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8109; q=dns/txt; s=iport; t=1394191396; x=1395400996; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=TTPMapyVkMZDspLmgNfKvSihIS3vgOpr+/niaooHoCo=; b=jRAaWR4okN2LZoLi9k2ylwjR0+vd8Mgc2sTsVfP8FZiD9Ud0jly5UDFo YjN9WkjgdYtwuuPDLqcwYzgt1xTkCQmuuam2LbMieXPDQbSXLErNx+Tuv 46uSOxLOfsAtR2pBRMD6vG/jb3R0TkSdSBMnyctUplfOeCZbI5622EMGN Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooKAIqrGVOtJV2Y/2dsb2JhbABagwg4Vad+lH4KgRMWAXSDfQEBAQMBeAYLCxgJFg8JAwIBAgFFBgEMBgIBAReHYQgNxkEXjkkWOoQ2AQOJC4sog2OBMJBkgyuBaUE X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="305667790" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 07 Mar 2014 11:23:16 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s27BNFwS020944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 11:23:15 GMT Received: from che-vpn-cluster-2-433.cisco.com (10.86.243.178) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Mar 2014 05:23:14 -0600 Message-ID: <5319AC20.4090906@cisco.com> Date: Fri, 7 Mar 2014 11:23:12 +0000 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carl Wallace , References: In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.86.243.178] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/1VIO0P22JkvdxvzLr8ZsQfGZEu0 Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 11:23:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Thank you very much for the feedback! I'll incorporate your suggestions as soon as I can. On 3/6/14, 3:12 PM, Carl Wallace wrote: > Section 1 - This may be in the reqs draft, but seems worth stating > here that some end points for a given recipient may share keys, > some may use different keys, some may have no keys and some may not > support encryption or signature verification at all. > We did discuss reviving the e2e-reqs draft in the WG session on Tuesday, but it would be important to include this. > Section 3 - What should the sender do if some end points for a > recipient indicate lack of support for encryption? Are error > responses helpful independent of confirmation that some end points > support encryption? Is the intent for messages to only be sent to > end points that advertise support? There is little (read: nothing) that can be said on what existing "legacy" end-points ought to do. I tried to say something on what existing clients already do, to the best of my knowledge. Many (most) drop anything they don't understand, so getting errors could very well be impossible unless the applications were specifically updated to "anti-support" this specification. It's also possible I'm missing the point here, too (-: The intention is not for the sending end-point to only send to other supporting end-points. Indeed, I want this to be compatible with [CARBONS] and [MUC] where the possible. To that end, most clients try to do something if there is a body, and this document could suggest that sending end-points include an appropriate generic "this message is protected" body. > > - Why not include an end point's key in its info results and enable > return of the encrypted SMK (or even CEK) with the encrypted > payload (to save a round trip). Given a single message could > trigger a number of requests for the SMK, the option to include the > encrypted CEK in the payload may be worthwhile. Including the > encrypted CEK would help with storage too. The encrypted CEK is included in each message with -06. Including an encrypted SMK is a possibility, although I start to worry about the size of the overall stanza. If it's absolutely known that the message will be delivered to a single end-point it shouldn't get too large, but I am assuming that servers will start multiplexing chat messages (a la [CARBONS]) which means the benefits of including the encrypted SMK are unrealized if only there's only a single instance of the encrypted SMK; including multiple SMKs can be very problematic (e.g., many server deployments reject very large stanzas). > > > - Why is the SID required to be unique for a {sender, recipient, > SMK} tuple? This would allow for the same SID to be used to name > every SMK used with a recipient. Suggest unique for each recipient > (i.e., SMK's are uniquely identified by recipient+SID for a given > sender). > I'm not sure what you're trying to say here (it could be due to me responding on the last day of an IETF meeting). Can you provide an example of what your concern here is? > - Discuss how multiple recipients are handled That is a very good point. There is some text there, but it is fairly weak. I was considering a form of ASCII sequence diagram of the general flow -- would that better help to explain things? > > - s/optionallly/optionally > Fixed in working copy. > - It would be nice to have a summary of new state information the > sender and recipient are required to manage (like SMKs) and > significant new operations (like authorization of key requests > where a given recipient may use a number of different public keys) That is a very good suggestion. Do you think you could provide some text to get it started? > > - Should include an example of a reply to an encrypted message. > Should/must the same SMK be used in replies? > That is not a bad idea. I'll look into it. > - Is there any reason pre-placed SMK values cannot be used instead > of SMK values retrieved automatically from the sender? > Is there any additional concern here beyond the point a few above? > Section 4 - How is the public key used to verify signatures > published to the recipients? If not included in the payload, > should be available a la the SMK. This would be useful, at a > minimum, when the signer uses a certificate from a PKI the > recipient trusts. > These are good points, and it ought to be included. The JWS structure does allow for inclusion of the jwk (or jku, or x5c, or x5t, or x5u) which would be the key used to sign the content. I'll add more clarity on this point. > - s/Playload/payload > Fixed in working copy. > - Include some text indicating users MUST be able to determine if > a message was authenticated > That is a good point. > - Should data be presented to the user when the timestamp is not > acceptable? There are guidelines for invalid signatures, but not > for unacceptable timestamps. Same comment on 3.3.5 too. > I have been hesitant on dictating what to display to users. I don't want to tie the hands of implementations, and it's rather difficult to independently verify that a given implementation complies without some sort of officiating body (which we definitely don't want). > - May want to distinguish between successful authentication vs > successful verification > Noted. > Section 5 - Should describe how the entity requesting a key gets > the SID > I thought I had said that in here, but I'll clarify it further. > - Should make it more clear that a new CEK is generated in order > to encrypt the SMK, then the CEK is encrypted under the public > key. > You have this reversed: the SMK is used to encrypt the CEK, and the recipient's public key is used to encrypt the SMK. It is completely possible that I was not consistent here. > Section 9 - The requirement for the sender to be online would seem > like sufficient grounds for including encrypted CEKs in the > payload. > Encrypted CEKs are in the payload in -06. > Section 11 - Offline storage may be another reason to include > encrypted CEKs in a payload. Perhaps the solution should be to > encrypt for each of a recipient's known keys plus an SMK that could > be used by end points using a different, > not-yet-known-to-the-sender key. > You mean encrypted SMKs here. One idea that had been discussed outside the meeting was to try and use [PEP] as a way to do this, but we didn't spend a lot of time thinking about the mechanics and implications here. > - Need to address authorization for SMK release. > I have pretty much hand-waved over this part. One idea that came to light this week was to provide fingerprints for the recipients' public keys, somehow. Suggestions for improvements are welcome. > - Include some guidance on SMK lifetime. There is *some* guidance in section 11.2, but I admit it is rather vague. Could you provide more specific suggestions? - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. [CARBONS] XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html > [MUC] XEP-0045: Multi-User Chat < http://xmpp.org/extensions/xep-0045.html > [PEP] XEP-0163: Personal Eventing Protocol < http://xmpp.org/extensions/xep-0163.html > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTGawgAAoJEDWi+S0W7cO1Jo4H/R8AvTt1WBMIwvBD1U8JNBaP M88uMewtHGoQ/NbizCPnNS8DTMQyMxs/z6w66WDBnNNuCFhjqgh5G4X7X9elnFzI VezIMKsr5Jc6dlN/9jRgWdQtEuqqmuGKfMHaAoNdqph5pP+zWSx5yhMbcb/wN7Uu 6+JdY4GB9Yz3xBrwQTBZnkRqqTKKL34/WoX42j9Vy2JgFLyRMu3xoW6xg99622Ol VJxXRs7X9uERB0Dn8xTW2NTnRIN82g4WZuuaJLOkGDFQaienaBwQTHhogjaHFcNv aTCnQhipI8Io4gLdT3uFzn84oZDYhBCSGyclegAXesthI9gnO3I671YUfTJl9xo= =G0xx -----END PGP SIGNATURE----- From nobody Fri Mar 7 04:28:37 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E7A1A0260 for ; Fri, 7 Mar 2014 04:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcVupKSKWCLt for ; Fri, 7 Mar 2014 04:28:30 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 661E51A0237 for ; Fri, 7 Mar 2014 04:28:30 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id r5so4443161qcx.18 for ; Fri, 07 Mar 2014 04:28:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=92Vz+m8aSDDLoLBRYXdPLYxr+brT4UDU5PzEUA+9QL8=; b=Kw94PhxNG6MYeIFras8Lakuwd0dAbDjpzwawuAayq0r64pQuh6h1LgoFDnbrjxg6Jv /SxvNluOaJVaugUMiG2Pa7PtWtBOhBLw0GkCTNudmXW9vAoz0B3kJ87XaH6yX8nYM3Lq mGVtDPNhyCfXCXSONEiHY4Kemmd8fgS+B1DDLGiJjQ2EK4IWvyp36H+IUC8LHR5cF9l4 1wzs0Yh17D+UjeGbSiAzfainxyRTZqcCwW+i4X0FPCxjnLvPsGAmrrLLq2iNXzMLtM2d 9Pdnb0hfI2Wr/UxhCuhy4j3NWV1xrzypO6k+EqnY6Q9vYeJ8kNri+duTE7rHXDO9dsWM MjSQ== X-Gm-Message-State: ALoCoQmOmJViI526xYIlN+1ICY71JQB50JpTRVW0tny/OoF2EIYfHJxUMlDxfuZ1RKqw3kfv6r/1 X-Received: by 10.224.43.144 with SMTP id w16mr9946945qae.93.1394195305805; Fri, 07 Mar 2014 04:28:25 -0800 (PST) Received: from [192.168.2.4] (pool-173-79-106-67.washdc.fios.verizon.net. [173.79.106.67]) by mx.google.com with ESMTPSA id 73sm12330135qgg.22.2014.03.07.04.28.21 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 07 Mar 2014 04:28:24 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 07 Mar 2014 07:28:17 -0500 From: Carl Wallace To: Matt Miller , Message-ID: Thread-Topic: [xmpp] comments on draft-miller-xmpp-e2e-06 References: <5319AC20.4090906@cisco.com> In-Reply-To: <5319AC20.4090906@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/MJ72ddHIsRYrV8mrOO4dsCMfWgM Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:28:34 -0000 On 3/7/14, 6:23 AM, "Matt Miller" wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA512 > >Thank you very much for the feedback! > >I'll incorporate your suggestions as soon as I can. > >On 3/6/14, 3:12 PM, Carl Wallace wrote: >> Section 1 - This may be in the reqs draft, but seems worth stating >> here that some end points for a given recipient may share keys, >> some may use different keys, some may have no keys and some may not >> support encryption or signature verification at all. >>=20 > >We did discuss reviving the e2e-reqs draft in the WG session on >Tuesday, but it would be important to include this. It=B9s also worth noting the sender may have multiple end points with the same properties. If the same SMK were used in replies, it creates kind of a odd scenario where both parties could be providing the SMK for the asking. =20 > >> Section 3 - What should the sender do if some end points for a >> recipient indicate lack of support for encryption? Are error >> responses helpful independent of confirmation that some end points >> support encryption? Is the intent for messages to only be sent to >> end points that advertise support? > >There is little (read: nothing) that can be said on what existing >"legacy" end-points ought to do. I tried to say something on what >existing clients already do, to the best of my knowledge. Many (most) >drop anything they don't understand, so getting errors could very well >be impossible unless the applications were specifically updated to >"anti-support" this specification. It's also possible I'm missing the >point here, too (-: > >The intention is not for the sending end-point to only send to other >supporting end-points. Indeed, I want this to be compatible with >[CARBONS] and [MUC] where the possible. To that end, most clients try >to do something if there is a body, and this document could suggest >that sending end-points include an appropriate generic "this message >is protected" body. I=B9ve not yet looked, but I had wondered if it would be possible to define the signature format so a non-supporting client could still display the text (similar to cleartext email vs opaque). This probably brings a can of canonicalization worms though. > >>=20 >> - Why not include an end point's key in its info results and enable >> return of the encrypted SMK (or even CEK) with the encrypted >> payload (to save a round trip). Given a single message could >> trigger a number of requests for the SMK, the option to include the >> encrypted CEK in the payload may be worthwhile. Including the >> encrypted CEK would help with storage too. > >The encrypted CEK is included in each message with -06. I made this error a couple of times. What I meant was encrypted CEK for a key already held by the end point, to avoid to the need for a round trip to get the SMK, to remove the online requirement for the sender at recipient reading time and to simplify future use of stored encrypted messages. The CEK could also be encrypted under the SMK to bootstrap unknown end points. > >Including an encrypted SMK is a possibility, although I start to worry >about the size of the overall stanza. If it's absolutely known that >the message will be delivered to a single end-point it shouldn't get >too large, but I am assuming that servers will start multiplexing chat >messages (a la [CARBONS]) which means the benefits of including the >encrypted SMK are unrealized if only there's only a single instance of >the encrypted SMK; including multiple SMKs can be very problematic >(e.g., many server deployments reject very large stanzas). Do you know what the threshold is? > >>=20 >>=20 >> - Why is the SID required to be unique for a {sender, recipient, >> SMK} tuple? This would allow for the same SID to be used to name >> every SMK used with a recipient. Suggest unique for each recipient >> (i.e., SMK's are uniquely identified by recipient+SID for a given >> sender). >>=20 > >I'm not sure what you're trying to say here (it could be due to me >responding on the last day of an IETF meeting). Can you provide an >example of what your concern here is? Assume a sender has used two SMKs while communicating with a given recipient: sender+recipient+SMK1 and sender+recipient+SMK2. The current text requires the SID to be unique "for a given (sender, recipient, SMK) tuple=B2. That allows for the same SID to be used for either SMK1 or SMK2. I am suggesting the SID should be unique for each recipient, from a sender=B9s perspective. > >> - Discuss how multiple recipients are handled > >That is a very good point. There is some text there, but it is fairly >weak. I was considering a form of ASCII sequence diagram of the >general flow -- would that better help to explain things? That would help. > >>=20 >> - s/optionallly/optionally >>=20 > >Fixed in working copy. > >> - It would be nice to have a summary of new state information the >> sender and recipient are required to manage (like SMKs) and >> significant new operations (like authorization of key requests >> where a given recipient may use a number of different public keys) > >That is a very good suggestion. Do you think you could provide some >text to get it started? Sure. Will try to send something next week. > >>=20 >> - Should include an example of a reply to an encrypted message. >> Should/must the same SMK be used in replies? >>=20 > >That is not a bad idea. I'll look into it. > >> - Is there any reason pre-placed SMK values cannot be used instead >> of SMK values retrieved automatically from the sender? >>=20 > >Is there any additional concern here beyond the point a few above? No, just looking for another place to not use of a key already know to the receiver. =20 > >> Section 4 - How is the public key used to verify signatures >> published to the recipients? If not included in the payload, >> should be available a la the SMK. This would be useful, at a >> minimum, when the signer uses a certificate from a PKI the >> recipient trusts. >>=20 > >These are good points, and it ought to be included. The JWS structure >does allow for inclusion of the jwk (or jku, or x5c, or x5t, or x5u) >which would be the key used to sign the content. I'll add more >clarity on this point. > >> - s/Playload/payload >>=20 > >Fixed in working copy. > >> - Include some text indicating users MUST be able to determine if >> a message was authenticated >>=20 > >That is a good point. > >> - Should data be presented to the user when the timestamp is not >> acceptable? There are guidelines for invalid signatures, but not >> for unacceptable timestamps. Same comment on 3.3.5 too. >>=20 > >I have been hesitant on dictating what to display to users. I don't >want to tie the hands of implementations, and it's rather difficult to >independently verify that a given implementation complies without some >sort of officiating body (which we definitely don't want). I thought these UI notes were more reminders to developers to make sure user=B9s could determine checks had been performed. > >> - May want to distinguish between successful authentication vs >> successful verification >>=20 > >Noted. > >> Section 5 - Should describe how the entity requesting a key gets >> the SID >>=20 > >I thought I had said that in here, but I'll clarify it further. > >> - Should make it more clear that a new CEK is generated in order >> to encrypt the SMK, then the CEK is encrypted under the public >> key. >>=20 > >You have this reversed: the SMK is used to encrypt the CEK, and the >recipient's public key is used to encrypt the SMK. It is completely >possible that I was not consistent here. I thought when the SMK is communicated to the end point, it is also encrypted under a content encryption key (referred to as a CMK in the text), that is then encrypted using the end point=B9s public key. If that is correct there are four keys at work: the CEK for the stanza (CEK1), the SMK to encrypt the CEK, the CEK to encrypt the SMK (CEK2) and the recipient=B9s public key to encrypt CEK2. > >> Section 9 - The requirement for the sender to be online would seem >> like sufficient grounds for including encrypted CEKs in the >> payload. >>=20 > >Encrypted CEKs are in the payload in -06. I tried to clarify in a reply comment above. This applies to the next few comments too. Read =B3encrypted CEKs=B2 are =B3CEKs encrypted using a key already possessed by the recipient=B2. I think I was consistent in misusing the term =B3encrypted CEKs=B2 in my comments in this way, and introduced the CEK term in my comments where it does not appear in the draft:-) > >> Section 11 - Offline storage may be another reason to include >> encrypted CEKs in a payload. Perhaps the solution should be to >> encrypt for each of a recipient's known keys plus an SMK that could >> be used by end points using a different, >> not-yet-known-to-the-sender key. >>=20 > >You mean encrypted SMKs here. > >One idea that had been discussed outside the meeting was to try and >use [PEP] as a way to do this, but we didn't spend a lot of time >thinking about the mechanics and implications here. > > >> - Need to address authorization for SMK release. >>=20 > >I have pretty much hand-waved over this part. One idea that came to >light this week was to provide fingerprints for the recipients' public >keys, somehow. Suggestions for improvements are welcome. > >> - Include some guidance on SMK lifetime. > >There is *some* guidance in section 11.2, but I admit it is rather >vague. Could you provide more specific suggestions? As above, will try to send some text next week. > > >- --=20 >- - m&m > >Matt Miller < mamille2@cisco.com > >Cisco Systems, Inc. > >[CARBONS] XEP-0280: Message Carbons < >http://xmpp.org/extensions/xep-0280.html > >[MUC] XEP-0045: Multi-User Chat < >http://xmpp.org/extensions/xep-0045.html > >[PEP] XEP-0163: Personal Eventing Protocol < >http://xmpp.org/extensions/xep-0163.html > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG/MacGPG2 v2.0.22 (Darwin) >Comment: GPGTools - https://gpgtools.org >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQEcBAEBCgAGBQJTGawgAAoJEDWi+S0W7cO1Jo4H/R8AvTt1WBMIwvBD1U8JNBaP >M88uMewtHGoQ/NbizCPnNS8DTMQyMxs/z6w66WDBnNNuCFhjqgh5G4X7X9elnFzI >VezIMKsr5Jc6dlN/9jRgWdQtEuqqmuGKfMHaAoNdqph5pP+zWSx5yhMbcb/wN7Uu >6+JdY4GB9Yz3xBrwQTBZnkRqqTKKL34/WoX42j9Vy2JgFLyRMu3xoW6xg99622Ol >VJxXRs7X9uERB0Dn8xTW2NTnRIN82g4WZuuaJLOkGDFQaienaBwQTHhogjaHFcNv >aTCnQhipI8Io4gLdT3uFzn84oZDYhBCSGyclegAXesthI9gnO3I671YUfTJl9xo=3D >=3DG0xx >-----END PGP SIGNATURE----- From nobody Sat Mar 8 02:46:34 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9124D1A016A for ; Sat, 8 Mar 2014 02:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.208 X-Spam-Level: X-Spam-Status: No, score=0.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Ue_cx0jU5dl for ; Sat, 8 Mar 2014 02:46:31 -0800 (PST) Received: from mail.ahsoftware.de (h1446028.stratoserver.net [85.214.92.142]) by ietfa.amsl.com (Postfix) with ESMTP id C31991A0166 for ; Sat, 8 Mar 2014 02:46:30 -0800 (PST) Received: by mail.ahsoftware.de (Postfix, from userid 65534) id 316D4423C297; Sat, 8 Mar 2014 11:46:25 +0100 (CET) Received: from eiche.ahsoftware (p57B20126.dip0.t-ipconnect.de [87.178.1.38]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.ahsoftware.de (Postfix) with ESMTPSA id 6873A423C297 for ; Sat, 8 Mar 2014 11:46:22 +0100 (CET) Received: by eiche.ahsoftware (Postfix, from userid 65534) id 793237FAAE; Sat, 8 Mar 2014 11:46:21 +0100 (CET) Received: from [IPv6:feeb::c685:8ff:fe12:175d] (unknown [IPv6:feeb::c685:8ff:fe12:175d]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by eiche.ahsoftware (Postfix) with ESMTPS id C75AB7F82C; Sat, 8 Mar 2014 10:46:18 +0000 (UTC) Message-ID: <531AF4E8.1040207@ahsoftware.de> Date: Sat, 08 Mar 2014 11:46:00 +0100 From: Alexander Holler User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: kevin@kismith.co.uk, Ashley Ward References: <531883F5.7000800@stpeter.im> <26D173CC-25CE-45AF-8F5A-27AF576558A0@surevine.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/1AahrwTyIlwV8r6btub1gGEGBl0 Cc: XMPP Working Group Subject: Re: [xmpp] message size X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 10:46:32 -0000 Am 06.03.2014 15:49, schrieb Kevin Smith: > On Thu, Mar 6, 2014 at 2:44 PM, Ashley Ward wrote: >> On 6 Mar 2014, at 14:40, Kevin Smith wrote: >>> On Thu, Mar 6, 2014 at 2:35 PM, Ashley Ward wrote: >>>> On 6 Mar 2014, at 14:28, Dave Cridland wrote: >>>> >>>>> You're saying to include, pre-encrypt, something like 123465 in the plaintext order to defeat message size analysis of the ciphertext? >>>> >>>> It's XML - you could always just use comments or whitespace. >>> >>> Comments are slightly problematic, on account of being illegal. >> >> True - I often forget that XMPP isn't entirely XML compliant! > > The stream isn't a real XML document (stream restarts break this) but > not allowing comments doesn't stop it being XML, just a subset. And just using whitespace is the most elegant solution. No necessary changes and no obvious problems. So instead of foobar using foobar or e.g. foobar or something similiar is imho the most preferable way to add unused plaintext. Regards, Alexander Holler From nobody Sat Mar 8 03:11:32 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD051A012A for ; Sat, 8 Mar 2014 03:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00hp-UmFWlvz for ; Sat, 8 Mar 2014 03:11:25 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8239E1A00E8 for ; Sat, 8 Mar 2014 03:11:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=943; q=dns/txt; s=iport; t=1394277081; x=1395486681; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3+eLQRkimcGsPWZyMbbT0VTDo7QsMpzoEu7HGwNoTr0=; b=avGkk7BTumfiRPmIyrOQfcezkD7YKbyUmZAMO9LEuNyJy+b3j+lqNYFS 27fM4xZj9KmNmKo3aIimnOANc6iVFaPDS1SW0KIomnJwEShwO8Wk9rUAe RDN++ILjDpf/63qZ/iZweSXG5HRX8H+8gx2ooFIo9pNN9xLMRsMIQ2t+W 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAAT6GlOtJV2d/2dsb2JhbABagwaBEsJBFnSCLDpRAT5CJwSIDJ8UsF4XkxoElFmDbJIrgy2BayQc X-IronPort-AV: E=Sophos;i="4.97,613,1389744000"; d="scan'208";a="25909189" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP; 08 Mar 2014 11:11:20 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s28BBKub006872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 8 Mar 2014 11:11:20 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.151]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Sat, 8 Mar 2014 05:11:20 -0600 From: "Joe Hildebrand (jhildebr)" To: "xmpp@ietf.org" Thread-Topic: Comments on draft-alkemade-xmpp-iq-validation-00 Thread-Index: AQHPOr8iCz6rRPnJ+kyy0gTn725IaA== Date: Sat, 8 Mar 2014 11:11:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.64.129] Content-Type: text/plain; charset="us-ascii" Content-ID: <2513D56E93E0D846848FFF3EC3598701@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/BiAVk6XDFRIJG0yDc_Il8Gt0QvI Subject: [xmpp] Comments on draft-alkemade-xmpp-iq-validation-00 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 11:11:31 -0000 (no hats) Section 1: suggest s/it was found// Before Section 4: suggest adding some examples in a new section. Good iq/response, spoofed response with different from (perhaps followed by real response to make it clear), unexpected 'from' from the server Section 4: suggest switching the order of 4.1 and 4.2. current section 4.1 is an edge case, leading with the core mechanism is more understandible Section 4.1: quote 6120 and 3920 directly if possible. Section 4.2: we had lots of discussion over "unique". We'll likely want some flavor of that discussion in the final text. For the MUST ignore text, can the client log an error or notify the user? Section 6: we'll likely want some security analysis here. May a server perform this tracking too, and reject things that look like attacks? This doc is a good start. I think we should adopt it into the working group immediately. --=20 Joe Hildebrand From nobody Mon Mar 10 07:51:34 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3893D1A043E for ; Mon, 10 Mar 2014 07:51:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTg_zwv13Z7w for ; Mon, 10 Mar 2014 07:51:31 -0700 (PDT) Received: from mail.zash.se (sphyrna.zash.se [IPv6:2001:470:28:559::]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3F31A0434 for ; Mon, 10 Mar 2014 07:51:31 -0700 (PDT) Received: from [IPv6:2001:16d8:ffc6:0:b1f7:63b9:e8ad:8e70] (unknown [IPv6:2001:16d8:ffc6:0:b1f7:63b9:e8ad:8e70]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: zash) by mail.zash.se (Postfix) with ESMTPSA id 5F56260C58 for ; Mon, 10 Mar 2014 15:51:25 +0100 (CET) Message-ID: <531DD16C.2000204@zash.se> Date: Mon, 10 Mar 2014 15:51:24 +0100 From: Kim Alvefur User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP WG References: <531DD129.9020305@zash.se> In-Reply-To: <531DD129.9020305@zash.se> X-Enigmail-Version: 1.6 OpenPGP: id=B67AD329; url=http://zash.se/~zash/pubkey.asc X-Forwarded-Message-Id: <531DD129.9020305@zash.se> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="LP336Q9bG2VHQT0mfsjb7xlPIAP1eNt6c" Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Mj_mtxs4-TJYYQcyWFFapyIKspM Subject: [xmpp] Fwd: [dane] DANE XMPP s2s implementation X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 14:51:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LP336Q9bG2VHQT0mfsjb7xlPIAP1eNt6c Content-Type: multipart/mixed; boundary="------------060005000006040507060506" This is a multi-part message in MIME format. --------------060005000006040507060506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Also relevant here. -------- Original Message -------- Subject: [dane] DANE XMPP s2s implementation Date: Mon, 10 Mar 2014 15:50:17 +0100 From: Kim Alvefur To: DANE WG Hi, Everyone back (and recovered) from IETF89? Much interesting, such people, very discussions, wow. So I have an experimental DANE implementation for server-to-server connections in the Prosody XMPP server. It's currently only doing DANE-EE and PKIX-EE. The TA variants are trickier, especially DANE-TA, so I have left them out for now. LuaSec, the OpenSSL to Lua binding we use, doesn't currently expose anything for validating some random chain. It also includes an attempt at doing something for authenticating the client certificate on incoming connections, by looking for a TLSA record at the same name as for SRV, eg _xmpp-server._tcp.example.com. Comments about this would be appreciated. Info: http://code.google.com/p/prosody-modules/wiki/mod_s2s_auth_dane Code: http://code.google.com/p/prosody-modules/source/browse/mod_s2s_auth_dane/= mod_s2s_auth_dane.lua -- Regards, Kim "Zash" Alvefur --------------060005000006040507060506 Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Attached Message Part" _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane --------------060005000006040507060506-- --LP336Q9bG2VHQT0mfsjb7xlPIAP1eNt6c 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/ iQIcBAEBCAAGBQJTHdFsAAoJEK3tmne2etMp6rcP/ie24jKG86zUaH3FAmi6L3Pg oRnYHxa92n3rxi05rMAxoyVMvllMKWMNFI55TUxoiKov2sOX6TKpGquW4TxGm6Xc o0wmcrJ338qVchppN+DidjSAOYMjAiHc7MqhH3ipLRptaGub/IJrE1EZGNF4ZbRN QBTB/yttKHcK2KKj7/dEydoKkJX8GWCt7TV6DrV1cwAAlYKIB3cVoT+cryR96ysX XX74wklaRyKcLEnAiEC/6vZjEpIb6G+3jF0ckyohNAYV2QUsPAJaX/W2ZK0Qb6jW SUk82lfnMnWA14VzpB3mmpJb4VBcneCgaBh8FHdbtcYU2hrDeZcy0kROng+rCOkE cD/KDPJQMB0gFi8dXswe6DDqeVM/Dy7bm853+orybCYr8UztsEV1ekpbIzgcWmPi GFQO0ukaj19YEYFb65xv71BBlXYLNHz3iEtS9+KtpjGYsFUdHKKYBQ/Rftzo3Y2Z 6XVioyB43peGMneRC7b7UbQIePbzg9Rjmt5U+GMW+rek+9mevECCq0UWdGfIJbgh cB/yDpSow5b5FwfDkkdyiBDcusohyRLETydWZyYKLEEB3LyZY4lt3GXFVH6PdEgI V/dxeLNvXxGizYJMHFQA1xLfMZprJorWKZyb5h6OzL7D9pwN5c0cFuKarcdcZDhB svNCWqRFmhSVlVThoRd9 =oWlp -----END PGP SIGNATURE----- --LP336Q9bG2VHQT0mfsjb7xlPIAP1eNt6c-- From nobody Mon Mar 10 11:15:29 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445D11A04E7 for ; Mon, 10 Mar 2014 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EhSG2qzbK45 for ; Mon, 10 Mar 2014 11:15:15 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E2A3F1A0691 for ; Mon, 10 Mar 2014 11:15:14 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0BD12404DE; Mon, 10 Mar 2014 12:15:08 -0600 (MDT) Message-ID: <531E012B.6060406@stpeter.im> Date: Mon, 10 Mar 2014 12:15:07 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP Working Group References: <20140310161350.GW21390@mournblade.imrryr.org> In-Reply-To: <20140310161350.GW21390@mournblade.imrryr.org> X-Forwarded-Message-Id: <20140310161350.GW21390@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/Gr5wgkcdqXz4wnqkfGFaYYM0ft0 Subject: [xmpp] Fwd: Re: [dane] DANE XMPP s2s implementation X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 18:15:24 -0000 FYI from the DANE list. Discussion here seems appropriate. -------- Original Message -------- Subject: Re: [dane] DANE XMPP s2s implementation Date: Mon, 10 Mar 2014 16:13:50 +0000 From: Viktor Dukhovni Reply-To: dane@ietf.org To: dane@ietf.org On Mon, Mar 10, 2014 at 03:50:17PM +0100, Kim Alvefur wrote: > It's currently only doing DANE-EE and PKIX-EE. I would recommend that, as with the SMTP draft, the XMPP community choose a subset of the DANE usages to support. Either 0/1 or 2/3, but not both. By choosing both you get the weakest security, and the maximal deployment friction (everyone needs to deploy and trust the same set of CAs). So it makes more sense to implement just one of DANE-EE or PKIX-EE, with a plan to later add one of DANE-TA or PKIX-TA respectively. > The TA variants are > trickier, especially DANE-TA, so I have left them out for now. Indeed, especially for DANE-TA, it makes sense to wait until the underlying TLS toolkits: OpenSSL, NSS, GnuTLS, ... support DANE trust chain verification and name checks (integrated with trust validation because DANE-EE obviates name checks, while DANE-TA requires them). Though IIRC the XMPP draft currently just defers all the DANE language to the SRV draft, it may at some point make sense to be more explicit about XMPP-specific choices, unless the SRV draft is modified to define a set of profiles, one of which exactly matches the requirements of XMPP. > It also includes an attempt at doing something for authenticating the > client certificate on incoming connections, by looking for a TLSA record > at the same name as for SRV, eg _xmpp-server._tcp.example.com. Comments > about this would be appreciated. I encourage you to discuss this with the XMPP draft authors, I asked this very question informally and was told that client certificate verification was somehow accomplished via callbacks. If it is reasonable to require the outbound XMPP clients for a domain to possess the same private keys and certificates as the inbound servers, then your approach may reasonable. Though you likely end up taking the union of the TLSA records for all servers, rather than just the specific server you connect to when validating a connection to a server. I would suggest a less ad-hoc strategy for authenticating clients, perhaps a lookup key for TLSA records at: _xmpp-client.example.com IN TLSA ... if client certificates are to be used with XMPP to authenticate the client domain. (Neither _port nor _proto make much sense for clients, the client is not a fixed transport end-point). -- Viktor. _______________________________________________ dane mailing list dane@ietf.org https://www.ietf.org/mailman/listinfo/dane From nobody Mon Mar 10 13:04:12 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1AC1A03FC for ; Mon, 10 Mar 2014 13:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik3aJGbSmdlr for ; Mon, 10 Mar 2014 13:04:07 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 304DC1A024B for ; Mon, 10 Mar 2014 13:04:07 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9CF3C404DE; Mon, 10 Mar 2014 14:04:01 -0600 (MDT) Message-ID: <531E1AB0.30307@stpeter.im> Date: Mon, 10 Mar 2014 14:04:00 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: XMPP Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/fTgsXncfHCxZvjpKou1B4s3kDh4 Subject: [xmpp] XMPP over WebSocket schemas X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 20:04:08 -0000 As noted during the working group session last week, there's a small copy-and-paste error in the schema for the element: the see-other-uri attribute is allowed only on the element. Thus... OLD NEW Also, I'm wondering if we want to say that the 'id' attribute should be included on the element. Peter From nobody Fri Mar 14 06:19:42 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95E81A0145 for ; Fri, 14 Mar 2014 06:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG4cNdiZMs0r for ; Fri, 14 Mar 2014 06:19:39 -0700 (PDT) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1122D1A013D for ; Fri, 14 Mar 2014 06:19:38 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id j5so7341291qga.4 for ; Fri, 14 Mar 2014 06:19:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=j8RatKb/DQmuVbAAT0B/88/xuipP97lDaz0JqQZJa7U=; b=ZA6pEvfvhYgmxuK0RG4OrCrlhvcIgbPN3lpLPp0le028BTu5vRMYwS/W6hSxNQc5ju zuWiEZ58jTEQ405NWQIjVjkYrHwTepVp/n015SKPB5PHDDiP6jXOQ4/6cDMDEJw6t2T2 xxuPIWykkceY85TDj9OEHVNcY0zFoKoLxebMBTQN8fAwf6tgmIXTsOhQLkY93P3jxvK1 l1QZPnq5lgyJkWpKpwdXgRL4oXwT82MNa/j5rL1kQx8dR0xyv04mDxqnKzi0orIjF5nH cWY1A5ixQmFKaTRyZkwZ9En+gqGzkxLHQKOmQUJtPHzIxSdWeBdUtpAhFtRx1ZNFSKMN 5nHQ== X-Gm-Message-State: ALoCoQmHkhVzrhe38RrCoDhjMWDqtTaFuCk1Dp17bv17P6R47DfWXZ7gaD2zXEGw1Vz1a2HNUP4N X-Received: by 10.224.11.10 with SMTP id r10mr3469225qar.8.1394803172076; Fri, 14 Mar 2014 06:19:32 -0700 (PDT) Received: from [192.168.2.4] (pool-173-79-106-67.washdc.fios.verizon.net. [173.79.106.67]) by mx.google.com with ESMTPSA id s6sm16038344qad.22.2014.03.14.06.19.29 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 14 Mar 2014 06:19:31 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.3.9.131030 Date: Fri, 14 Mar 2014 09:19:25 -0400 From: Carl Wallace To: Matt Miller , Message-ID: Thread-Topic: [xmpp] comments on draft-miller-xmpp-e2e-06 References: <5319AC20.4090906@cisco.com> In-Reply-To: <5319AC20.4090906@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/HPh1C1BjBVNY2UCzzqwMvASzSbQ Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 13:19:41 -0000 On 3/7/14, 6:23 AM, "Matt Miller" wrote: > >> - It would be nice to have a summary of new state information the >> sender and recipient are required to manage (like SMKs) and >> significant new operations (like authorization of key requests >> where a given recipient may use a number of different public keys) > >That is a very good suggestion. Do you think you could provide some >text to get it started? Here=B9s some text as a starting point: Existing XMPP clients will need to maintain additional state information and incorporate new user interfaces to support end-to-end encryption and authentication. Changes for sending clients include: - Generate session master keys (SMKs) - Store SMKs for use during active sessions - Store SMKs to provide to peers and to support reading of saved messages (may require use of storage key) - Accept requests for SMKs - Release SMKs to authorized requestors (where SMK may be requested from multiple resources each using different means to authenticate) - Generate content encryption keys (CEK) - Use SMK and CEK values to encrypt XMPP stanzas - Generate signing key (optional) - Use signing key to sign XMPP stanzas Changes for receiving clients include: - Send request for SMK to peers - Store SMK for use during active session - Use SMK to decrypt CEK used to decrypt XMPP stanzas - Store session master keys retrieved from peers to support reading of saved messages (may require use of storage key) - Provide indication to users when encryption is in use - Retrieve keys required to verify signatures on signed XMPP stanzas - Verify signatures and display indication of success/failure to user - Store keys required to verify signature to support reading of saved messages (may require use of storage key) >> >>- Include some guidance on SMK lifetime. > >There is *some* guidance in section 11.2, but I admit it is rather >vague. Could you provide more specific suggestions? I did not generate any text for this yet because the use of SMKs still seems unsettled to me. Some issues: - including a CEK encrypted for each known end point key plus under an SMK potentially exceeds size threshold used by some servers - having each end-point request SMKs from the sender generates additional traffic - a sender that communicates with a large number of peers must maintain a large SMK database for an undetermined period of time - the sender must be available for a recipient to decrypt messages sent under an SMK that has not previously been retrieved (this is possibly not acceptable for all cases where XMPP may be used) - SMK usage complicates storage of encrypted messages (recipients could re-encrypt the CEK under a storage key or maintain a database of encrypted SMKs) From nobody Fri Mar 14 09:51:59 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0B5A1A017D; Fri, 14 Mar 2014 09:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_PqSIWmgg9B; Fri, 14 Mar 2014 09:51:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 319A41A00F1; Fri, 14 Mar 2014 09:51:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.1.0p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140314165151.22882.69098.idtracker@ietfa.amsl.com> Date: Fri, 14 Mar 2014 09:51:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/o783khzbmjP9p60N3ym4cPCK4hk Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-websocket-02.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 16:51:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : An XMPP Sub-protocol for WebSocket Authors : Lance Stout Jack Moffitt Eric Cestari Filename : draft-ietf-xmpp-websocket-02.txt Pages : 13 Date : 2014-03-14 Abstract: This document defines a binding for the XMPP protocol over a WebSocket transport layer. A WebSocket binding for XMPP provides higher performance than the current HTTP binding for XMPP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-websocket-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-websocket-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 17 12:50:51 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DEF1A0436 for ; Mon, 17 Mar 2014 12:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVjpBi_f6hx6 for ; Mon, 17 Mar 2014 12:50:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF91A0200 for ; Mon, 17 Mar 2014 12:50:46 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2HJoVP3086804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Mar 2014 14:50:33 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell Date: Mon, 17 Mar 2014 14:50:32 -0500 X-Mao-Original-Outgoing-Id: 416778632.574216-b914a5fcd20b4a1564d715c519309937 Content-Transfer-Encoding: quoted-printable Message-Id: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/3sMLbhfrHvD_Jqp3xD7GRblEiUM Subject: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11 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, 17 Mar 2014 19:50:49 -0000 This is a Working Group Last Call of draft-ietf-xmpp-6122bis-11. The = draft is available at the following URL: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-11 The WGLC will conclude on 31 March, 2014. Please send your comments to = the authors and the XMPP mailing list. Thanks! Ben. From nobody Tue Mar 18 14:00:08 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 033131A01A5 for ; Tue, 18 Mar 2014 14:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbSKBskAOtul for ; Tue, 18 Mar 2014 14:00:04 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 37FE01A0125 for ; Tue, 18 Mar 2014 14:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12406; q=dns/txt; s=iport; t=1395176396; x=1396385996; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=D9mpUbURytiDmWQ286oSubJt1q75au3GHFGfGSQZGJw=; b=OfSV6MExd2VwiUht3YDDwVQE3IqnjRLtTgoYWE816Qi0PzsWzPJLnA8Y E0y8m6S44DglZNcc5hM+og56wx3EmfOMWktkukCodJ5DviDpKX0Dz91e5 GMVSBPV05hWVe4HzOLHeNZY4yImYEQMPWe51NyYALoM3P6bOJz4T5g6VL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQLALKyKFOtJXHA/2dsb2JhbABagwY7V6kRBJkOgS4WdIIlAQEBBDIBRRELGAkWDwkDAgECAUUGAQwGAgEBF4de0DsXjgALBgEHFjqEOAEDiRo4iwiDbJIwg0yBSwgXIg X-IronPort-AV: E=Sophos;i="4.97,680,1389744000"; d="scan'208";a="28457076" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 18 Mar 2014 20:59:55 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2IKxttY015349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Mar 2014 20:59:55 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 18 Mar 2014 15:59:54 -0500 Message-ID: <5328B3CB.5080501@cisco.com> Date: Tue, 18 Mar 2014 14:59:55 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carl Wallace , References: <5319AC20.4090906@cisco.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/cb6F7b2eYZitpxitkOIdbKnyRQQ Subject: Re: [xmpp] comments on draft-miller-xmpp-e2e-06 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 21:00:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/7/14, 5:28 AM, Carl Wallace wrote: > > > On 3/7/14, 6:23 AM, "Matt Miller" wrote: > > Thank you very much for the feedback! > > I'll incorporate your suggestions as soon as I can. > > On 3/6/14, 3:12 PM, Carl Wallace wrote: >>>> Section 1 - This may be in the reqs draft, but seems worth >>>> stating here that some end points for a given recipient may >>>> share keys, some may use different keys, some may have no >>>> keys and some may not support encryption or signature >>>> verification at all. >>>> > > We did discuss reviving the e2e-reqs draft in the WG session on > Tuesday, but it would be important to include this. > >> Itıs also worth noting the sender may have multiple end points >> with the same properties. If the same SMK were used in replies, >> it creates kind of a odd scenario where both parties could be >> providing the SMK for the asking. > Good point. > >>>> Section 3 - What should the sender do if some end points for >>>> a recipient indicate lack of support for encryption? Are >>>> error responses helpful independent of confirmation that some >>>> end points support encryption? Is the intent for messages to >>>> only be sent to end points that advertise support? > > There is little (read: nothing) that can be said on what existing > "legacy" end-points ought to do. I tried to say something on what > existing clients already do, to the best of my knowledge. Many > (most) drop anything they don't understand, so getting errors could > very well be impossible unless the applications were specifically > updated to "anti-support" this specification. It's also possible > I'm missing the point here, too (-: > > The intention is not for the sending end-point to only send to > other supporting end-points. Indeed, I want this to be compatible > with [CARBONS] and [MUC] where the possible. To that end, most > clients try to do something if there is a body, and this document > could suggest that sending end-points include an appropriate > generic "this message is protected" body. > >> Iıve not yet looked, but I had wondered if it would be possible >> to define the signature format so a non-supporting client could >> still display the text (similar to cleartext email vs opaque). >> This probably brings a can of canonicalization worms though. > There is an XSF XEP that covers this using a different technology, and calls it opportunistic signatures. My experience has been that opportunistic signatures opens a very large can of worms, which is why I avoided it in my draft. There are additional considerations for s, since the expectation is for there to be a single child element (except for type='error', where there is also an in the parent's namespace). We could decide to remove signatures from this draft almost entirely, and leave it as someone else's exercise to deal with in the general case. In this scenario, I envision keeping some form of signature is to aid in authenticating PFS key exchanges, but then it can be specific to the keyreq then. > >>>> >>>> - Why not include an end point's key in its info results and >>>> enable return of the encrypted SMK (or even CEK) with the >>>> encrypted payload (to save a round trip). Given a single >>>> message could trigger a number of requests for the SMK, the >>>> option to include the encrypted CEK in the payload may be >>>> worthwhile. Including the encrypted CEK would help with >>>> storage too. > > The encrypted CEK is included in each message with -06. > >> I made this error a couple of times. What I meant was encrypted >> CEK for a key already held by the end point, to avoid to the need >> for a round trip to get the SMK, to remove the online requirement >> for the sender at recipient reading time and to simplify future >> use of stored encrypted messages. The CEK could also be >> encrypted under the SMK to bootstrap unknown end points. > > > Including an encrypted SMK is a possibility, although I start to > worry about the size of the overall stanza. If it's absolutely > known that the message will be delivered to a single end-point it > shouldn't get too large, but I am assuming that servers will start > multiplexing chat messages (a la [CARBONS]) which means the > benefits of including the encrypted SMK are unrealized if only > there's only a single instance of the encrypted SMK; including > multiple SMKs can be very problematic (e.g., many server > deployments reject very large stanzas). > >> Do you know what the threshold is? The threshold is different for different deployments /-: There are some without any limit, which means the system crashes if it runs out of memory trying to deal with an extremely large stanza. Another I'm aware of has a limit of 40KB, and will drop the connection on anything bigger. I don't know how common any particular limit is, though. And worse, there's no real way to detect prior to trying. > > >>>> >>>> >>>> - Why is the SID required to be unique for a {sender, >>>> recipient, SMK} tuple? This would allow for the same SID to >>>> be used to name every SMK used with a recipient. Suggest >>>> unique for each recipient (i.e., SMK's are uniquely >>>> identified by recipient+SID for a given sender). >>>> > > I'm not sure what you're trying to say here (it could be due to me > responding on the last day of an IETF meeting). Can you provide > an example of what your concern here is? > >> Assume a sender has used two SMKs while communicating with a >> given recipient: sender+recipient+SMK1 and sender+recipient+SMK2. >> The current text requires the SID to be unique "for a given >> (sender, recipient, SMK) tuple². That allows for the same SID to >> be used for either SMK1 or SMK2. I am suggesting the SID should >> be unique for each recipient, from a senderıs perspective. > > I see your point now. >>>> - Discuss how multiple recipients are handled > > That is a very good point. There is some text there, but it is > fairly weak. I was considering a form of ASCII sequence diagram of > the general flow -- would that better help to explain things? > >> That would help. > > >>>> >>>> - s/optionallly/optionally >>>> > > Fixed in working copy. > >>>> - It would be nice to have a summary of new state information >>>> the sender and recipient are required to manage (like SMKs) >>>> and significant new operations (like authorization of key >>>> requests where a given recipient may use a number of >>>> different public keys) > > That is a very good suggestion. Do you think you could provide > some text to get it started? > >> Sure. Will try to send something next week. > > >>>> >>>> - Should include an example of a reply to an encrypted >>>> message. Should/must the same SMK be used in replies? >>>> > > That is not a bad idea. I'll look into it. > >>>> - Is there any reason pre-placed SMK values cannot be used >>>> instead of SMK values retrieved automatically from the >>>> sender? >>>> > > Is there any additional concern here beyond the point a few above? > >> No, just looking for another place to not use of a key already >> know to the receiver. > > >>>> Section 4 - How is the public key used to verify signatures >>>> published to the recipients? If not included in the >>>> payload, should be available a la the SMK. This would be >>>> useful, at a minimum, when the signer uses a certificate from >>>> a PKI the recipient trusts. >>>> > > These are good points, and it ought to be included. The JWS > structure does allow for inclusion of the jwk (or jku, or x5c, or > x5t, or x5u) which would be the key used to sign the content. I'll > add more clarity on this point. > >>>> - s/Playload/payload >>>> > > Fixed in working copy. > >>>> - Include some text indicating users MUST be able to >>>> determine if a message was authenticated >>>> > > That is a good point. > >>>> - Should data be presented to the user when the timestamp is >>>> not acceptable? There are guidelines for invalid signatures, >>>> but not for unacceptable timestamps. Same comment on 3.3.5 >>>> too. >>>> > > I have been hesitant on dictating what to display to users. I > don't want to tie the hands of implementations, and it's rather > difficult to independently verify that a given implementation > complies without some sort of officiating body (which we definitely > don't want). > >> I thought these UI notes were more reminders to developers to >> make sure userıs could determine checks had been performed. > I'm sure we can come up with something that's not exactly normative language. > >>>> - May want to distinguish between successful authentication >>>> vs successful verification >>>> > > Noted. > >>>> Section 5 - Should describe how the entity requesting a key >>>> gets the SID >>>> > > I thought I had said that in here, but I'll clarify it further. > >>>> - Should make it more clear that a new CEK is generated in >>>> order to encrypt the SMK, then the CEK is encrypted under the >>>> public key. >>>> > > You have this reversed: the SMK is used to encrypt the CEK, and > the recipient's public key is used to encrypt the SMK. It is > completely possible that I was not consistent here. > >> I thought when the SMK is communicated to the end point, it is >> also encrypted under a content encryption key (referred to as a >> CMK in the text), that is then encrypted using the end pointıs >> public key. If that is correct there are four keys at work: the >> CEK for the stanza (CEK1), the SMK to encrypt the CEK, the CEK to >> encrypt the SMK (CEK2) and the recipientıs public key to encrypt >> CEK2. > You are absolutely correct; sorry for my own confuzzlement! > >>>> Section 9 - The requirement for the sender to be online would >>>> seem like sufficient grounds for including encrypted CEKs in >>>> the payload. >>>> > > Encrypted CEKs are in the payload in -06. > >> I tried to clarify in a reply comment above. This applies to the >> next few comments too. Read ³encrypted CEKs² are ³CEKs encrypted >> using a key already possessed by the recipient². I think I was >> consistent in misusing the term ³encrypted CEKs² in my comments >> in this way, and introduced the CEK term in my comments where it >> does not appear in the draft:-) > > > >>>> Section 11 - Offline storage may be another reason to >>>> include encrypted CEKs in a payload. Perhaps the solution >>>> should be to encrypt for each of a recipient's known keys >>>> plus an SMK that could be used by end points using a >>>> different, not-yet-known-to-the-sender key. >>>> > > You mean encrypted SMKs here. > > One idea that had been discussed outside the meeting was to try > and use [PEP] as a way to do this, but we didn't spend a lot of > time thinking about the mechanics and implications here. > > >>>> - Need to address authorization for SMK release. >>>> > > I have pretty much hand-waved over this part. One idea that came > to light this week was to provide fingerprints for the recipients' > public keys, somehow. Suggestions for improvements are welcome. > >>>> - Include some guidance on SMK lifetime. > > There is *some* guidance in section 11.2, but I admit it is rather > vague. Could you provide more specific suggestions? > >> As above, will try to send some text next week. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTKLPLAAoJEDWi+S0W7cO1L3IH/igYVs7+S4bJACRXkzVqUDqr AUiIg/Ply3x04Cf06O0oCmRmfdxe9GhNv3CRbs07tETihZY31PV0Nez+BkHkVpN2 jcTE2ACDYbChGZAb55F8ThBNHWuDZfKJuRN0F+Elfckl9GVkCuwDiGj9TPLXvnbS 1KUdoFr0OQSwF8qaLMPdX3N/1/7srTmM84bkHL0RYpT4sihlzbWwYydr0/NKYSqy L1Zn33Yw8RQpKjrtqOw5I7CrhN/qTytTD6srZNnqR/W68+MmDfb1y4RYfqnYX8Qy NPuDdk/hME42hSkUoJqSGEKez0iClmSTakNserA3vjl6cn3cRUYZWRzoKBk43vI= =36MU -----END PGP SIGNATURE----- From nobody Fri Mar 21 11:39:34 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244BF1A0A16 for ; Fri, 21 Mar 2014 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYKYAqdRnUqk for ; Fri, 21 Mar 2014 11:39:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B071A0A01 for ; Fri, 21 Mar 2014 11:39:31 -0700 (PDT) Received: from [172.20.10.9] (mobile-166-147-071-120.mycingular.net [166.147.71.120]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2LIdJ9e083342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 21 Mar 2014 13:39:21 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-147-071-120.mycingular.net [166.147.71.120] claimed to be [172.20.10.9] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> Date: Fri, 21 Mar 2014 13:39:13 -0500 X-Mao-Original-Outgoing-Id: 417119953.191491-f7fddc1a776fdc621683b351e758604c Content-Transfer-Encoding: quoted-printable Message-Id: <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/wyzC37UGRTZAvzLzLyjaZ7p3pTg Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 18:39:33 -0000 Just a reminder, there's a little more than a week left in this WGLC. If = people have sent comments so far, I have not seen them. Thanks! Ben. On Mar 17, 2014, at 2:50 PM, Ben Campbell wrote: > This is a Working Group Last Call of draft-ietf-xmpp-6122bis-11. The = draft is available at the following URL: >=20 > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-11 >=20 > The WGLC will conclude on 31 March, 2014. Please send your comments to = the authors and the XMPP mailing list. >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp From nobody Tue Mar 25 12:59:01 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B05D1A01DD for ; Tue, 25 Mar 2014 12:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOwV9cgxmZpg for ; Tue, 25 Mar 2014 12:58:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B976B1A00BE for ; Tue, 25 Mar 2014 12:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2047; q=dns/txt; s=iport; t=1395777518; x=1396987118; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+HqTlFHC8FJc8KqzLXrZKv6eDA1qZGjPYNkJSN3rqJQ=; b=gZQgQB0MKM/vMFOFa9XYnhQ4w/ZwFtoOwoatB2TLp/gEvbWaP1oKEkZ8 Nb4iNkAzg7IH1V95a/bm6+j7nBw0iGHvrpJYWxiU8ae7oRFqCxxmdz6D4 p6DC/qZMFCh6aEMn0pFMZYTowZhQ0ikFRsoiZcqHr85I2eJKmhv44LDZX 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQJAK/eMVOtJXHB/2dsb2JhbABZgwY7V6lXBJkRgR0WdIImAQEEeBELIRYPCQMCAQIBRQYNBgIBAYd1z3UXjjs6hDgBA4kaOI57kjKDTYIM X-IronPort-AV: E=Sophos;i="4.97,730,1389744000"; d="scan'208";a="309778381" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 25 Mar 2014 19:58:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s2PJwbem009468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 19:58:37 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 14:58:37 -0500 Message-ID: <5331DFEC.4030900@cisco.com> Date: Tue, 25 Mar 2014 13:58:36 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: XMPP Working Group References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> In-Reply-To: <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ZBYzoGHvdVYDHtwOAAMnx2Jclco Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 19:58:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've finished reviewing draft-ietf-xmpp-6122bis-11. I mostly think this document is ready to be published. I think it deals with the internationalization issues at hand as well as can be expected. However, in 3.2. Domainpart, I wonder about the following: 4. So-called "additional mappings" MAY be applied to the domainpart, such as those defined in [I-D.ietf-precis-mappings] or [RFC5895]. As far as I can tell, just about all of the suggested mappings from RFC5895 are already required here. But for any that are not, I worry about the potential for interoperability problems if say two servers communicating with each other apply different mappings. It might be best to strike this bullet from the list. Less concerning to me is in 3.3. Localpart: 2. So-called "additional mappings" MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. I think there is less concern about interoperability problems here, but I wonder if it is of any real utility. The similar language in 3.4. Resourcepart is not concerning to me at all; there are some cases where additional mappings are desirable (e.g., MUC nicknames), and I think the language makes it clear that anything beyond "it's opaque" is to be approached with care. Thoughts? - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTMd/sAAoJEDWi+S0W7cO12V4IAIShHIc39J0+4TcruXwFGuNi bKV+ZrJnsTD7MYmv7uA/xorVdcjUofBJGaonpH6Fiev6ZYhgai34IuzrgtpPx6XF VtYjNOuV+2eyMT6HTuI7lilC6CtzaG2L/063GlvBL31ttSxjtbK9yb647aPyrTPc qGFEB3PHGjuZC/zcgyUkEj6N1X0Mc+1KpjGiBd6Kl6X6X4mh9blvfLlX2ryPPQvd IMD+VWb6W3fQ/gI6AN7wuUo0zQArJwjIoSDBv82ZR60WIbQyQ1EZY7PRVV5ZiDD8 ErvCB1S1whthYoVdJdqa/GZPduiZtTKsyuz66v4Ecgj0dV8ypK9cWIgv/fO6hEI= =lrlV -----END PGP SIGNATURE----- From nobody Tue Mar 25 13:16:50 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAF11A01F4 for ; Tue, 25 Mar 2014 13:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hjHoE4EZ9i-o for ; Tue, 25 Mar 2014 13:16:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8CA1A01F8 for ; Tue, 25 Mar 2014 13:16:47 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 12E7A4010C; Tue, 25 Mar 2014 14:16:46 -0600 (MDT) Message-ID: <5331E42D.6020501@stpeter.im> Date: Tue, 25 Mar 2014 14:16:45 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Matt Miller , XMPP Working Group References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> <5331DFEC.4030900@cisco.com> In-Reply-To: <5331DFEC.4030900@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/bF4mvwvR6IFhpSXRj9KsJn-DO68 Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 20:16:49 -0000 On 3/25/14, 1:58 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > I've finished reviewing draft-ietf-xmpp-6122bis-11. I mostly think > this document is ready to be published. I think it deals with the > internationalization issues at hand as well as can be expected. > > However, in 3.2. Domainpart, I wonder about the following: > > 4. So-called "additional mappings" MAY be applied to the domainpart, > such as those defined in [I-D.ietf-precis-mappings] or [RFC5895]. > > As far as I can tell, just about all of the suggested mappings from > RFC5895 are already required here. But for any that are not, I worry > about the potential for interoperability problems if say two servers > communicating with each other apply different mappings. It might be > best to strike this bullet from the list. Yes, I think you are right that it would be best to remove this step. While updating draft-ietf-precis-saslprepbis last night, I removed any mention of additional mappings from the password algorithm, for similar reasons. > Less concerning to me is in 3.3. Localpart: > > 2. So-called "additional mappings" MAY be applied, such as those > defined in [I-D.ietf-precis-mappings]. > > I think there is less concern about interoperability problems here, > but I wonder if it is of any real utility. In saslprepbis, we've changed the username text to read: 3. So-called additional mappings MAY be applied, such as mapping of delimiters (e.g., characters such as '@', ':', '/', '+', and '-') and special handling of certain characters or classes of characters (e.g., mapping of non-ASCII spaces to ASCII space or mapping of control characters to nothing); the PRECIS mappings document [I-D.ietf-precis-mappings] describes such mappings in more detail. However, that kind of mapping doesn't apply to XMPP localparts because we profile the PRECIS IdentifierClass, which prohibits punctuation and space characters outside the ASCII7 range, control characters, etc. So IMHO it's unnecessary for localparts. > The similar language in 3.4. Resourcepart is not concerning to me at > all; there are some cases where additional mappings are desirable > (e.g., MUC nicknames), and I think the language makes it clear that > anything beyond "it's opaque" is to be approached with care. Agreed, although I'd change the bullet to mostly or entirely match what I added to draft-ietf-precis-saslprepbis. Peter From nobody Tue Mar 25 13:26:07 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0811A0239 for ; Tue, 25 Mar 2014 13:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Sje8NAJuGY8 for ; Tue, 25 Mar 2014 13:26:01 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDDD1A0245 for ; Tue, 25 Mar 2014 13:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3408; q=dns/txt; s=iport; t=1395779159; x=1396988759; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=eNjlsc6HI1C2FYBxSyWBAIBMrTZfOPg5jJuNCd2TMhg=; b=lgbE7/Nzu6laYlmDcuk9Ihf+uxNU0dlm67lgS/HjPtDkmehONg90MB86 xCs7sOOpKHGXGh14JOdX+OhMoEGE/2cyxL1WoXo+rJE8Poxkocx5KCSV4 4+Ef2itWeFcq+tFfjz9G9Is1qrciiVwtxcUH50kPyi0DzWS+42WzdXec0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUJABnmMVOtJV2a/2dsb2JhbABZgwY7V6lXBJkRgR0WdIIlAQEBAwF4EQsYCQ8HDwkDAgECAUUGAQwGAgEBh20Iz3oXjjs6GIQgAQOJGjiOe5Iyg02CDA X-IronPort-AV: E=Sophos;i="4.97,730,1389744000"; d="scan'208";a="30311042" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 25 Mar 2014 20:25:46 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s2PKPkpu021506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 20:25:46 GMT Received: from MAMILLE2-M-T03K.local (64.101.72.44) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 15:25:46 -0500 Message-ID: <5331E64A.5080909@cisco.com> Date: Tue, 25 Mar 2014 14:25:46 -0600 From: Matt Miller User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Peter Saint-Andre , XMPP Working Group References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> <5331DFEC.4030900@cisco.com> <5331E42D.6020501@stpeter.im> In-Reply-To: <5331E42D.6020501@stpeter.im> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [64.101.72.44] Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/gv4Js1JR3VYzGN0zuC2ueKUBM5E Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 20:26:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 3/25/14, 2:16 PM, Peter Saint-Andre wrote: > On 3/25/14, 1:58 PM, Matt Miller wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> I've finished reviewing draft-ietf-xmpp-6122bis-11. I mostly >> think this document is ready to be published. I think it deals >> with the internationalization issues at hand as well as can be >> expected. >> >> However, in 3.2. Domainpart, I wonder about the following: >> >> 4. So-called "additional mappings" MAY be applied to the >> domainpart, such as those defined in [I-D.ietf-precis-mappings] >> or [RFC5895]. >> >> As far as I can tell, just about all of the suggested mappings >> from RFC5895 are already required here. But for any that are >> not, I worry about the potential for interoperability problems if >> say two servers communicating with each other apply different >> mappings. It might be best to strike this bullet from the list. > > Yes, I think you are right that it would be best to remove this > step. While updating draft-ietf-precis-saslprepbis last night, I > removed any mention of additional mappings from the password > algorithm, for similar reasons. > >> Less concerning to me is in 3.3. Localpart: >> >> 2. So-called "additional mappings" MAY be applied, such as >> those defined in [I-D.ietf-precis-mappings]. >> >> I think there is less concern about interoperability problems >> here, but I wonder if it is of any real utility. > > In saslprepbis, we've changed the username text to read: > > 3. So-called additional mappings MAY be applied, such as mapping > of delimiters (e.g., characters such as '@', ':', '/', '+', and > '-') and special handling of certain characters or classes of > characters (e.g., mapping of non-ASCII spaces to ASCII space or > mapping of control characters to nothing); the PRECIS mappings > document [I-D.ietf-precis-mappings] describes such mappings in more > detail. > > However, that kind of mapping doesn't apply to XMPP localparts > because we profile the PRECIS IdentifierClass, which prohibits > punctuation and space characters outside the ASCII7 range, control > characters, etc. So IMHO it's unnecessary for localparts. > Agreed. >> The similar language in 3.4. Resourcepart is not concerning to me >> at all; there are some cases where additional mappings are >> desirable (e.g., MUC nicknames), and I think the language makes >> it clear that anything beyond "it's opaque" is to be approached >> with care. > > Agreed, although I'd change the bullet to mostly or entirely match > what I added to draft-ietf-precis-saslprepbis. > That works for me. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTMeZKAAoJEDWi+S0W7cO1cdUIALStFgXG1uuizVckpgGMpalQ WKc9WU5OcIdvUBk9NuPjHP8J18wx9nvKCqpEp+yN4CznvurF/g8gJZxZsRdBD0mV HtO8OxhqqH3v0q+CQmWoGxx9VSmFzgR+4BKXbjsJrWec2BU8oSpouagk01moFJIe F46ZeVsU+TZYhxxGrnvnljsUEv7YFHevkeFO6cd22Jo35ikU/NjkBLMEEpR2+9mk Xw3N0eNmkucZ8xILVVtRbLIq3L6AcZNo0Gr3MeKI/SSxcJYm4bBYxnnQa3jOZJXA WkvnGnUEECIQ58hu60DHmH60HS2OHH7WwfPvutwvf8cBJmnVx4AWP69MtnRH+is= =3whQ -----END PGP SIGNATURE----- From nobody Tue Mar 25 18:27:58 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9EE1A0028 for ; Tue, 25 Mar 2014 18:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4qyklcMlX3Ps for ; Tue, 25 Mar 2014 18:27:54 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1001F1A0025 for ; Tue, 25 Mar 2014 18:27:53 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1130E4010C; Tue, 25 Mar 2014 19:27:51 -0600 (MDT) Message-ID: <53322D17.80707@stpeter.im> Date: Tue, 25 Mar 2014 19:27:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Matt Miller , XMPP Working Group References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> <5331DFEC.4030900@cisco.com> <5331E42D.6020501@stpeter.im> <5331E64A.5080909@cisco.com> In-Reply-To: <5331E64A.5080909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/02uHmqXn2jvJU77ujDi2otrh40E Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11 X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 01:27:56 -0000 On 3/25/14, 2:25 PM, Matt Miller wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 3/25/14, 2:16 PM, Peter Saint-Andre wrote: >> On 3/25/14, 1:58 PM, Matt Miller wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >>> >>> I've finished reviewing draft-ietf-xmpp-6122bis-11. I mostly >>> think this document is ready to be published. I think it deals >>> with the internationalization issues at hand as well as can be >>> expected. >>> >>> However, in 3.2. Domainpart, I wonder about the following: >>> >>> 4. So-called "additional mappings" MAY be applied to the >>> domainpart, such as those defined in [I-D.ietf-precis-mappings] >>> or [RFC5895]. >>> >>> As far as I can tell, just about all of the suggested mappings >>> from RFC5895 are already required here. But for any that are >>> not, I worry about the potential for interoperability problems if >>> say two servers communicating with each other apply different >>> mappings. It might be best to strike this bullet from the list. >> >> Yes, I think you are right that it would be best to remove this >> step. While updating draft-ietf-precis-saslprepbis last night, I >> removed any mention of additional mappings from the password >> algorithm, for similar reasons. >> >>> Less concerning to me is in 3.3. Localpart: >>> >>> 2. So-called "additional mappings" MAY be applied, such as >>> those defined in [I-D.ietf-precis-mappings]. >>> >>> I think there is less concern about interoperability problems >>> here, but I wonder if it is of any real utility. >> >> In saslprepbis, we've changed the username text to read: >> >> 3. So-called additional mappings MAY be applied, such as mapping >> of delimiters (e.g., characters such as '@', ':', '/', '+', and >> '-') and special handling of certain characters or classes of >> characters (e.g., mapping of non-ASCII spaces to ASCII space or >> mapping of control characters to nothing); the PRECIS mappings >> document [I-D.ietf-precis-mappings] describes such mappings in more >> detail. >> >> However, that kind of mapping doesn't apply to XMPP localparts >> because we profile the PRECIS IdentifierClass, which prohibits >> punctuation and space characters outside the ASCII7 range, control >> characters, etc. So IMHO it's unnecessary for localparts. >> > > Agreed. I looked at that text again and made a few changes (we're not mapping delimiters, we're mapping characters that are similar to delimiters): 3. So-called additional mappings MAY be applied, such as mapping of characters that are similar to common delimiters (such as '@', ':', '/', '+', '-', and '.', e.g., mapping of IDEOGRAPHIC FULL STOP (U+3002) to FULL STOP (U+002E)) and special handling of certain characters or classes of characters (e.g., mapping of non-ASCII spaces to ASCII space); the PRECIS mappings document [I-D.ietf-precis-mappings] describes such mappings in more detail. >>> The similar language in 3.4. Resourcepart is not concerning to me >>> at all; there are some cases where additional mappings are >>> desirable (e.g., MUC nicknames), and I think the language makes >>> it clear that anything beyond "it's opaque" is to be approached >>> with care. >> >> Agreed, although I'd change the bullet to mostly or entirely match >> what I added to draft-ietf-precis-saslprepbis. >> > > That works for me. Great. Thanks again for the review. Peter From nobody Wed Mar 26 21:29:57 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8F1A0447 for ; Wed, 26 Mar 2014 21:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 gOYlsCbD3619 for ; Wed, 26 Mar 2014 21:29:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A411A0446 for ; Wed, 26 Mar 2014 21:29:55 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2R4TlVS042308 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Mar 2014 23:29:48 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell Date: Wed, 26 Mar 2014 23:29:46 -0500 X-Mao-Original-Outgoing-Id: 417587386.097872-05341c230cf75e959f011c87d78c20b1 Content-Transfer-Encoding: quoted-printable Message-Id: <5D239412-9EE6-4CFA-8E76-21F2CA4EF002@nostrum.com> To: XMPP Working Group X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/3YHQOG7tFv0KzeBLQUzM3pxUGS0 Subject: [xmpp] Draft Minutes from London X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 04:29:56 -0000 Hi, The _draft_ minutes from the XMPP meeting in London are available at = http://www.ietf.org/proceedings/89/minutes/minutes-89-xmpp . Please send = any corrections to the chairs as soon as possible. Thanks! Ben.= From nobody Thu Mar 27 12:32:43 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC901A06F6 for ; Thu, 27 Mar 2014 12:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 C9cHh058cGHq for ; Thu, 27 Mar 2014 12:32:40 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 76FF01A0177 for ; Thu, 27 Mar 2014 12:32:40 -0700 (PDT) Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 369B54010C; Thu, 27 Mar 2014 13:32:37 -0600 (MDT) Message-ID: <53347CD1.5040109@stpeter.im> Date: Thu, 27 Mar 2014 13:32:33 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Ben Campbell , XMPP Working Group References: <5D239412-9EE6-4CFA-8E76-21F2CA4EF002@nostrum.com> In-Reply-To: <5D239412-9EE6-4CFA-8E76-21F2CA4EF002@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/KKaHQSHlNXflAMAChhS982c5Nh8 Subject: Re: [xmpp] Draft Minutes from London X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 19:32:42 -0000 On 3/26/14, 10:29 PM, Ben Campbell wrote: > Hi, > > The _draft_ minutes from the XMPP meeting in London are available at http://www.ietf.org/proceedings/89/minutes/minutes-89-xmpp . Please send any corrections to the chairs as soon as possible. Other than the stray typo or two, looks good. Peter From nobody Thu Mar 27 13:28:24 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FBE1A033A for ; Thu, 27 Mar 2014 13:28:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 xlaGeugaSvzZ for ; Thu, 27 Mar 2014 13:28:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 746301A01FD for ; Thu, 27 Mar 2014 13:28:20 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2RKSGK4095321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2014 15:28:18 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <53347CD1.5040109@stpeter.im> Date: Thu, 27 Mar 2014 15:28:16 -0500 X-Mao-Original-Outgoing-Id: 417644896.716095-9ff16f509ef6981e400464baba274bbe Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D239412-9EE6-4CFA-8E76-21F2CA4EF002@nostrum.com> <53347CD1.5040109@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/ZIXxn4vdnQaSX6Bb-sWDfpXUt_M Cc: XMPP Working Group Subject: Re: [xmpp] Draft Minutes from London X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 20:28:22 -0000 On Mar 27, 2014, at 2:32 PM, Peter Saint-Andre = wrote: > On 3/26/14, 10:29 PM, Ben Campbell wrote: >> Hi, >>=20 >> The _draft_ minutes from the XMPP meeting in London are available at = http://www.ietf.org/proceedings/89/minutes/minutes-89-xmpp . Please send = any corrections to the chairs as soon as possible. >=20 > Other than the stray typo or two, looks good. Thanks, Peter! If there are only a few stray typos, that's better than I expected. = These often have whole herds :-) From nobody Mon Mar 31 19:41:39 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99FC1A6F79; Mon, 31 Mar 2014 19:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WN3rpcEEn48; Mon, 31 Mar 2014 19:41:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 147941A0922; Mon, 31 Mar 2014 19:41:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140401024131.4027.6338.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 19:41:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/768rLBGrFwE2Z2DXm_i7hr7RFQo Cc: xmpp@ietf.org Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-12.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 02:41:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. Title : Extensible Messaging and Presence Protocol (XMPP): Address Format Author : Peter Saint-Andre Filename : draft-ietf-xmpp-6122bis-12.txt Pages : 25 Date : 2014-03-31 Abstract: This document defines the address format for the Extensible Messaging and Presence Protocol (XMPP), including support for code points outside the ASCII range. This document obsoletes RFC 6122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 31 19:43:44 2014 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 106421A6F79 for ; Mon, 31 Mar 2014 19:43:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UdKkqVgqqvHF for ; Mon, 31 Mar 2014 19:43:42 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCE21A0922 for ; Mon, 31 Mar 2014 19:43:42 -0700 (PDT) Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E58394010C; Mon, 31 Mar 2014 20:43:38 -0600 (MDT) Message-ID: <533A27D9.2020404@stpeter.im> Date: Mon, 31 Mar 2014 20:43:37 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: xmpp@ietf.org References: <20140401024131.4027.6338.idtracker@ietfa.amsl.com> In-Reply-To: <20140401024131.4027.6338.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/XxcOvC9Ph-wubmBc-n8qwatZvyg Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-12.txt X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 02:43:44 -0000 Small changes to address feedback from Matt Miller. On 3/31/14, 8:41 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF. > > Title : Extensible Messaging and Presence Protocol (XMPP): Address Format > Author : Peter Saint-Andre > Filename : draft-ietf-xmpp-6122bis-12.txt > Pages : 25 > Date : 2014-03-31 > > Abstract: > This document defines the address format for the Extensible Messaging > and Presence Protocol (XMPP), including support for code points > outside the ASCII range. This document obsoletes RFC 6122. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-12 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > xmpp mailing list > xmpp@ietf.org > https://www.ietf.org/mailman/listinfo/xmpp >