On 04/07/2014 11:29 PM, ianG wrote: > On 8/04/2014 03:13 am, Pranesh Prakash wrote: >> Dear all, >> In the March IETF 89 meeting in London, there were renewed discussions >> around end-to-end encryption in XMPP. >> >> Here is the recording of the session: >> >> http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=IETF89_XMPP&chapter=part_5 >> >> >> There was basic agreement that OTR is a horrible fit for XMPP since it >> doesn't provide full stanza encryption. The very reasons for the >> benefits of OTR (its ability to be protocol-agnostic) are the reasons >> for its shortfalls too. >> >> However, there is no clear alternative. The closest is >> draft-miller-xmpp-e2e. The one clear verdict was that more contributors >> are required. > > Has anyone got a text-based summary of what this is about? I'm happy > to read, but I find listening to recordings doesn't really work. > > >
Better late than never: >From http://www.ietf.org/proceedings/89/minutes/minutes-89-saag : Matt Miller presents Securing XMPP End-to-End Matt Miller (XMPP): off the record (OTR). Problems: finding a stable reference for OTR. Only covers normal fonts, invents new crypto. Support lacking for multiple devices on-line simultaneously. Paul: document is nearly stable. XMPP end to end. Protects whole stanzas. Works with multiple devices on-line at the same time. Reuses JOSE. Issues: PFS undefined. No support for store and forward (i.e. when other party is off-line). Need security input and review. Open to ideas. Peter St Andre: XMPP designed for more than IM. So, ability to protect more than just the typed text is important. Hildebrand: non-normal fonts are not protected (e.g. Boldface). If helpers don't participate then this aspect will not be addressed. MM: there are drafts that attempt to protect everything. SF: suggest address a practical subset of all problems. DKG offers to help with protecting time and similar components. He also mentioned that the currently-defined algorithm is insufficiently secure. Paul: Don't want a complicated list of algorithms for users to choose from. RH: asking about support for agility. Paul: planning to implement new algorithms with a version change. Hannes: interesting to observe that some prefer software update mechanism for agility. Paul: algorithms are identified by number to support negotiation and agility. Peter SA: the community is quite tight, so it is practical to implement agility this way. PHB: algorithms don't break catastrophically. Steve Kent: presence procedure could announce algorithm support. Tim Polk: pull-downs are needed only when support still exists for weak algorithms. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
