Skip to main content
  • New Internet Architecture Board, IETF Trust, IETF LLC and Internet Engineering Task Force Leadership Announced

    Members of the incoming Internet Architecture Board (IAB), the IETF Trust, the IETF Administration LLC (IETF LLC) Board of Directors, and the Internet Engineering Steering Group (IESG)—which provides leadership for the Internet Engineering Task Force (IETF)—have been officially announced, with new members selected by the 2021-2023 IETF Nominating Committee.

      13 Feb 2023
    • Informing the community on third-party correspondence regarding the W3C

      In accordance with our policy of transparency, this blog post is being published in order to keep the community informed about recent correspondence with lawyers acting on behalf of the Movement for an Open Web.

      • Lars EggertIETF Chair
      8 Feb 2023
    • Six Applied Networking Research Prizes Awarded for 2023

      Six network researchers have received Internet Research Task Force Applied Networking Research Prize (ANRP), an award focused on recent results in applied networking research and on interesting new research of potential relevance to the Internet standards community.

      • Grant GrossIETF Blog Reporter
      9 Jan 2023
    • Travel grants allow Ph.D. students to participate at IETF meeting in-person

      Sergio Aguilar Romero and Martine Sophie Lenders, both Ph.D. students in technology fields, attended and participated in the IETF 115 meeting in London with assistance through travel grants from the Internet Research Task Force.

      • Grant GrossIETF Blog Reporter
      7 Jan 2023
    • Impressions from the Internet Architecture Board E-Impact Workshop

      The IAB ran an online workshop in December 2022 to begin to explore and understand the environmental impacts of the Internet. The discussion was active, and it will take time to summarise and produce the workshop report – but the topic is important, so we wanted to share some early impressions of the outcomes.

      • Colin PerkinsIAB Member
      • Jari ArkkoIAB Member
      6 Jan 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