Ein Münchener spass

Or - what I think happened at the Munich IETF

Other reports from the same meeting:

No, I'm not bothering with a lot of fun and games this report. Even though the week wasn't as exhausting as some, I'm still tired, sleepy and on my way home.

A completely unexpected part of the pleasure of Munich was the weather - consistently warm and sunny all through the week, at 25+ degrees outside and even more inside. Some of the meeting rooms seemed to have excellent facilities for heating, but little for cooling - the heat in some, when they were packed beyond capacity by hotly arguing IETFers with hot-running laptops, equipped with the everpresent radio LAN modems, could easily reach into the thirties - Centigrade!

For this was also the biggest non-US IETF ever - at 1300-odd members, it fell just a handful short of Memphis, and exceeded expectations by at least 500 people.
(What does this portend for the future?)

But back to working groups, events and areas. As usual, I'll not be saying much about non-Apps groups - with an Apps track that had 2 parallel sessions in almost all slots on the agenda, the poor ADs had very little time and even less energy to spare to look in on how other IETF groups were doing. So all non-Applications groups' news must be treated as "overheard in passing".

Application security: What does that mean?

For years, the IETF community, and especially the IAB, has argued strenously that the security of the Internet needs improvement. One particular item has now come to the fore as a rallying cry: "Death to clear text passwords!"

However, this is not as easy as it seems. It is chillingly easy to design schemes for password hiding, or non-password authentication, that turn into "equivalent to cleartext passwords" once a skilled cryptographer gets his hands on them. Or it may be a scheme that needs new login databases, or requires the password to be known at the server site (something Unix, through a sheer stroke of brilliance, avoided many years ago), or runs smack into the dreaded US export laws and French encryption bans.

At the same time, the security "gurus" of the IETF have made noises for a long time that sound like "this problem is solved - you only need to ......" (sound of increasing incomprehensibility)

At the AAARG BOF meeting (the acronym stands for Application Authentication/Authorization Review Group, and also for how the group chair feels when thinking of the problem), the disconnect between security people and application protocol developers became extremely apparent; the security people said "this problem is well known and solutions are available", the apps people said "no specification other than TLS exists that is actually usable - and TLS has undesirable properties". (TLS = the protocol formerly known as SSL, an encryption protocol used by Netscape and Explorer, using the patented RSA cryptosystem and X.509 certificate hierarchies for authentication)

It is clear that more work is needed; it is not clear exactly what. (Later in the week, ACAP, the working group that is next to ask the IESG for approval, decided to mandate a login mechanism called CRAM-MD5, which has been known for some time, but also has known problems)

Directories: Is there hope?

The Directory area was undergoing a new reorganization at this meeting, the ASID group having finished its revamping of the LDAP version 3 protocols, and the other directory groups also nearing the end of their work items.

There is, however, more work to be done; we are far from the situation where we can create a global directory service; for reasons both technical and political.

What is eminently clear is that people will deploy large-scale, internal directories using standard protocols, especially LDAP version 3, which seems to have the promise of being a good protocol.

However, this is not enough. In order to enable the interconnection of these services, there has to be some agreement between them on items that both LDAP and its "ideological parent", X.500, has left to the implementors' choice: Naming schemes, schemas and searching strategies.

In the systems we have designed today, it is extremely unnatural for there to be two objects with the same name; this means that if two directories choose the same name for an object, they cannot be interconnected.

Yet we have chosen not to give advice for, and the world has chosen not to implement, any scheme in which this uniqueness can be guaranteed at reasonable cost; 9 years after the first X.500 standard was published, the question of "who manages the namespace" is still largely unanswered and unanswerable.

This is not news. The DIRDEP (Directory Deployment) BOF was quite clear both in its indication that they knew that there was a problem here, and in that we do not know any easy solution.

But this cannot be allowed to continue. If there are no easy ones, perhaps it is time to start trying some hard ones.

Character sets: An idea whose time is right

It seemed entirely appropriate that a first explicit policy for the IETF on character sets (written and presented by yours truly) should be presented in München, a city whose name for itself is not expressible in the US-ASCII alphabet.

