What can the IETF learn from History? Lessons from Heisenberg

Can we learn something about inclusiveness from history? A look at the 1920 physics conferences.

The Internet Engineering Task Force has had an ongoing debate about inclusiveness in many dimensions. Many of us lament that there are not more women engaged in the industry; and that we are unable to engage in a better way engineers from developing countries. However, there is also a debate about the interdisciplinary aspects of our work, where the merits of engaging beyond the engineering discipline becomes a bit less clear.

In the early 1990s Marshall Rose somewhat cynically coined the term many fine lunches and dinners to describe conferences like the IETF.¹ It is comforting, therefore, to have learned that we were following in the footsteps of great minds.

In the 1920s, there were a number of physics conferences, and one in particular in Brussels that featured Bohr, Einstein, Planck, Born, the Joliot-Curies, Pauli, Heisenberg, and others. The vast majority of the attendees were Europeans (and men). The European aspect was due to location of the conference and the difficulty of traveling across continents.

“God does not throw dice” was the hotly debated statement versus quantum theories. Heisenberg later recounted that they all stayed in the same hotel, and that the real discussions occurred not during the paper presentations, but at dinners.² I don’t think we can say that those conferences were where the true discoveries occurred, but I think they helped in directing researchers in the right direction. This is why the IETF meets in person from time to time. This is also why hybrid work is so important, where one splits time working with others and on one’s own.

People who attended those conferences in the 1920s were physicists, and they were very focused on a very narrow a particular aspect of physics, even though those aspects had profound consequences to society. Had they invited philosophers, my take is that the philosophers would have gotten in the way, and neither group would have gotten anything out of the interchange.

IETF conferences and work styles are aimed at engineers. That aspect should not change, and in some cases perhaps it should even revert a bit. However, the practice of engineering evolves, just as the understanding of physics did back then. A colleague of Einstein’s dressed him down for using such a simple platitude as an argument, and you can read in the record how the “old guard” (yes, even Einstein) was slow to accept new concepts. This sounds eerily familiar, and is a cautionary tale to those of us in that group to pay attention to new concepts.

Engaging new blood is key to any organization. Traveling internationally to new places to find new people may or may not be valuable. The IETF tried this in 2014 by traveling down to Buenos Aires, to see if we could engage more people. The answer seems to have been no, but the costs of going to Argentina also seemed relatively small. To me, it increasingly difficult to justify in this day and age that the conference has not been held in India.

Rose, M., The Open Book: A Practical Perspective On OSI, Prentice Hall, 1990. ↩︎
Rhodes, R., The Making of the Atomic Bomb, Simon and Schuster, 1987. ↩︎

Happy Birthday, IETF

There’s a small group that hosts meetings three times per year, and works mostly via email that you’ve probably not heard of. They’re called the Internet Engineering Task Force or IETF. The women and men who participate in the IETF create standards by which computers communicate with one another. You’re reading this note thanks to several of those standards. They are collected in documents known as Requests for Comments or RFCs that are available for anyone to read. In fact, you can write your own if you want.

The IETF became important to me at a time when we were just learning how to manage congestion (more demand than there is bandwidth). It stayed important when we needed more efficient routing protocols. Through internationalization efforts at the IETF, the Internet grew from a U.S. government network to a worldwide network of networks that supports people speaking just about any language.

Last week marked the IETF’s 30th birthday. To the thousands of people who have participated over those thirty years, especially to those who aren’t with us today, I want to say this: Thank you. Thank you to those who have worked to make TCP/IP-based networking suitable for the way we live, work, and play. Thanks to the people who have done their level best to see that our protocols are safe and secure. Thanks to those who shared their innovations, so that the best ideas are available for all to use. Thanks to those who devoted their lives to handling all the administrative aspects of the organization.

So now you know who the IETF is. You too can participate, as can anyone. For more information, just go to www.ietf.org and join the party and celebrate with us this anniversary, and the ones in the future.

Mark Crispin: 1956 – 2012

Mark Crispin passed away on the 28th of December. While I didn’t know him well, Mark was a very important visionary in the area of Internet applications, and Email and character sets in particular.

I first enjoyed his work as a user of the MM program on TOPS-20, upon which he based the design of IMAP. MM featured strong searching and marking capabilities, as well as all the customization a person could want. It was through MM that people individualized their messages with funny headers or a cute name. And it was all so easy to use. Mark was constantly reminding us about that, and how UNIX’s interface could always stand improvement. Mark was an unabashed TOPS-20 fan.

Before the world had fully converged on vt100 semantics, Mark worked to standardize SUPDUP and the SUPDUP option. He was also early to recognize the limitations of a single host table. Mark’s sense of humor brought us RFC-748, the Telnet randomly-lose option, which was the first April 1 RFC. He also wrote another such RFC for UTF-9 and UTF-10.

Most of us benefit from Mark’s work today through our use of IMAP, which followed Einstein’s advice by having a protocol that was as simple as possible to tackle the necessary problems, but no simpler. We know this because our first attempt was POP, which was too simple. Mark knew he had hit the balance right because he made benefited from his experience with lots of running code and direct work with many end users.

