Monthly Archives: April 2015

privacy-policy-538719_1280

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

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.

 

Kathleen Moriarty, Security Area Director

Internet Security vs. Quantum Computing

One of the great scientific challenges of our time is the construction of a practical quantum computer. Such a machine would use the counterintuitive principles of quantum physics, and it could rapidly explore an vast number of possible states. It could perform computational tasks that are far beyond our current capabilities, such as modeling molecules, designing new types of drugs, and of course, breaking most of the cryptographic systems that are in use today. Fortunately, no one has yet built a practical quantum computer, though many countries and companies are striving do just that. For example, the U.S. government has spent more than $80M USD on a project with that aim. Quantum computing is still an unproven technology, and it may not be practical for decades, but since it poses an existential threat to cryptography, we need to start preparing now for the possibility that one day quantum computing will become a reality. When that happens, we will be living in a post-quantum world.

Without actually having a quantum computer in hand, we are using theories to make educated guesses about the capabilities of these yet-to-be-realized machines. It is widely believed that the public key cryptography that is in widespread use today will easily be broken by a quantum computer. It is also believed that the symmetric encryption algorithms and hash functions will remain largely secure, perhaps requiring the larger key sizes that are already widely implemented.

Can we begin the work to replace the algorithms that we depend on today, including RSA, DSA, ECDSA, DH, and ECDH? The research community is hard at work identifying algorithms that will be secure against the threat of quantum computing. Significant progress has been made, and some public algorithms are believed to be secure. When this work is ready, the IETF will need to adapt protocols to make use of the new algorithms.

The U.S. National Institute for Standards and Technology (NIST) recently organized a Workshop on Cybersecurity in a Post-Quantum World. It brought together people from the research community, government, and industry from all around the world to start the work on the development and standardization of cryptography that will still be secure in a post-quantum future. NIST deserves a round of applause for this well-planned event, and the presentations and discussions showed that good work has been done, but more is needed.

We favor of a pragmatic systems engineering approach, in which we embrace algorithms that are the most mature and well-reviewed, and thus are the most deserving of our confidence, and that we then use systems engineering to mitigate the issues associated with those algorithms, such as large public keys. These algorithms have very large keys, and practical techniques are needed to handle them.

In our view, the first post-quantum secure algorithm to be standardized will be hash-based signatures. The security of hash-based signatures is well established. A well-engineered proposal for this type of signature was recently made to the IRTF Crypto Forum Research Group by Andreas Hülsing. If you are familiar with the original hash-based signatures proposed by Ralph Merkle in the late 1970s [1][2], you know that their main disadvantage is their long key generation time. The new proposal, called Extended Hash-Based Signatures or XMSS [3], uses multiple trees, in a hierarchical way, to solve that problem.

Other work has been brought to the IRTF and the IETF on hash-based signatures, including [4] and [5].

Let’s work together to keep the Internet secure in a post-quantum world.

David McGrew and Russ Housley

References:

[1] http://www.merkle.com/papers/Thesis1979.pdf

[2] http://en.wikipedia.org/wiki/Merkle_signature_scheme

[3] draft-huelsing-cfrg-hash-sig-xmss-00

[4] draft-mcgrew-hash-sigs-02

[5] draft-housley-cms-mts-hash-sig-02

IANA Protocol Parameters Explained

You may have heard about the IANA transition, or to be more precise, about the transition of US government oversight relating to IANA. In March 2014, the US government announced their intent to relinquish their role to the multistakeholder Internet community.

The communities served by IANA – such as the IETF – have been busy ensuring their systems are ready for this. In the case of the IETF, our community worked through a plan, and this plan was approved in January 2015. This plan calls for continuing the existing arrangements with regards to IANA as far as protocol parameters are concerned. Internet engineers have worked with the evolving IANA arrangements for more than 35 years, and more than 15 in the current setup. The system is mature today. It has handled and can handle IANA oversight adequately.

But we do get many questions around the IANA functions, particularly when meeting people who have not been involved in the IETF work. To begin with, what are protocol parameters? What is the role of IAB? What is oversight? Who draws contracts at the IETF? What role does the IAOC play? How can you ensure that the IETF leadership works according to the community’s wishes?