The policy is very simple, recommending that all character data be identified, that ISO 10646 encoded in UTF-8 be the "standard character set" that all protocols should be able to transport, and that protocols provide a way to carry language identification on data.

In the BOF, "rough consensus" was achieved (meaning that there were a few vocal objectors, but also many supporters); when it was presented in the plenary meeting, no objections were heard at all.

This is good; it seems to show that we have achieved some kind of reasonable compromise that allows us to move forward.

AND - the days of unlabelled, "anything goes" text transfer as an option in Internet protocols are gone. About time.

About cryptography, patents, export and other strange beasts

On September 7, the world changes.

This is the day on which the basic patents for public-key cryptography expire in the US, allowing, as far as anyone can tell, anyone to practice the Diffie-Hellman approach to public-key cryptography, and the DSS signature algorithm, without having to pay anyone anything.

So far, most work, in the IETF and elsewhere, most work has been using the more well known (and somewhat faster, but no more secure, I think) cryptoalgorithm called RSA, which is patended, the patent is owned by RSA Data Incorporated, and those patents do not expire until 2003 or thereabouts.

RSA is known throughout the industry for its rather excessive approach to licensing fees, but many key players, including both Microsoft and Netscape, have already paid their dues, and see little reason to shift to another cryptoalgorithm.

However, the IETF has a tradition of preferring "unencumbered material", or at least material with "reasonable and non-discriminatory terms". This is vital for, among other things, the ability of smaller firms to practice Internet standards.

The question was raised in the open IESG meeting (where most of the 1300 participants were present), and the meeting showed near-unanimous consensus: The IETF prefers unencumbered technology.

In this particular case, it prefers that standards mandate Diffie-Hellman based algorithms as mandatory-to-implement protocol options rather than RSA algorithms.

This has immediate effects upon the TLS working group (which tried to specify no minimum algorithm, and was sent back to the WG by the IESG), the PKIX working group (which had seemed to specify certification hierarchies without specifying a signature algorithm), DNSSEC, where only RSA is specified, and other security groups; the long term effects may be far more interesting.

The reaction to this of the vendor community that is already shipping tons of product with RSA-based functions only in them will certainly be interesting. This may not be funny.

Classes of citizenship, and cops on the Infobahn

So far, the Internet has operated on a remarkably simplistic model: Give us your packets, and we'll try to deliver them.

Some modifications are done: TCP's famous backoff strategies ensure that when things start to break down, the users reduce pressure; when some users try to use more than others, Weighted Fair Queueing or RED makes sure that the result is not too unreasonable.

But still, the term "best-effort packet delivery" is still quite relevant.

This may change soon. The most well-publicized effort is RSVP, with its ability to tell the network "please give the following packets preferred service". There are doubts about how well this scales to millions of simultaneous reservations through core routers; initial deployment is probably going to be limited to intranets.

Perhaps the most well-attended of all sessions in Munich was the one called "differential service", where a series of suggestions for a simpler scheme ("tag the packet with bits in the headers") were bandied about; apparently it is possible to get a bit more mileage out of these than was done with the defined-but-mostly-unused Type Of Service bits of the IP header so far.

More radical is Van Jacobson's suggestion, given in a talk at the plenary: Modify the routers to not only reduce the traffic of those who "send too much" to normal levels, but "exile" them - make their bandwidth go away.
He claimed that mechanisms exist that seem to work in the lab, but used his talk as a plea for help to get traffic data that he could use for figuring out whether they would work in real life.

This may actually change what new services we can introduce on the Internet radically; if there is no danger of taking out the infrastructure by deploying new services, the barrier for trying things, which seems low enough already, may disappear altogether; on the other hand, people might find that "anything new doesn't work" (because it doesn't fit the rules the network uses for policing), and act accordingly; this may shape the future.

But apparently, it still has some years to go before production, even by VJ's estimate. Research in progress!

Other tidbits, rumours and misclellaneous

Of course this isn't all that happened, it isn't even most of it. Some other things that may be worthy of mention:
Harald.T.Alvestrand@uninett.no
Last modified: Tue Sep 2 09:31:41 1997