[xmpp] Problems with draft-miller-xmpp-e2e [WAS: [Standards] Updated Yabasta Protocol (E2E-related)]

"Matt Miller (mamille2)" <mamille2@cisco.com> Thu, 11 July 2013 13:09 UTC

Return-Path: <mamille2@cisco.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC0211E812E for <xmpp@ietfa.amsl.com>; Thu, 11 Jul 2013 06:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6znODCl8BBN for <xmpp@ietfa.amsl.com>; Thu, 11 Jul 2013 06:09:49 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B586321F9F20 for <xmpp@ietf.org>; Thu, 11 Jul 2013 06:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9900; q=dns/txt; s=iport; t=1373548188; x=1374757788; h=from:to:cc:subject:date:message-id:references: mime-version; bh=uvOLkU6cEvuNoqSvhLeYTVxM8jzFcvHsVkU2cO7hBQw=; b=HvIVd6R1wXI6AV5QON32IOhS6v0qMUC9+R+MW2BuVBbGVDDTu76jjvQI CatwsmEPoVR1rLAISvzX9vpC4xri7ZgZNbBrqUqlMrpRPD0hz5vn9tJ7r Lemk0GLyJdZaJX1OKxbrdBr55dYZIx/xb6MSdbaSeBcUJR4MuaLnX9VCA Y=;
X-Files: smime.p7s : 4136
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAJid3lGtJV2d/2dsb2JhbABRCYMJMk3BUIEGFnSCIwEBAQMBSSoGBQcEAgEZAwEBAQEKHQcCMBQJCAIECgQFCAaHewYMtzSOJoEKBhAKEQsCA4MAbAOQDoEth0iQIYFYgTmCKA
X-IronPort-AV: E=Sophos; i="4.87,1043,1363132800"; d="p7s'?scan'208"; a="233573517"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 11 Jul 2013 13:09:47 +0000
Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6BD9lAF016141 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Jul 2013 13:09:47 GMT
Received: from xmb-aln-x11.cisco.com ([169.254.6.51]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 08:09:47 -0500
From: "Matt Miller (mamille2)" <mamille2@cisco.com>
To: "<xmpp@ietf.org> Group" <xmpp@ietf.org>
Thread-Topic: Problems with draft-miller-xmpp-e2e [WAS: [Standards] Updated Yabasta Protocol (E2E-related)]
Thread-Index: AQHOfjfqBUeXs7ErtE2yPaxw8EVu4g==
Date: Thu, 11 Jul 2013 13:09:46 +0000
Message-ID: <BF7E36B9C495A6468E8EC573603ED941152B1B4F@xmb-aln-x11.cisco.com>
References: <1693EFE1FD641C42A0D542FCBC732DE6BDE5BA3C@EX3.YODA.UTOPIA.LOCAL>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.129.24.90]
Content-Type: multipart/signed; boundary="Apple-Mail=_C49A6B86-81DB-4BCC-B8B9-5D73576ECDBB"; protocol="application/pkcs7-signature"; micalg="sha1"
MIME-Version: 1.0
Cc: Peter Waher <Peter.Waher@clayster.com>
Subject: [xmpp] Problems with draft-miller-xmpp-e2e [WAS: [Standards] Updated Yabasta Protocol (E2E-related)]
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2013 13:09:53 -0000

Forwarding to the proper discussion venue...

Begin forwarded message:

> From: Peter Waher <Peter.Waher@clayster.com>
> Subject: FW: [Standards] Updated Yabasta Protocol (E2E-related)
> Date: June 27, 2013 1:59:40 PM MDT
> To: "Matt Miller (mamille2@cisco.com)" <mamille2@cisco.com>
> 
> Hello Matt
> 
> Anything you would like to comment on, on the standards list?
> 
> Sincerely,
> Peter Waher
> 
> -----Original Message-----
> From: Jon Kristensen [mailto:info@jonkri.com] 
> Sent: den 27 juni 2013 15:30
> To: Peter Waher
> Cc: XMPP Standards
> Subject: Re: [Standards] Updated Yabasta Protocol (E2E-related)
> 
> Hi Peter, and thank you for your response!
> 
> These are the problems of the draft as I understand it.
> 
> It does not offer perfect forward secrecy, as the compromise of a private key would unlock all of the session keys protected by the corresponding public key.
> 
> It also does not allow for anonymity (neither weak or strong), as the public key is being sent in the clear.
> 
> A Diffie-Hellman key exchange request model could be used to tackle these problems, provided that two levels of <keyreq /> requests can be used. I don't know if this is part of the indended usage of the draft, or whether or not it would actually work. It would be great to see, though! Has any work been done to accommodate this feature?
> 
> I'm also a little concerned about the fact that the public keys is used to protect the session keys from a deniability perspective, but I haven't really thought that through enough yet. Maybe it's nothing...
> 
> Thanks again!
> 
> Jon
> 
> On Thu, 2013-06-27 at 17:25 +0000, Peter Waher wrote:
>> Hello Jon
>> 
>> Have you considered using the proposed draft for end-to-end encryption available at IETF?
>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-06
>> 
>> Sincerely,
>> Peter Waher
>> 
>> -----Original Message-----
>> From: Jon Kristensen [mailto:info@jonkri.com]
>> Sent: den 26 juni 2013 14:16
>> To: standards@xmpp.org
>> Subject: [Standards] Updated Yabasta Protocol (E2E-related)
>> 
>> Hello everyone!
>> 
>> The OTR-inspired and end-to-end secure Yabasta protocol has received a significant update today. You can see the updated protocol at <https://github.com/jonkri/yabasta-protocol/>.
>> 
>> The protocol now supports a higher degree of anonymity than it did 
>> before. The public key is no longer automatically transferred in the 
>> authenticated key exchange (as is the case with the Off-the-Record 
>> protocol). Instead, the key exchange only exposes a signature. Users 
>> can then perform various identity verification actions (such as
>> "challenges") to increase their trust in the remote peer before they reveal their public key. This is done so that clients can choose to consider their public keys a secret credential, and not automatically reveal their public keys to an active man-in-the-middle attacker.
>> 
>> The protocol has also been made more flexible. Clients can now configure things like what prime numbers to use for the Diffie-Hellman calculations, as well as what cryptographic and signing algorithms to use. Other updates include a separation between the abstract method and the actual protocol implementation, various clean-ups, and additional explanations to make the document easier to understand.
>> 
>> Feedback is more than welcome! :-)
>> 
>> Thanks!
>> 
>> Jon Kristensen
>> 
>> 
> 
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3345 / Virus Database: 3204/6445 - Release Date: 06/27/13

- m&m

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