I wanted to share a few documents designed to answer these questions:

  • An introductory presentation describes how IETF deals with IANA functions and protocol parameters. You can find the presentation here.
  • An short document that describes the role of protocol parameters in the Internet, and what is the role various organisations. You can find the document here.
  • An earlier blog article discussed the importance of continuity in handling IANA functions. You can find the article here.
  • The official IETF plan for the transition is of course our primary document, and the document is here.

Hopefully you find these documents helpful. Do not hesitate to ask me or others at the IETF leadership if you have any questions on this matter.

Jari Arkko, IETF Chair

Plurilingüe IETF

ietfjournalru

La semana pasada, al hablar de Internet abierta para un evento de Gobernanza en Moscú, Jari se reunió con gente del Capítulo Rusia de Internet Society. ¡Habían hecho una traducción del Diario de IETF al ruso! Nos gustaría dar las gracias a ISOC, el capítulo y a Fedor Smirnov por este trabajo.

Esta visita nos impulsó a escribir un artículo sobre algunos materiales y foros en idioma no inglés que existen alrededor de la IETF. En primer lugar, el “Tao de la IETF”, nuestro documento introductorio clásico, está disponible en siete idiomas: alemán, español, francés, japonés, portugués, chino simplificado e inglés.

Julião Braga lideró un esfuerzo para compilar las versiones del Tao en portugués, español e inglés en “O Livro do IETF / El Libro del IETF” (“The Book of the IETF”). Este libro está siendo utilizado para formar a la comunidad latinoamericana rumbo al IETF 95 (Buenos Aires) y más allá.

Libro_IETF_New

Algunas de las sesiones de educación previas a las reuniones del IETF se han brindado en otros idiomas. Las diapositivas de orientación para recién llegados están disponibles en inglés, español, mandarín y francés. El papel de los estándares abiertos se ha destacado en los videos de ISOC en inglés, español y francés.

También hay listas de discusión en idiomas no inglés relacionadas con las actividades del IETF. Por ejemplo, hay una lista de correo para IETFers finlandeses. Sin embargo, durante mucho tiempo hemos tenido tantas personas que no hablan finlandés que terminamos hablando en inglés, y la mayoría estamos demasiado ocupados para encontrarnos en otros sitios que no sean las reuniones del IETF.

Una discusión mucho más activa se da en la lista de correo de IETF-LAC alojada por LACNOG, donde los participantes contribuyen en su idioma local (en su mayoría español o portugués, aunque puede utilizarse cualquier idioma). Es importante destacar que estas listas de correo están destinadas a facilitar los debates, sobre todo para los nuevos participantes. La estructura del IETF, incluyendo los grupos de trabajo y las listas, están pensadas para el avance de cualquier trabajo.

Probablemente hay otras listas por ahí. Si usted sabe de alguna, háganoslo saber para que podamos agregar la información en una wiki.

El inglés es claramente la lingua franca cuando se trata de tecnología, y es el idioma en el que se lleva a cabo el trabajo de la IETF. Sin embargo, cuando se trata de aprender sobre nuevos procesos y expresar opiniones es más fácil para todos en la lengua materna, por lo que el uso de múltiples idiomas para los debates y la educación local no debería ser una sorpresa para nadie en nuestro mundo multicultural. Capítulos de ISOC, grupos de operadores regionales o nacionales y la academia realizan reuniones multilingües a diario. Internet continúa creciendo, y aquellos de nosotros que ya estamos conectados nos beneficiamos de que participen en su desarrollo tantas personas como sea posible.

Si ustedes desean contribuir con una traducción del Tao en un idioma aún no disponible, por favor háganoslo saber.

Nos gustaría dar las gracias a Fedor, Julião, Lisandro, Cristiano, Antonio, ISOC,
sus capítulos, y a muchos otros por apoyar estos esfuerzos. Son
importantes en la comunicación de lo que es y hace el IETF, y contribuyen a la bienvenida de más participantes en nuestro trabajo.

¡Gracias!

Jari Arkko, Presidente de IETF y Alvaro Retana, Routing Area Director
(Versión española por Christian O’Flaherty. Click here for the English version.)

New Datatracker UI

datatracker

The upgrade to the datatracker UI mentioned in plenary at IETF 92 has just been released. This effort has been underway for more than a year.

Lars Eggert began the effort, working intensively on porting the GUI to Bootstrap. The work took 287 separate commits, and comprised changes to 1016 different files.

