From nobody Fri Oct 23 14:18:13 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFF61AD0A7 for ; Fri, 23 Oct 2015 14:18:11 -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 BAbTnSa6Ex6n for ; Fri, 23 Oct 2015 14:18:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3731AD0A5 for ; Fri, 23 Oct 2015 14:18:10 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t9NLI6KW044642 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 23 Oct 2015 16:18:07 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: xmpp@ietf.org From: Adam Roach Message-ID: <562AA40E.40407@nostrum.com> Date: Fri, 23 Oct 2015 16:18:06 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Martin Thomson Subject: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2015 21:18:12 -0000 XMPP folks: Martin and I put together a proposal for an approach that allows for end-to-end encrypted XMPP conversations, including in the presence of MUC. Although not a completely implementable spec, this should give a good idea about the direction we have in mind: https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 Anyone interested in this work should give it a read and provide feedback. In particular, I'm curious if anyone interested in implementing this kind of thing has requirements can't be addressed with the high-level approach we're describing. Thanks! /a From nobody Sat Oct 24 01:55:32 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3D81B2F37 for ; Sat, 24 Oct 2015 01:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.083 X-Spam-Level: X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FsY-BQfE_EeV for ; Sat, 24 Oct 2015 01:55:29 -0700 (PDT) Received: from s.xnyhps.nl (s.xnyhps.nl [46.19.32.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C6A1B2F35 for ; Sat, 24 Oct 2015 01:55:28 -0700 (PDT) Authentication-Results: xnyhps.nl; dmarc=none header.from=xnyhps.nl DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=xnyhps.nl; s=mail; t=1445676921; bh=qVT7nrrQdcEGZlVYx4XccWSBC1+nlBNRlmY3zCMC9ws=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=afJpBn3YqWAD7uymWUfXes9SEqlKmhZAR7EC4u+U1RG4/mtlmdFevqsd/gob9cben W3HOi97MCnnwyPJitn4LmhMY2/5JQeeVwNiBI9z8kfrXvJLB5zAkbeGyM3HAizlmKi oV63GFNIyLcvnSxNcm2tMD2o+36JlzzY4x/xdmYM= Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5.2 From: Thijs Alkemade In-Reply-To: <562AA40E.40407@nostrum.com> Date: Sat, 24 Oct 2015 10:55:17 +0200 Message-Id: <6340BA7B-A6DD-4F9C-82C3-6B39E97D62D9@xnyhps.nl> References: <562AA40E.40407@nostrum.com> To: Adam Roach Archived-At: Cc: Martin Thomson , XMPP Group Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2015 08:55:31 -0000 --Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 okt. 2015, at 23:18, Adam Roach wrote: >=20 > XMPP folks: >=20 > Martin and I put together a proposal for an approach that allows for = end-to-end encrypted XMPP conversations, including in the presence of = MUC. Although not a completely implementable spec, this should give a = good idea about the direction we have in mind: >=20 > https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 >=20 > Anyone interested in this work should give it a read and provide = feedback. In particular, I'm curious if anyone interested in = implementing this kind of thing has requirements can't be addressed with = the high-level approach we're describing. >=20 > Thanks! >=20 > /a Hi Adam, I've read through the draft, and there are still some things unclear to = me. Forward secrecy is never mentioned. =46rom the design, I can't tell if = it was a requirement. The symmetric key that is generated in =C2=A76.2 can be = decrypted by anyone who has a log of all stanzas and the private Diffie-Hellman key = of either party. The symmetric key has a limited lifetime, but that is not enough = if the DH keys do not expire and I don't see the document mention that they do. The support for offline messaging is also a bit unclear to me. =C2=A76.4 = suggests that a client can send a Symmetric Key Advertisement to a client that is currently offline. But how would the sender obtain the DH public key for = the recipient if that key is advertised using presence (as stated in =C2=A76.1= )? The receiving client would also need to wait for the sender to be online to = obtain its DH public key before it can decrypt the key. (And the sender would = be unable to change their DH key until all advertisements have been acknowledged, destroying forward secrecy.) To be honest, I think the current OMEMO draft, while not perfect, = matches my requirements a lot better. Regards, Thijs --Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJWK0d3AAoJEDJpbwxQSdU3fR0P/RwEmq/hdyajKESMu2wqYnpw 7KwNxs3yyTd/Sgm17h3xDnKCgpBWW9p0fesKp+JNDC152UuMHuNfZixui/piHYDr geOsS9D9Mcw870M7pR+Loja79b0KugX9N+PZMrxeQZHR89SW/JVetTH3cStJvRE2 kFvUCIakgNQ6f1ueDQ3Wafx884l7hhYrk9rZVtjAcropXMppVwq8oyJ8dnH/gdeL wPUA7E9qSZkhn4GPZ+4PTaLKgNAju2sTPW3XHsa1RJjsgHINvoFeCDeyIacPGMTp WeFiNmsZG1KGCbVdisZVc1JC1v5xIZ3Wdbzd1VOkgumEWIf3sExulDydgiULb25U VE3lTvRfocStPi4pQPpYKSBALXAC5WJGttBDbPvH+ZDSN3HAoLFX2r1sWrjc/L8k 1LbdFnh7IRy6UQyEA57rtk91MvD7wkFyf7gg4oxh4qWEUfGivunowoyOZShfNOTU eawGfOnVsq/wGRnvEmcpwMA2kfpz9+qa58bRONkorgmeEfFNG7c88Bg5zxXsKbKd ngmC2q4WNGAckv3fJBVIm1+IHW32kJbxnPuehSMZkH/SgbbTaThxVZP4w8ZcJU3/ w7cbIn0/vsOIGtRnRZxzfXk/SD5J/Wmaq3oHCBX/UChdrM5loRKHChHD1sd7P4J0 2y9KSxRvG7VL0XT6i8X/ =rMNi -----END PGP SIGNATURE----- --Apple-Mail=_1BD9529D-6C3B-473B-91D0-1D2A81EE5906-- From nobody Sun Oct 25 20:57:35 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7781E1B3625 for ; Sun, 25 Oct 2015 20:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, J_CHICKENPOX_34=0.6, 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 y3OWZ_Ee2gXa for ; Sun, 25 Oct 2015 20:57:31 -0700 (PDT) Received: from lo.psyced.org (lost.in.psyced.org [188.40.42.221]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EC21B3624 for ; Sun, 25 Oct 2015 20:57:31 -0700 (PDT) Received: from [192.168.20.105] (97-90-49-254.static.yakm.wa.charter.com [97.90.49.254]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id t9Q3xItJ025678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 26 Oct 2015 04:59:22 +0100 To: xmpp@ietf.org References: <562AA40E.40407@nostrum.com> From: Philipp Hancke Message-ID: <562DA49E.8020108@goodadvice.pages.de> Date: Sun, 25 Oct 2015 20:57:18 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562AA40E.40407@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 03:57:34 -0000 Am 23.10.2015 um 14:18 schrieb Adam Roach: > XMPP folks: > > Martin and I put together a proposal for an approach that allows for > end-to-end encrypted XMPP conversations, including in the presence of > MUC. Although not a completely implementable spec, this should give a > good idea about the direction we have in mind: > > https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 > > Anyone interested in this work should give it a read and provide > feedback. quite a number of comments and questions... https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.2.1 Clients that wish to participate in encrypted messaging publish keying material to their presence we've stopped putting stuff into presence quite a while ago... See PEP question below. (I assume you don't require compat with ancient services like google talk that could never be bothered to implement post-2004 features like PEP) Each client generates new keying material that is bound to the full JID that they use (that is, each client has its own keying material; there is no key associated with a user's bare JID). This is problematic with server-chosen resource parts which change with each login. 'static' resources like 'desktop', 'work' or 'iphone' are a thing of the past. PEP is likely the answer here. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.2.2 Prior to sending a message, a client first retrieves and validates the presence of the intended recipient. Can you explain what you mean with 'first retrieves and validates the presence of the intended recipient'? I suspect the presence model you have in mind is not what XMPP commonly does... which is 'broadcast' so no retrieval. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.3 A user founds a MUC in the usual fashion (see [XEP-0045], section 10.1). Two changes are made: broken link. I would also suggest replacing 'founds' with 'creates' for consistency of terminology. But that's just me. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-3.3.1 The inviting client generates a signed invitation and sends this to the bare JID of the offline user using what key? The bare JID has no key. If not using MAM this message might be delivered to the next client that signs on which might not be a client that can decrypt the message. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4 Can you please use other element names? is very non-descriptive which is the reason that new xmpp extensions don't use this style anymore. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4.1 The server uses the client's authentication credentials, which are usually bound to a connection, to determine if the client owns the identifier. the identifier being user@example.com/resource? https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-4.2 generates an error, or a message containing the identity. s/message/result (this refers to an iq-result) https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5 The routing and message handling information from the cleartext (element basename plus to, from, and type attributes) For this should include the id attribute? That is, stanzas produce encrypted stanzas; we usually write this as and (also elsewhere) https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.1 This removes the language indicator from the unencrypted stanza. Note that the server might re-add the stream's xml:lang when forwarding. Not a problem I think, I would just omit the xml:lang in the example. It's rarely used anyway. To do: check with someone who might know. should be ignored. Note that the lack of might affect storage, see http://xmpp.org/extensions/xep-0313.html section 5. Also resource locking, carbons etc. Multi-client is a hard problem. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.2.3 Since there is an expectation of reliability and in-order message delivery, clients should highlight where message are missing. This reliability is only partially achieved when crossing s2s. I need to ponder more on this. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.3 A signature on messages is necessary to prevent impersonation of other MUC participants. wait, why is this now talking about MUC again? https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.5 Encrypting status is highly desirable. You'll end up encrypting 'user has been unavailable for 15 minutes' -- in languages some of the users friends don't even understand. In practice few people use the status. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-5.6 Thus, clients are required to suppress chat state notifications when a peer is offline. I think that's already in XEP-0085. Since you don't have presence for the peer you don't know their chat state support and should not send chat states. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-6.1 Please, don't put stuff into . Use PEP. You also want to use XEP-0335. https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-7 I think using 'roster' here is confusing since that is used in 6121 and XEP-0045 for slightly different purposes (neither of which makes any assertions about validity). https://tools.ietf.org/html/draft-thomson-xmpp-secure-00#section-8 I like the idea. It is better than 'just use sasl anonymous' since the server can provide this service only to authenticated clients. In terms of implementation, I think this better described as an xmpp-to-xmpp transport. There is something here which puzzles me: Clients are able to include the new pseudonym in any interaction that they initiate Are you assuming that client that requested this would send stanzas with from='7ee6df7a831198624131@example.com/someresource'? Servers will typically override any client-set 'from' which seems to have impact on the crypto scheme you're proposing. From nobody Mon Oct 26 10:14:16 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78781B4FD9 for ; Mon, 26 Oct 2015 10:14:15 -0700 (PDT) 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, FREEMAIL_FROM=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 ZLHn_sHVcVAt for ; Mon, 26 Oct 2015 10:14:14 -0700 (PDT) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8275E1B4FD7 for ; Mon, 26 Oct 2015 10:14:13 -0700 (PDT) Received: by wicll6 with SMTP id ll6so124226055wic.0 for ; Mon, 26 Oct 2015 10:14:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=FP5mzWQ7oB9dl0kSnd3Q5muDhhYcNde/BIofUJo7u08=; b=ieOSwJP/hLSqfc91yygKVdAQ8HPDMmNoYvcqeAd2TZPEEJwJxiu2nVHby21QtInOKS P/ZpCsC0Cy6J+aao5tBlKs6wUPuZtEN9VlUomkCF06ORt6J6xeSX/yGeXaO28zuuSDJJ mmIpiI+Ni60id1ua0zoiBRCS0QJ1FoEItC9azxeReBzmkUW9xQ4jBvFX3JZXnyiM//LK 4dOPus/Wk++BZo5YCKSKK6lxm/MUR+7rlPVkvp10FvkhOgpHtBJVgfoavtyoSsQsmcIu VSZOIv2521azy/biR/6ITfrFv7bOk7TKHHbwv/tnRjzfd5YCa0XEgnnsItbBqZvEi+sF lYZg== X-Received: by 10.195.11.33 with SMTP id ef1mr14503129wjd.34.1445879651974; Mon, 26 Oct 2015 10:14:11 -0700 (PDT) Received: from [131.188.34.87] (flowbook.informatik.uni-erlangen.de. [131.188.34.87]) by smtp.googlemail.com with ESMTPSA id fx19sm14616916wic.2.2015.10.26.10.14.11 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Oct 2015 10:14:11 -0700 (PDT) To: Adam Roach , xmpp@ietf.org References: <562AA40E.40407@nostrum.com> From: Florian Schmaus X-Enigmail-Draft-Status: N1110 Message-ID: <562E5F53.9060104@geekplace.eu> Date: Mon, 26 Oct 2015 18:13:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <562AA40E.40407@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KXm9qiKvloHqjMU4L0LS8SOOaxepD7Rag" Archived-At: Cc: Martin Thomson Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 17:14:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KXm9qiKvloHqjMU4L0LS8SOOaxepD7Rag Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23.10.2015 23:18, Adam Roach wrote: > XMPP folks: >=20 > Martin and I put together a proposal for an approach that allows for > end-to-end encrypted XMPP conversations, including in the presence of > MUC. Although not a completely implementable spec, this should give a > good idea about the direction we have in mind: >=20 > https://tools.ietf.org/html/draft-thomson-xmpp-secure-00 >=20 > Anyone interested in this work should give it a read and provide > feedback. What Thijs and Philipp said so far. What's the motivation behind using Presence to announce the Keys? PEP appears to be a much better choice. I also think that it should be possible, although very inefficiently in terms of bandwidth, to design an XEP which uses OMEMO for MUC encryption. Which makes me wonder what your selling points compared to OMEMO are? - Florian --KXm9qiKvloHqjMU4L0LS8SOOaxepD7Rag Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWLl9TXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMzU3QjAxODY1QjI1MDNDMTg0NTNEMjA4 Q0FDMkE5Njc4NTQ4RTM1AAoJEIysKpZ4VI41cj8IAKn2k8tdB+Mm4g0Rf3ZRjEDu ZpJt9fJ9JlqLyXwrpGGn6/NRpWIYi5U8bgVsqSayeLcuLsEVte40u4CPHV7ohY9y eAjzBU7q7jvuHjpjvK1HVeo/DrWa7ucO8MAKBlgoAPxft0FsqyTyTPzfDynmLooz SIpGlIbft3LvwWkD5ZT3aRKZASr//HB29zxL452HuSa1GGuznbBY5y6SjfOT8I4l VYEY+P1P5b7fHPSPV/2ATVOOZc1mQw349h+BmZh5CsHkXML+R/Cp+6KnbAMz0X2p s5k3AUJKqB25gXCLDUr8h9ngX5O7yuqcPNEtM5a54k0D16Yf/mmf7HN4rLAbHRI= =SamI -----END PGP SIGNATURE----- --KXm9qiKvloHqjMU4L0LS8SOOaxepD7Rag-- From nobody Wed Oct 28 05:43:11 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64E61A87A8 for ; Wed, 28 Oct 2015 05:43:09 -0700 (PDT) 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, FREEMAIL_FROM=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 Nzl5fJya0agF for ; Wed, 28 Oct 2015 05:43:08 -0700 (PDT) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7A251A8788 for ; Wed, 28 Oct 2015 05:43:07 -0700 (PDT) Received: by wicfv8 with SMTP id fv8so11155585wic.0 for ; Wed, 28 Oct 2015 05:43:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type; bh=Av9/Il0lEKCVB+hrc1l37q0kNrTnVsDwbdoESJu64Yg=; b=VYmXTqq6lf5uDkMZ4THzQZcheJ9mGZKadyKjolNtBJMqoc3Q90Y28pQ6NCxbvSkpxM 6j3l5vVTyp4tCK097I3ZDl3qoPDiHYnHpja5ZJ43sT4t3Fi0D4jHuacKaVXw5E/3h/ic 5X7FN6uPzcQLgaL0DYJNn6YjGZQYAckyNhI14nyE4AlAz3OmFFA+4PT7FfO7BnUz7iA+ vBlq6W7CVCy2Gm3Tg736NEg+fqJkH9kFQInVcYBgmm0/G7J+9p4RdFuKEck91TtSAhig EQHIq6pwjAB2T5o3d+Bg87TgeFg/EU5DUDO7oUsD2z8TrKP4B0AmQilEeSYYVDsr5c0j AtRw== X-Received: by 10.194.190.47 with SMTP id gn15mr37203456wjc.119.1446036186392; Wed, 28 Oct 2015 05:43:06 -0700 (PDT) Received: from [131.188.34.87] (flowbook.informatik.uni-erlangen.de. [131.188.34.87]) by smtp.googlemail.com with ESMTPSA id ka10sm49884123wjc.30.2015.10.28.05.43.04 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Oct 2015 05:43:04 -0700 (PDT) To: Martin Thomson References: <562AA40E.40407@nostrum.com> <562E5F53.9060104@geekplace.eu> From: Florian Schmaus X-Enigmail-Draft-Status: N1110 Message-ID: <5630C2C7.6030907@geekplace.eu> Date: Wed, 28 Oct 2015 13:42:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cFU26Abt76N7jio4Hit0MEAPpIbOjOG4C" Archived-At: Cc: xmpp@ietf.org Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 12:43:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cFU26Abt76N7jio4Hit0MEAPpIbOjOG4C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28.10.2015 01:41, Martin Thomson wrote: > On 27 October 2015 at 02:13, Florian Schmaus wrote: >> Which makes me wonder what your selling points compared to >> OMEMO are? >=20 > It would help to know what OMEMO is. http://conversations.im/xeps/multi-end.html The XSF participated this year in Google's Summer of Code. One project was called "Axolotl support for Conversations". Axolotl is the OTR competitor designed by the WhisperSystem's people and is used in TextSecure. Conversations is an open source XMPP client for Android. One outcome of this GSOC project was the aforementioned OMEMO XEP. - Florian --cFU26Abt76N7jio4Hit0MEAPpIbOjOG4C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJWMMLIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMzU3QjAxODY1QjI1MDNDMTg0NTNEMjA4 Q0FDMkE5Njc4NTQ4RTM1AAoJEIysKpZ4VI416f8IALBTs/HBFeAvjq0NYHKT6HLf wAYGmZJtSQIqBbIk1vn1D6+u5l9KEz8AZtb41QEF9OkW2rm9uqYYucbkwIriKStE 9otgLTDnxPTCOnwPKJ3TWd8276EVi5d1vqfzEs1hlCu2UA/nAylYO3O28GBIBRnJ TqlXnX4K4DcWhlWNhj4VtxV9HteIVgoa2Cw7YD1DZlptBR5hd9QOBxuZG9r2yW78 XZVtcqyXefiq/tlZI+Dv62/Ishlw6doVPQlNXgh28CleB6LOOCCFCtfEUmV7jSlE yQ7f6zgknqE1c+p1ipric+lf48g5QXTxKANRFzHvUjoBwAn9Y02r5HRkTFDUKUg= =TeDl -----END PGP SIGNATURE----- --cFU26Abt76N7jio4Hit0MEAPpIbOjOG4C-- From nobody Thu Oct 29 00:08:34 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D06E1A8AC5 for ; Thu, 29 Oct 2015 00:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 HNe-r6gaxFhd for ; Thu, 29 Oct 2015 00:08:31 -0700 (PDT) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94E21A8AEB for ; Thu, 29 Oct 2015 00:08:31 -0700 (PDT) Received: by ykba4 with SMTP id a4so33283864ykb.3 for ; Thu, 29 Oct 2015 00:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yu60RDZ7VBFhYD0Yo++MkOC3f79b01ajWFcqfKuCesU=; b=ZtL2ZujK05ldyWxuRqQz2IK8EDv6uz1p0xSvqQTHm8s/UgreekLiU1qYJIBBDxospX RY+a2p7vaY5apyQelGkV4dgJQyUHzyhiiUpO8RKHuGNMrlmS/ytxkn7NLMZxODAGvbhz OfQ9v8lF4Bzs/nefg8XsasHUMll4zK936XIO6hczwXbqRNv+gwDOnbGu46TyPvsBK8al Tw54d8B67xrc+7iQPTXxbT6nafVmWm4QXSmqc1SwjQd3/pcwix4SMUJymMtu/mCNL+OV G189CXwXg/otmQbbR2y9BUzHqIpLF+Ff9OC99i4a+9dtBv9IrYu3VrrvKfUlFi+cWaob 1wFg== MIME-Version: 1.0 X-Received: by 10.13.204.207 with SMTP id o198mr124569ywd.183.1446102510982; Thu, 29 Oct 2015 00:08:30 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Thu, 29 Oct 2015 00:08:30 -0700 (PDT) In-Reply-To: References: <562AA40E.40407@nostrum.com> <562E5F53.9060104@geekplace.eu> <5630C2C7.6030907@geekplace.eu> Date: Thu, 29 Oct 2015 16:08:30 +0900 Message-ID: From: Martin Thomson To: Florian Schmaus , XMPP Group Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 07:08:33 -0000 On 29 October 2015 at 09:02, Martin Thomson wrote: > I don't think that Axolotl is a good model > for the general use case. Since Florian asked nicely, here's the text I wrote about a year ago regarding PFS: >>> For a system where the messages are stored, this is largely a pointless exercise. Destroying the messages is also necessary to ensure that they cannot be recovered. We value function over perfect security and consider logging to be a critical part of a functional chat system. Furthermore, forward secrecy requires that a round trip between two parties occurs to establish a properly ephemeral key. This means that any initial message to any other device either cannot have forward secrecy, or it cannot include any content. In the latter case, content could only be carried once the receiving device has replied with their ephemeral share. (Other systems address this in part by provisioning a public store with shares ahead of any need for others to use them, but these systems work poorly in multi-party scenarios.) In the case where there are multiple agents in a chat - a scenario we consider to be critical for usability reasons - if any one user agent is offline, any message encrypted for that agent has to use a key that can only be unilaterally updated. Messages destined for the offline agent will necessarily depend on the private keying material on that agent, which cannot be updated. <<< I think that there was a separate note about the value of PFS for some exchanges. From andy@strb.org Thu Oct 29 11:05:58 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A881B30E1 for ; Thu, 29 Oct 2015 11:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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] 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 If6vMIA3epaG for ; Thu, 29 Oct 2015 11:05:56 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45651B30E0 for ; Thu, 29 Oct 2015 11:05:55 -0700 (PDT) Received: by wicll6 with SMTP id ll6so50064663wic.1 for ; Thu, 29 Oct 2015 11:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=strb.org; s=google; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=S8eWLMUyaDgoz2SsYvbUFlz4QtLx9MDregCqSHZTGOo=; b=iv0JJ5FNpdYQzeeUPNCZUeO4Apa8f+Utfi3Ec2wwCRN59Lyd7gHRL3cafgpD6BXqGM McYFCm+VfGN1BR3xguI5BDF7TB4bhAop86nx0EgQ2SJCOQZWlYhnQnSJP0QXQ4/iGE5k WGgmxf7XAXgGYLG7G0okg9q9e5Oj2tpK8+WA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=S8eWLMUyaDgoz2SsYvbUFlz4QtLx9MDregCqSHZTGOo=; b=Ofju54HrxGe8lG0RoFhpTBh9KZrrQOOrJCRmhGy4OkPZ+yvZwSKykfwioTMWjxlgP9 rZe9Ic1qBLEMtgnO2uh6lOiRWxm/d0vhiV0QWhALugrpVdN/Y67+2WiVKZQjbYVOvO88 m/nRLh71jUCjHmgiKw8KcUIqgiPz+SVM3Om2ISTVMk35hRUrPAzQs0Dmgc/oe68GS/mh OHScRYterVbKuJcV+ISeY92+jh1dfL5guXoFinjVPN/R2MwqfvDV7/GEFfepVrJtlZSB gORDLwLa256GtYK4sjzIA0z3tOHZgYqZGcbHdfDJKPPaf9+InJ0nQj7jgvZfxgstigh1 JcXg== X-Gm-Message-State: ALoCoQn+ksvwJRb+ZAMEn8bu9ZseeB/exu0AUPUyGmT6aqIolRe9F36EL4JkdTIak7TsCnCDecmU X-Received: by 10.28.92.16 with SMTP id q16mr9242775wmb.94.1446141954334; Thu, 29 Oct 2015 11:05:54 -0700 (PDT) Received: from [137.226.109.174] (ip2-174.halifax.rwth-aachen.de. [137.226.109.174]) by smtp.googlemail.com with ESMTPSA id 20sm10343176wmh.8.2015.10.29.11.05.53 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Oct 2015 11:05:53 -0700 (PDT) Message-ID: <56326001.1010300@strb.org> Date: Thu, 29 Oct 2015 19:05:53 +0100 From: Andreas Straub User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Martin Thomson , XMPP Group References: <562AA40E.40407@nostrum.com> <562E5F53.9060104@geekplace.eu> <5630C2C7.6030907@geekplace.eu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 18:06:56 -0000 Hi, I'm the person behind the OMEMO spec, so I'm obviously a bit biased, but I thought I would weigh in on this specific point. > For a system where the messages are stored, this is largely a > pointless exercise. Destroying the messages is also necessary to > ensure that they cannot be recovered. I feel strongly that there's nevertheless a significant benefit to be gained from some form of forward secrecy. It's still the difference between an attacker having to break one secret and being able to decrypt the entire history, versus having to break one secret per message (or sub-chain in the axolotl world). I would actually argue that in a stored-messages scenario, frequent key update is *even more important*, because the impact of a broken secret can be so much higher. > (Other systems address this in part by provisioning a > public store with shares ahead of any need for others to use them, but > these systems work poorly in multi-party scenarios.) Are there any specific problems with multi-party scenarios you could elaborate on? We've been using just this approach with OMEMO (and I'd argue it's been pretty successful so far), so I'd be very interested if there is something that we've neglected to consider here. > In the case where there are multiple agents in a chat - a scenario we > consider to be critical for usability reasons - if any one user agent > is offline, any message encrypted for that agent has to use a key that > can only be unilaterally updated. Messages destined for the offline > agent will necessarily depend on the private keying material on that > agent, which cannot be updated. You make a good point here, in that conversations that involve a device that is offline for long periods of time must necessarily degrade their forward secrecy accordingly. However, this is not necessarily the average use-case. In fact, its a rare edge case. I would argue that a protocol which always provides the highest level of forward secrecy that is possible in any situation is preferable, even if in certain pathological cases, the security will degrade to a fixed-secret equivalent level. > We value function over perfect security and consider logging to be a > critical part of a functional chat system. I agree wholeheartedly. People have come to expect such features from a modern instant messaging service, and rightfully so. But OMEMO actually achieves these while also providing forward secrecy. I don't think that we should give up on forward secrecy altogether just because we can't achieve *perfect* forward secrecy in every situation. Cheers, Andy From adityadivekar03@gmail.com Thu Oct 29 12:07:14 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009F61A8A62 for ; Thu, 29 Oct 2015 12:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.349 X-Spam-Level: X-Spam-Status: No, score=-0.349 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4UGQp9kw4GD for ; Thu, 29 Oct 2015 12:07:13 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C80D1A8A60 for ; Thu, 29 Oct 2015 12:07:12 -0700 (PDT) Received: by lfbn126 with SMTP id n126so23236129lfb.2 for ; Thu, 29 Oct 2015 12:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=OCJuBgf8XAcct3rZi/DQ9zNe6Mn8Rekd+u5hKmWc6Qw=; b=qOnherqCl2ajOKDQQUFDGP5bKdk7yRFayNgSTfXNqVAoXyFiUGob3QX0dL2SafTX0n gxfHpcf2j2FiWicR8AwyZO0UBpgHzdQH8CjTl8sub+f9ZOFJ+trCbzn1Ysf53G7QAMOX yutEC1VeLZP1QeVWSKqMuFxHsvHSFrKBiAZjOuTnmMkyampFLp6MR0osbMpSfjCyw5fM 72rLNx51c6TuKhbnDkK/2tcqGyPi/3CJDy7E8P+F+FCP9twzOjfSmyPX5VQBTFWrh2bH eD9hcACGF3S/nh8+Vm8EtsJbmjdwD+ya1rQewgpI1d8TQsFiAYnnRKD5+ZrKejzsRC3T eqeg== MIME-Version: 1.0 X-Received: by 10.25.212.8 with SMTP id l8mr1198864lfg.118.1446145630452; Thu, 29 Oct 2015 12:07:10 -0700 (PDT) Received: by 10.114.109.5 with HTTP; Thu, 29 Oct 2015 12:07:10 -0700 (PDT) Date: Fri, 30 Oct 2015 00:37:10 +0530 Message-ID: From: Aditya Divekar To: xmpp@ietf.org Content-Type: multipart/alternative; boundary=001a1141ffca98c510052343041c Archived-At: Subject: [xmpp] Getting Started 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, 29 Oct 2015 19:08:22 -0000 --001a1141ffca98c510052343041c Content-Type: text/plain; charset=UTF-8 Hi, I would like to start contributing to swift by taking on some beginner level bugs. Could you please point me in the right direction. --001a1141ffca98c510052343041c Content-Type: text/html; charset=UTF-8
Hi,
I would like to start contributing to swift by taking on some beginner level bugs. Could you please point me in the right direction.
--001a1141ffca98c510052343041c-- From nobody Thu Oct 29 14:10:58 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6747F1ACDE3 for ; Thu, 29 Oct 2015 14:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 m8ZIayE9vOhh for ; Thu, 29 Oct 2015 14:10:56 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAED81ACDBE for ; Thu, 29 Oct 2015 14:10:55 -0700 (PDT) Received: by ykdr3 with SMTP id r3so56459799ykd.1 for ; Thu, 29 Oct 2015 14:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6h1nXzCAumT/b5b9uvkI9j6uRPDur/UkqX248FWnrl8=; b=ROeNVLwJ9uaQxY37+/CqHnbEXSAwwtnNZjv3zTUTF9dC+eoIcyyXqqg8OxctewbJtr OHlLajyxoK2wSWmP60HVOzo2r66WTtpvBTMAoOq2749vTpxhwLE2KISi1J0qnOZVvqUm INTKimsq0Z3JZAqxwtcDsRyhCZ2JhYZtUz9YUZnHtQxCQeCNgAHPLqQQ9MgclGoAQoj+ TDdnlWX3Wk/I6n/+NepJCHI+bBmFOGuTLC0YjsTkMiTbwV2M7T+i9ASlyy2QKkAV0avY Mwfy78wwvGn02pXPjHTesGWT5M766wIMXhzf5f0qt75T2EdEsf2LM5IrtGE5tmXRTITE BVvQ== MIME-Version: 1.0 X-Received: by 10.13.196.196 with SMTP id g187mr3628994ywd.98.1446153055231; Thu, 29 Oct 2015 14:10:55 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Thu, 29 Oct 2015 14:10:55 -0700 (PDT) In-Reply-To: <56326001.1010300@strb.org> References: <562AA40E.40407@nostrum.com> <562E5F53.9060104@geekplace.eu> <5630C2C7.6030907@geekplace.eu> <56326001.1010300@strb.org> Date: Fri, 30 Oct 2015 06:10:55 +0900 Message-ID: From: Martin Thomson To: Andreas Straub Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: XMPP Group Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 21:10:57 -0000 On 30 October 2015 at 03:05, Andreas Straub wrote: > Hi, > > I'm the person behind the OMEMO spec, so I'm obviously a bit biased, but > I thought I would weigh in on this specific point. > >> For a system where the messages are stored, this is largely a >> pointless exercise. Destroying the messages is also necessary to >> ensure that they cannot be recovered. > > I feel strongly that there's nevertheless a significant benefit to be > gained from some form of forward secrecy. It's still the difference > between an attacker having to break one secret and being able to decrypt > the entire history, versus having to break one secret per message (or > sub-chain in the axolotl world). I would actually argue that in a > stored-messages scenario, frequent key update is *even more important*, > because the impact of a broken secret can be so much higher. I think that you will find that the proposed design does have the ability to perform frequent key updates for both symmetric and asymmetric keys. It's just that we don't have anything that would allow something like the Axolotl per-message switch. >> (Other systems address this in part by provisioning a >> public store with shares ahead of any need for others to use them, but >> these systems work poorly in multi-party scenarios.) > > Are there any specific problems with multi-party scenarios you could > elaborate on? Elaboration was in the next paragraph :) I don't think that there is much more to it. >> In the case where there are multiple agents in a chat - a scenario we >> consider to be critical for usability reasons - if any one user agent >> is offline, any message encrypted for that agent has to use a key that >> can only be unilaterally updated. Messages destined for the offline >> agent will necessarily depend on the private keying material on that >> agent, which cannot be updated. > > You make a good point here, in that conversations that involve a device > that is offline for long periods of time must necessarily degrade their > forward secrecy accordingly. However, this is not necessarily the > average use-case. In fact, its a rare edge case. I would argue that a > protocol which always provides the highest level of forward secrecy that > is possible in any situation is preferable, even if in certain > pathological cases, the security will degrade to a fixed-secret > equivalent level. My experience with this is that this is far from unusual, rather that it is the norm that one or several participants in a discussion are offline, potentially for extended periods. The real challenge is in deciding if you are willing to cut them out of the conversation entirely at some point. >> We value function over perfect security and consider logging to be a >> critical part of a functional chat system. > > I agree wholeheartedly. People have come to expect such features from a > modern instant messaging service, and rightfully so. But OMEMO actually > achieves these while also providing forward secrecy. I don't think that > we should give up on forward secrecy altogether just because we can't > achieve *perfect* forward secrecy in every situation. Ultimately I agree. I think that the only place we might disagree is how far toward the ideal we intend to aim. From nobody Sat Oct 31 16:20:16 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13DFC1B39EB for ; Tue, 27 Oct 2015 17:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 3cFjPZPqUEL9 for ; Tue, 27 Oct 2015 17:41:56 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1364E1B39E8 for ; Tue, 27 Oct 2015 17:41:55 -0700 (PDT) Received: by ykba4 with SMTP id a4so231258945ykb.3 for ; Tue, 27 Oct 2015 17:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PkyfdEPfwF910xBNGBV3Bxq6b41U6xWhiH6o8AS2uiw=; b=JFKa72nzlToEz5fBZF7tb8lnfUlvkkcfmZ5oVll+wgEx6HwrW18FSIBiFWOIlwanAi uh1Xco04gV9EubibqpIup3cDFCEMfxH3cP//iW1I/pFKyRdMYRTFxM7+YDhp8RnxOCpH uMDc80CVMckihfbWgvYNLYldEr/nyRl+VaFbJi4mwWQUKxXqRBLdcwXkIt5kcv9N8Va9 glt0tsFpPlSgz1knl09+bxqFaPUBO88pE5OT8kZV3VirEwYViHlhaOjIn8C5D7yh2uhm Z0Q+a42AcXfETEJ9FehB2EbBcF2h7sdUCL2w/xmCImuPGddOxf9kpZxgqFqUXvziDpG+ Prdw== MIME-Version: 1.0 X-Received: by 10.129.79.132 with SMTP id d126mr16234308ywb.159.1445992915232; Tue, 27 Oct 2015 17:41:55 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Tue, 27 Oct 2015 17:41:55 -0700 (PDT) In-Reply-To: <562E5F53.9060104@geekplace.eu> References: <562AA40E.40407@nostrum.com> <562E5F53.9060104@geekplace.eu> Date: Wed, 28 Oct 2015 09:41:55 +0900 Message-ID: From: Martin Thomson To: Florian Schmaus Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 16:20:15 -0700 Cc: xmpp@ietf.org Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 00:41:58 -0000 On 27 October 2015 at 02:13, Florian Schmaus wrote: > Which makes me wonder what your selling points compared to > OMEMO are? It would help to know what OMEMO is. From nobody Sat Oct 31 16:20:17 2015 Return-Path: X-Original-To: xmpp@ietfa.amsl.com Delivered-To: xmpp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD8B1B39F6 for ; Tue, 27 Oct 2015 17:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, IXHASH_X1=1.5, 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 VOQWJ7-U58JU for ; Tue, 27 Oct 2015 17:42:34 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314231B39F4 for ; Tue, 27 Oct 2015 17:42:34 -0700 (PDT) Received: by ykek133 with SMTP id k133so55355188yke.2 for ; Tue, 27 Oct 2015 17:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x3sJqmx496zxbutAT+HtkJddAw8WfpQEEfWwLCCmAzM=; b=voANGzXJ7eWwvlW3WwcOVVsOB/99Gn1Bimp3xZYGtYF9/0PaX9d12WjlUMGGv/HsL8 Mqy2kWBoOxbxM1t/rFB+Fqxr1exBro4f5arCFZB7zzFgpmU6NXYDYQQpszcHVD8LolxP y21GVXIBz/eWgggrxOTaXMcaE767qOwUyCGCB6vjPWc1lHbdXF0YCE2vidmu6QT9sxfv 2ZzIop9m11dieDRlXDgxLV6J1Eu+O2Y2finMLyGUjg73yHvc1GiXVCf4A0GwyKqK9Ek7 M4ZXN8wvBiulDErclHbU0bi6P0pLEk8Ol797po+ulHU/RMnnxnON5QG5s2X0byfmJpig J+bg== MIME-Version: 1.0 X-Received: by 10.129.132.83 with SMTP id u80mr32549800ywf.187.1445992953569; Tue, 27 Oct 2015 17:42:33 -0700 (PDT) Received: by 10.129.132.145 with HTTP; Tue, 27 Oct 2015 17:42:33 -0700 (PDT) In-Reply-To: <6340BA7B-A6DD-4F9C-82C3-6B39E97D62D9@xnyhps.nl> References: <562AA40E.40407@nostrum.com> <6340BA7B-A6DD-4F9C-82C3-6B39E97D62D9@xnyhps.nl> Date: Wed, 28 Oct 2015 09:42:33 +0900 Message-ID: From: Martin Thomson To: Thijs Alkemade Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Sat, 31 Oct 2015 16:20:15 -0700 Cc: XMPP Group Subject: Re: [xmpp] New(ish) draft: Secure Messaging in XMPP X-BeenThere: xmpp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: XMPP Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 00:42:36 -0000 On 24 October 2015 at 17:55, Thijs Alkemade wrote: > Forward secrecy is never mentioned. I guess the section I wrote up on it was lost.