I will miss his quirkiness, his cowboy boots, and his recommendations for the best Japanese food in a town where the IETF would visit, and I will miss the contributions he should have had more time to make.

WCIT and the ITU?

The International Telecommunications Union (ITU) is making the news these days, in part because there is about to be a treaty conference called the World Conferences on International Tariffs (WCIT). What is the ITU? and what do they do?

The ITU is a specialized agency of the United Nations that focuses on telecommunications. It has four components:

A general secretariat;
A standardization sector or ITU-T;
A radio coordination sector or ITU-R; and
A development sector or ITU-D;

The radio sector coordinates spectrum allocation and so-called “orbital satellite slots”. It also is responsible for standardization of time. The development sector focuses on the special needs of developing countries. The standardization sector has over 150 years set international standards for telecommunications, starting with the telegraph. The general secretariat manages logistics of the three sectors, and represents the ITU to other international fora, and to the U.N.

How has the ITU been relevant to you? There are several key standards that are worth taking note of:

E.164 specifies pretty much what a telephone number looks like, starting with the international dialing code.
G.711, G.719 and others specify how voice is encoded into data.
X.509 is the basis for the public key infrastructure that is in use on the World Wide Web.
D.50 specifies accounting standards by which international carriers bill each other, or so-called settlement rates. There’s real money involved in this one.

This is some pretty important stuff.

The ITU-T was formed out of the CCITT, which was a coordination committee, primarily made of European governments. These days, its membership spans 193 countries. Only governments may vote, although civil society and paying sector members may have some influence.

So what is WCIT? WCIT is a treaty-level conference in which all those lovely accounting rates are agreed upon. But they’re not stopping there. The ITU-T has had a very limited role in the Internet’s development. Standardization and governance over the Internet falls to several classes of entities:

National governments with their own sets of laws;
Standards organizations such as the IEEE, IETF, W3C, and 3GPP; and
Not-for-profit organizations such as ICANN and Internet Registries.

This latter group focuses on what I call “internals”. That is- how do you get an IP address or a domain name? The Internet has grown over 1.25 billion users with very limited involvement of the ITU-T.

Now governments want to take a firmer hand in areas such as how addresses and names are allocated and cybersecurity. That is what WCIT is about.

More about the ITU and WCIT in the future.

Web (in)Security and What Can Be Done

We all like to think that web security is perfect, but we all know better. You know about spam, phishing, and all manner of malware. You probably run a virus scanner on your computer. But what you don’t expect and shouldn’t expect is that the core of our security system would have a flaw. It does, and has, from the beginning. What’s more, it’s a known flaw.

How is it your browser decides to trust a site, or to show that lovely lock icon and perhaps a green URL bar when your communication is both encrypted and verified to be to a specific end point? The simple answer is that your browser provider, Microsoft, Mozilla, Apple, or Google, has made a decision on your behalf that – at least as initially configured – your browser will trust a certain set of authorities– certificate authorities (CAs)– who will validate others.

One such certificate authority got hacked. Badly. And because they were trusted by your browser, so might you have been. Here’s how it works.

When you access a URL that begins with “https”, a certificate is sent by that site that is signed by one of the trusted CAs, saying “yes, I agree that this is google.com,” (for example). If someone gets in between you and Google, they won’t have the private key associated with that certificate, and they won’t be able to validate to your browser.
If someone breaks into a CA and gets a certificate for “google.com” (again, for example), and then gets between you and the real Google, they will be able to masquerade. It doesn’t matter which CA it is, as long as your browser trusts it. Google needn’t have any relationship with that CA.

This is what happened with DigiNotar. Not only did they get hacked, but they didn’t notice. They didn’t have sufficient controls in place to even spot the attack. That they should have had.

But now there’s something else we can do. In the Internet Engineering Task Force (IETF), a few folks led by a gentleman by the name of Paul Hoffman have developed an approach where sites like Google can effectively register which certificates are valid for them in an separate alternative authority that we largely trust, the Domain Name System (DNS). You use DNS to convert site names like ofcourseimright.com to IP addresses like 10.1.1.1.

The group working on it is called “dane“. Had the dane mechanism been in place in the browser, the attack on Diginotar and Google would have failed, even if Google was a customer of Diginotar (which they weren’t).

When we speak of security we always discuss defense in depth. That is– never rely on exactly one mechanism to protect you, because at some point it will surely break. In this case, the attacker needed to (a) compromise the CA and (b) get in between the service and the end user to succeed. Had dane been in place, atop (a) and (b), the attacker would also have to have compromised Google’s DNS for the attack to succeed. That’s likely even harder than compromising a CA.

Dane has another potential benefit: in the long run, it may get browsers completely out of the business of telling you who to trust, or it will extremely limit that trust.

This attack also demonstrates that as threats evolve our response to those threats evolves. Here we understood the threat, but just didn’t get the work done fast enough before a CA was compromised. I still call this a win, as I think we can expect to see dane even faster than we expected before the attack.