Skip to main content
  • IETF 118 post-meeting survey

    IETF 118 Prague was held 4-10 November 2023 and the results of the post-meeting survey are now available on a web-based interactive dashboard.

    • Jay DaleyIETF Executive Director
    30 Nov 2023
  • Net zero update for 2023

    An update on the IETF’s carbon footprint over the past year and efforts going forward to increase the sustainability of how the IETF operates.

    • Greg WoodIETF LLC Director of Communications and Operations
    • Stephanie McCammonDirector of Meetings and Sponsorships, IETF Secretariat
    29 Nov 2023
  • IETF 118 Highlights

    The IETF 118 meeting was held in Prague in early November. In general, the meeting was productive and full of lively discussions fueled by 1067 onsite participants, and 1806 participants altogether.

    • Christopher A. WoodIAB Member
    28 Nov 2023
  • Cisco to host IETF 121 Dublin meeting

    I am pleased to announce that Cisco will be the Host for IETF 121 Dublin, 2-8 November 2024.

    • Jay DaleyIETF Executive Director
    6 Nov 2023
  • Suggested IETF 118 Sessions for Getting Familiar with New Topics

    These IETF 118 meeting sessions included discussions and proposals that are accessible to a broad range of Internet technologists whether they are new to the IETF or long-time participants.

      4 Nov 2023

    Filter by topic and date

    Filter by topic and date

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

    • Kathleen MoriartySecurity Area Director

    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