Skip to main content
  • IETF Administration LLC 2025 Budget

    A draft budget was shared previously for community consultation and the IETF Administration LLC now has finalised its budget for 2025.

    22 Jan 2025
  • RFC Production Center management transition

    After an extensive review of recent developments in the RFC Editor function, the IETF Administration LLC (IETF LLC) and Association Management Solutions LLC (AMS) have agreed that the IETF LLC will assume management of existing RFC Production Center (RPC) staff, under an Employer of Record arrangement with AMS, the employer of the RPC team.

    5 Jan 2025
  • Workshop on the Decentralization of the Internet at ACM CoNEXT 2024

    The recent Decentralization of the Internet (DIN) workshop at ACM CoNEXT-2024 brought together network researchers, law and policy experts, and digital right activists to discuss the consolidation and centralization of the existing Internet applications, services, and infrastructure observed in recent years.

    19 Dec 2024
  • Launch of the IETF Community Survey 2024

    The IETF Community survey is our major annual survey of the whole of the IETF community and is used to inform the actions of IETF leadership throughout the year. The 2024 IETF Community Survey is live and we want to hear from you!

    19 Dec 2024
  • Second IASA2 Retrospective Report

    The IETF Administration LLC (IETF LLC) has now completed the second IETF Administrative Support Activity (IASA 2.0) retrospective. The report was developed with community input and review, and is now available online.

    18 Dec 2024

Filter by topic and date

Filter by topic and date

End-to-End Message Encryption — Can it be done?

30 Apr 2015

End-to-end (e2e) encryption for email is hard. We know this from OpenPGP and S/MIME efforts with the main problem being around obtaining, installing, and exchanging keys.

privacy policy

End-to-end (e2e) encryption for email is hard. We know this from OpenPGP and S/MIME efforts with the main problem being around obtaining, installing, and exchanging keys. While there are a number of positive efforts to fix e2e encryption for email, it may take a while for a viable easy to use solution to be deployed and actively used.  What if instead, we think more about what we want to communicate that needs to be encrypted and if a shift is needed to be open to new solutions?

Today with social media, we are trending toward texting and instant messaging as a default form of communication.  We typically use these technologies for quick messages and some, like XMPP have e2e encryption capabilities already… but it could be better.

Wouldn’t it be nice to have less mail to manage?  As we all know, quick messages and discussions are better suited to XMPP, SMS, or other IM related protocols.  Using these technologies gets you away from managing an unwieldy inbox, and if  it’s encrypted at the data level (e2e) you don’t have to worry about exposing that data.

XMPP already has Off-the-Record (OTR) encryption support, so aren’t we done?  No, that would be nice.  OTR is lacking some features and the crypto could be improved upon, but it certainly fits the bill for easy-to-use.

Developers and some XMPP working group participants have plans for new features and need to gauge support from the community.   Improved e2e functionality has been proposed in IETF drafts in the past, but has not gotten enough attention and really could help us improve our e2e capabilities for messaging.  Some of the features proposed include:

  • The ability to send encrypted messages when the recipient is offline, where the recipient can read the messages when they come back online
  • e2e encrypted group chat
  • Improved security and reliability of e2e encryption solution for messaging
  • ‘device mobility’ or the ability to send and receive messages on any of your devices
  • added accountability, to know who has the ability to read messages and who
    has the ability to confer that ability to others

If XMPP were favored in cases when you prefer to have your messages encrypted, it may lessen the need for e2e encrypted email, shifting how we accomplish communication goals.  For those unfamiliar, the XMPP protocol provides instant messaging or chat.  Use of instant messaging embedded in other tools makes this a more accessible method of communication for every day users, that may not be technical, but want their privacy protected with encryption.

So you say OTR is good enough.  Is it really?  While I do use OTR quite often and am glad to have it, it doesn’t always work.  An OTR session could break and send your text in the clear without forewarning.  This could be a problem.

Not only that, file transfers (both meta-data and data) are also completely unprotected by OTR, without warning in most user interfaces.  Along with many of the other protocols on this list:

A couple of highlights of XMPP extensions impacted:

  • Presence — Your presence is visible to everyone you’ve subscribed to — and all of the servers between you and them.
  • File transfers — and the associated metadata — are completely
    unprotected by OTR.
  • Vcard  — exchanging contact information in XMPP — that too is exposed with current OTR implementations
  • etc.

all of which have the potential to leak personal information without e2e encryption.

What’s needed?

Interest expressed in this work with active reviews and contributors on requirements and proposals to drive work on end-to-end encryption for XMPP forward.  This could be a game changer.


Share this page