The IETF Datatracker is now a responsive website which supports use on a much larger variety of devices, from small mobile devices to desktops.

The work relies heavily on the capabilities of Bootstrap, and continues to use the Django framework which the datatracker has been built on since version 2.00. It also uses new icons from FontAwesome, functions from django-bootstrap3.

Additional page conversion work has been done by Ole Laursen, and final style tweaks, bug-fixes and adaptations were performed by Henrik Levkowetz. There is more information about this release at http://datatracker.ietf.org/release/about

As before the best way to report any issues with the datatracker is to follow the “Report a Bug” link in the footer of each page.

Please join me in thanking Lars for this major effort! I would also like to thank Ole, Henrik, and everyone else who works on the datatracker and other IETF tools.

Robert Sparks, Datatracker Project Manager

Monikielinen IETF

ietfjournalru

Last week, while speaking about open Internet in Moscow for an Internet Governance event, Jari met with folks from the Internet Society Russia Chapter. They had recently made a translation of the IETF Journal to Russian! We’d like to thank ISOC, the chapter, and Fedor Smirnov for this work.

This visit prompted us to write an article about some non-English materials and forums that exist around the IETF. First, the “Tao of the IETF”, the classic introductory document exists in seven languages: Deutsch (German), Español (Spanish), Français (French), 日本語 (Japanese), Português (Portuguese), 简体中文 (Simplified Chinese), and English.

Julião Braga led an effort to compile the Portuguese, Spanish and English versions of the Tao in “O Livro do IETF / El Libro del IETF” (“The Book of the IETF“). This book is being used to aid in the education of the Latin American community towards IETF 95 (Buenos Aires) and beyond.

Libro_IETF_New

Some of the education sessions before IETF meetings have been run in other languages. The newcomer’s orientation session slides are available in English, Spanish, Mandarin, and French. The role of open standards has been highlighted in the videos from ISOC in English, Spanish, and French.

There are also non-English discussion lists related to IETF activities. As an example, there is a mailing list for Finnish IETFers. However, for a long time we have had so many non-Finnish speaking people that we just speak English, and we’re mostly too busy to ever meet anywhere else than in IETF meetings.

A far more active discussion happens in the LACNOG-hosted IETF-LAC mailing list, where participants contribute in their local language (mostly Spanish or Portuguese, but any language can be used). It is important to highlight that these mailing lists are intended to make discussions easier, mostly for new participants. The IETF structure, including WGs and other lists, are expected to be used to progress any work.

There are probably other lists out there. If you know of one, let us know so that we can add the information to a wiki.

English is clearly the lingua franca when it comes to technology, and it is the language in which work of the IETF is conducted. However, learning about new processes and expressing opinions is easier in anyone’s mother tongue so the use of multiple languages for local discussions and education shouldn’t be a surprise to anyone in our multi-cultural world. ISOC Chapters, regional or national operator groups, and academia conduct multilingual meetings on a daily basis in many different languages. The Internet continues to grow, and those of us already connected benefit from as many people as possible being able to use it and participate in its ongoing development.

And, if you would like to contribute a translation of the Tao in a language not yet available, please let us know.

We would like to thank Fedor, Julião, Lisandro, Christian, Antonio, ISOC,
their chapters, and many others for supporting these efforts. They are
important in communicating what the IETF does and is, and welcoming more
participants to our work.

Kiitos!  Gracias!

Jari Arkko, IETF Chair and Alvaro Retana, Routing Area Director
(Véase también la Versión española)

RFC 1

Today marks the 46th anniversary of RFC 1.

Happy birthday, RFC series!

This is also an opportunity to reflect on the RFC series and the principles behind it.

For example, we have had recent work to reconsider the canonical format, aiming to increase the usability of the RFC series and to match the needs of a even wider variety of readers. And of course, broad community input and technical excellence in the RFCs are the things that can help make the Internet work better.

Today, the RFC series includes more than 7000 documents. Published on the 30th anniversary of RFC 1’s publication, RFC 2555 assembles recollections on the RFC series.

The RFC series includes many different kinds of documents. Documents coming out of the IETF, documents coming out of the IRTF, independent stream documents, and so on. Not to mention April 1 RFCs, which we again got to enjoy a couple of days ago. Long live the RFC series!

Jari Arkko, IETF Chair