Day 0, 8/11/97
It took two airplanes, a train, a trolley, and a car -- 9 hours and 6 timezones -- to get me here, in the real world.
But it's only a few hops on a really nice (E-3) link between Ger- many and New Jersey, if you travel on the Internet.
This week we'll be spending our time with about 1,100 other hard- core networking engineers ("geeks" would not be an unfair description) at the IETF meeting in Munich. We'll be sending back reports on what's hot, what's the buzz, and what's being debated in this thrice-yearly retreat for the plumbers of cyberspace. We'll be covering the network security field, along with a few other related topics.
The IETF works on "rough consensus and running code," sometimes derisively referred to as "rough code and running consensus." It's an all-volunteer organization which collaborates together on Internet protocol standards, such as TCP/IP. People work together, mostly through mailing lists but with some conventional interaction, in "Working Groups." These groups write "Internet Drafts" which, if they make it through the process, become standards known in the jargon as "RFCs," or Requests For Comments. The conventional interaction is mostly these triennial meetings, with an occasional sprinkling of interoperability trials here and there.
This week we'll be covering the TLS, IPsec, PPP, and SSH Working Groups. Translated into English, that's the efforts to standardize:
So it's Sunday. Most of the folks are here already. The IETF is dominated by U.S. participants, so most of the people in the hotel lobby have that glazed look of someone who had a bad time trying to sleep on an airplane last night. The only people whose faces are more glazed are the "newbies" -- the newcomers who went to the introductory session held on Sunday afternoons to attempt to explain the arcane workings of the IETF. What can we tell from Sunday, when the meetings haven't started yet? People are starting to network (in the human sense), meeting over beer and cappuccino in the lobby to discuss packet formats. News of who's changed jobs and who's showing up again after missing a few meetings. There are those who follow these things year in and year out (this is the 39th meeting) and those who only attend when their work requires it.
Who's here? Microsoft has 19 people. Cisco has 34. Bay Networks, not always well represented, has 29. FTP Software, which is suffering from its own internal problems, is only sending 3 and one of them flies back to Boston at the end of the week to be "transi- tioned" (a Dilbertesque euphemism for being laid off.) These are actually good numbers -- the California meetings are stuffed with "uninformed Suits and tire kickers looking for a free education in networking," as the crusty old timers will grumble.
Well, it's 1 AM and unlike my PC's packets, I'm not doing all that great with having hopped the Atlantic last night, so that's all for now -- we'll be sending another report tomorrow.
Day 1, 8/12/97
It's 9:45 PM. I'm sitting in a meeting room in the hotel. It's set up with tables, arranged in rows to seat perhaps 200 people. Half of these chairs are at empty tables, with an ethernet plug and a power plug on the table. The other half of the seats have Silicon Graphics workstations or PC's. On the side of the room are three full-height equipment racks full of routers and perhaps six Silicon Graphics servers. All of this connects to a high-speed (64 megabit) digital link across the parking lot to a nearby office building, where it connects into the European public Internet. It takes a half a second for an IP packet to travel from my laptop in Germany to my ISP in Massachusetts. Thinking about the alleged traffic jams on the Internet, consider it's 11 IP packet hops from Germany to Massachusetts. I'd tell you how many packet hops it is from my home system to Microsoft's web site, but Microsoft's web site is not responding :-)
This room has so much bandwidth, people are commenting that they get better performance reading their mail here than they do at home through their modems. I saw someone in here this morning, wearing headphones, speaking into the microphone on his PC. He was speaking Hebrew so I suppose he was talking to Israel.
Today the meetings started. The security item for the day is SPKI, pronounced "spookie." This is a digital identification system. It's being discussed at the IETF meeting because there is a raging theological debate among people who advocate digital identification standards. [Sounds exciting, doesn't it?] In one camp are the old-guard, ex-government contract suppliers, who think "identity cards" are what you issue to tank drivers while they are on patrol in Bosnia. These people prefer a scheme known as ITU X.509. Other people, who don't like the complexities of this system, have proposed their own alternative, called the "Simple Public Key Infrastructure." This conflict is somewhat of a cause celebre since some of the Big Names in the crypto world are involved in SPKI, including Ron Rivest of RSA fame and several senior cryptographers from Lucent (Bell Labs). These people have more of an organic view of identity, which is closer to the PGP "web of trust" model than it is to some sort of national identity card.
In addition to the formal activities, of which the security area is only a small part, there are the informal meetings, in the halls, in the lobby, in the area restaurants. Every day at lunch and dinner the attendees spill out of the hotel like a cloud of digital locusts to overwhelm the local restaurants, talking rapidfire of "criticality object identifiers" and "5-tuple reductions."
Day 2, 8/13/97
If it's Tuesday it must be time to talk about PGP. Not only does the IETF have digital signature efforts underway using "mainstream" X.509 in the PKIX group, and "Simple" PKI work in the SPKI group, but yet a third activity has been proposed, to start the process of formally standardizing PGP.
Now you might think that the IETF looks at these Working Groups like Pit Bull Terriers. You can easily determine the strongest and best one by confining them all to a small enclosed space with a small piece of raw meat. Some people here in Munich think this is how the IETF decides what proposals get Working Group status.
But the consensus is that PGP is a Good Thing for the IETF to be thinking about. It is real technology that is known to work because it's being used today, and the dominant vendor, PGP Inc., is proposing that the "PGP certificate" format be opened up to the IETF standards process.
But then arises... (drumroll please)...
The Danvers Doctrine says "We'll design security protocols to be strong, without regard to politics, government policy, or other external issues."
Now this sounds really smart if you're a techie designing a crypto protocol. Make it strong. Make it safe. Make sure your users will be protected. Good stuff, right?
There's a downside. What happens if major vendors were to start ignoring the IETF? It's a problem that some feel has to be addressed. Strong crypto is a "motherhood and apple pie" thing to these Internet folk, but if they alienate the vendor community they could have more significant problems.
The Danvers Doctrine as applied to PGP guarantees that today will kick off a raging debate over what cryptographic mechanisms must be implemented. Now, in the IETF, there's a standard for everything. In particular, the word must is defined, in RFC-2119. The definition could mean, perhaps, that a hypothetical "Open PGP" would be described in such a way that in order to be compliant with the standard you must implement Triple DES. Nice and strong. Nice and safe. Nice and impossible to export from the U.S. Now, setting aside all the theological, political, constitutional, rational, and irrational reasons why this may be a good idea, it would put U.S. vendors in the position of being unable to ship compliant implementations that are exportable. And that's bad for business. And that could make U.S. vendors worry less about the IETF, or even start to ignore its standards.
And that would be Very Bad Thing indeed.
Note: Thayer signed the dispatch below using PGP 5.0. For those who might want to check its authenticity, I've put his unedited dispatch, with signature in place, on the TBTF archive. To my embarassment I was not able to check the signature myself: both my everyday crypto utility (FileCrypt, from the Dutch company Highwire) and PGP 2.6.2 for the Macintosh choked on it. After I posted the piece with this comment Thayer sent the following email, whose signature I was able to verify.-----BEGIN PGP SIGNED MESSAGE----- I am sorry I used my DSS signature instead of my RSA signature, thus causing you to experience the joys of PGP interoperability, or lack thereof. It was 2 in the morning and I just came back from a spontaneous bull session about ISAKMP. [feel free to post this email too...] [and now I'll touch the proper knobs and dials to RSA sign this, I hope...] -----BEGIN PGP SIGNATURE----- Version: PGP for Personal Privacy 5.0 Charset: noconv iQCVAwUBM/LvDsKmlvJNktGxAQHHDgQAmqOVlMeQPy57dYbm/E5VnH1CwQGlonmG afQ65emD8tg5B4+P4Z42ve5ts1Ok29J4UGQ4v7IkRgmXJKwqX2UKXuIaq8qZaOon kmPWghwKnm/6tHOk5hq57Hz5c67IjX+Ur5WUzZMhm86I+nbfW0EHBNXhrhZgWJdh /MERq3wS804= =Hwn3 -----END PGP SIGNATURE----- -- Rodney Thayer Sable Technology +1 617 332 7292
Day 3, 8/14/97
The days are getting busier as the week progresses. The fellow from Digital loaned out a couple of dozen wireless modem devices so now there are people scattered all over the hotel lobby sitting on couches logged on to the net through these little black boxes sticking out of the back of their laptop computers.
Today the SSH (see, I didn't spell it wrong), PKIX, CAT, and Key Signing meetings were held. A busy day indeed for the crypto weenie.
SSH is Secure Shell. It's a tool set and a protocol to allow secure "shell" (character console) access across the net to Unix and other systems. SSH too is sort of redundant with TLS, but it too is deploying now and therefore it's considered logical to have a working group. Besides, those Finnish folks from Data Fellows have such cool accents!
PKIX is public key infrastructure, done with X.509 certificates, like they use in Netscape and Microsoft web servers. It meets twice. The documents are pretty hefty. Check out the drafts. There will be a short quiz the next time you go to use your credit card, or driver's license, or passport...
The Key Signing was the PGP Key Signing "Party" held at the IETF. People stand up and read their PGP hash values so you can confirm you can match a key to a person. So if you don't see a hash of 6661-a3e2-51e0-940c-cb30-15c8-8c29-564f-e0bc-97ea, don't trust the key you're using to authenticate this message.
As the conversations continue, it becomes more evident that the crypto policies of the United States are at least a little odd. It's sometimes embarassing. I can stand in the hallway at this public conference and talk about encrypting network packets. I can go back to my laboratory and encrypt packets. The lady across the room from Israel, the gentleman from Finland, and all the others in the room know it's clear we all possess the same technology (and sometimes theirs is better!), but I have to avoid exporting products that do this so the U.S. government can restrict access to Triple DES outside this country?
Say what? Do you think there are no crypto people east of Nova Scotia? Don't you know they've uncovered prehistoric caves in Central Europe with drawings of people rubbing two long primes together to get a block cipher? I mean, it's arithmetic. It's not like the genie is going to stay in the bottle. As someone once said, it's like erecting stop lights in space.
Day 4, 8/15/97
Today we had another PKIX meeting. Perversely it was held in the same room as the PGP key signing last night, so we walk in to talk about X.509 certificates and there are handouts sitting at the back of the room listing peoples' PGP fingerprints.
This time in the PKIX meeting we talked about the protocols used "on the wire" to support one computer (the client) submitting a certificate request to another computer (the Certificate Authority). There are two proposals, one called "PKIX Part III," by Adams (Entrust) and Ferrel (SSE), and another called "Internet Public Key Infrastructure", by Myers (Verisign), Deacon (Verisign), and Liu (Cisco). The latter was quite new, having been published only at the end of June, after the draft deadline for the meeting. (The publishing deadline assures that the drafts get onto the Web site before the meetings.) It's late in the process: the other proposal, "Part III," is already scheduled to go to "last call" (i.e., to be promoted to the next level in the standards process).
There was a vigorous discussion about this newer proposal, with people from Entrust, Verisign, Microsoft, and others taking turns at the microphone. It develops that the PKIX 3 document (kind of, sort of) requires that the protocol support key recovery. This got some folks a little excited.
The debate was sociologically interesting. Most people are spectators in these little pieces of technical theatre. They can't be otherwise: the drafts can be quite obtuse, and it's sometimes really hard to follow what's going on. One does tend to draw conclusions based on who makes comments, who sits beside whom, etc. I made some comments, and while doing so suddenly realized that I was sitting next to the folks from Microsoft, who also were fairly vocal. From the spectator's point of view I could have appeared to be "with" Microsoft on this issue. Surreal. I've uttered my share of choice comments about Microsoft (and about Verisign, and about other vendors). I'm not their lap dog, but it could have appeared I was playing one at this IETF. But that sort of spontaneous intersection of opinions happens at these meetings, which is part of what makes them so engaging.
See, I told you there'd be a PKIX quiz :-)
Day 5, 8/16/97
It's Monday evening. The IETF meeting ended last Friday, at approximately 11:30 AM, local time.
So why am I writing this on Monday? Well, as the techies would say, "the IETF doesn't scale well."
It seems that, traditionally, IETF meetings were always four days in length. However, due to the number of groups meeting, that became difficult. They even went to evening meetings (thus interfering with the important business of schmoozing with one's fellows) and still four days wasn't enough. So it finally dawned on them to expand the meeting to five days. This was a fine idea, except that the traditional thing to do was to shut down the network in the terminal room late Thursday or early Friday. This meant that the network connection went away moments after the end of the last meeting, thus I was stuck (gasp!) without an Internet feed.
Add to this the non-compatability of German telephones and my US modem, plus a day's travel to get back to my office, and you end up with me writing the Day Five report on Monday.
But back to my IETF story.
On Friday, we had the IPsec meeting. Now at this meeting we had one mild disagreement, one calmly worded surprise, and a couple of relatively new observations. Since we have nineteen documents actually, I count 21, but what's two drafts among 175 debating Internet folk?), this is considered a mild meeting. There are drafts for architecture, packet formats, almost a dozen encryption ciphers (don't blame me, my name's only on four of the documents), and miscellaneous other proposals.
The good news is, people are definitely realizing that [Attention news flash here] people are currently using the Internet without encryption. Since this is happening, there is agreement -- "rough consensus" as the mantra says -- that we need to get this stuff done as soon as possible.
There are still problems. The main document that isn't done is the architecture spec. This means we wrote 20 or so documents based on an old architecture spec and some notes written on the back of an envelope. Some have characterized this as "firing a gun and then running ahead of the bullet to paint a target where it's going to hit." This may be true, but in all fairness this is the third generation of the architecture document, so at least for those hardy folk who have been around for a while the architecture is known.
The scary thing is, there was consensus on another point: with all those documents, we realized that sometime soon we are bound to hear that someone has written "IP Security For Dummies."
Copyright © 1995-2000 by Keith Dawson. Commercial use prohibited. May be excerpted, mailed, posted, or linked for non-commercial purposes.
Most recently updated 8/19/97