Mythology about security…

Ed Felton tweeted a few days ago: “Often hear that the reason today’s Internet is not more secure is that the early designers failed to imagine that security could ever matter. That is a myth.”

This is indeed a myth.  Much of the current morass can be laid at the feet of the United States government, due to its export regulations around cryptography.

I will testify against the myth.  Bob Scheifler and I started the X Window System in 1984 at MIT, which is a network transparent window system: that is, applications can reside on computers anywhere in the network and use the X display server. As keyboard events may be transmitted over the network, it was clear to us from the get-go that it was a security issue. It is in use to this day on Linux systems all over the world (remote X11 access is no longer allowed: the ssh protocol is used to tunnel the X protocol securely for remote use). By sometime in 1985 or 1986 we were distributing X under the MIT License, which was developed originally for use of the MIT X Window System distribution (I’d have to go dig into my records to get the exact date).

I shared an office with Steve Miller at MIT Project Athena, who was (the first?) programmer working on Kerberos authentication service, which is used by Microsoft’s Active Directory service. Needless to say, we at MIT were concerned about security from the advent of TCP/IP.

We asked MIT whether we could incorporate Kerberos (and other encryption) into the X Window System. According to the advice at the time (and MIT’s lawyers were expert in export control, and later involved in PGP), if we had even incorporated strong crypto for authentication into our sources, this would have put the distribution under export control, and that that would have defeated X’s easy distribution. The best we could do was to leave enough hooks into the wire protocol that kerberos support could be added as a source level “patch” (even calls to functions to use strong authentication/encryption by providing an external library would have made it covered under export control). Such a patch for X existed, but could never be redistributed: by the time that export controls were relaxed, the patch had become mostly moot, as ssh had become available, which, along with the advent of the World Wide Web, was “good enough”, though far from an ideal solution.

Long before the term Open Source software was invented, open source and free software was essential to the Internet for essential services. The choice for all of us  working on that software was stark: we could either distribute the product of our work, or enter a legal morass, and getting it wrong could end up in court, as Phil Zimmerman did somewhat later with PGP.

Anyone claiming security was a “failure of imagination” does not know the people or the history and should not be taken seriously. Security mattered not just to us, but everyone working on the Internet. There are three software legacies from Project Athena: Kerberos, the X Window System, and instant messaging. We certainly paid much more than lip service to Internet security!

Government export controls crippled Internet security and the design of Internet protocols from the very beginning: we continue to pay the price to this day.  Getting security right is really, really hard, and current efforts towards “back doors”, or other access is misguided. We haven’t even recovered from the previous rounds of government regulations, which has caused excessive complexity in an already difficult problem and many serious security problems. Let us not repeat this mistake…

 

 

4 Responses to “Mythology about security…”

  1. Peter McNeeley Says:

    What about how FTP was not password protected in original RFC but is in a later version.

    https://tools.ietf.org/html/rfc114

    https://tools.ietf.org/html/rfc959

    • gettys Says:

      RFC 114 (dating from 1971) predates the Internet as we know it (ARPA net days). Access control was at the IMP level then (you had to have an authorized account to use the ARPA net at that point). It was very much a “prototype”. The TCP/IP conversion occurred in 1982(?).

      By the mid 1980’s, and the advent of BSD UNIX making connection to the Internet much, much easier, it was clearly growing up, and this is the era of Kerberos’ (and X’s) initial development.

      So people did what they could: e.g. passwords were added to FTP. (note that RFC’s often occur much later than implementation).

      Don’t confuse the absence of something better for lack of vision by people: export controls meant that you would be unable to freely distribute your software, and inhibited lots of software, not just X’s design and implementation.

      • Peter McNeeley Says:

        “Don’t confuse the absence of something better for lack of vision by people” totally agree. I think many people are actually quite intelligent. I respect the giants of the shoulders we now stand upon.

        However:
        Given the current state of the internet.
        (Context being extremely problematic security and privacy issues)

        Do you think the choice of putting software Distribution over say security/privacy was the correct one?

        If you could go back in time would you still make the same decision?

        How much of this decision really rests on a political ideology forwarded by the likes of people like John Perry Barlow?

        • gettys Says:

          What was our alternative? Stop our work entirely? Something even worse may have appeared (which arguably was Windows, though it has improved greatly over the last 10-20 years?). Note that commercial companies were also strongly discouraged from using any crypto for a long time: the license process for them was a PITA, enforcing very poor security (by the key length limitations).

          There is also the law of unintended consequences as well. HTTP cookies, which have been a privacy nightmare, were implemented very quickly by Netscape to enable E-commerce, being much easier to use than the cumbersome methods used by OpenMarket before cookies were available. As HTTP editor, we had concerns about standardization of them, but it was a “done deal” by the time the IETF started work on the spec as it was in widespread use. The best we could do was to standardize their use with a decent spec, rather than try to design anything better.
          I also guarantee we did not foresee the depth of the nightmare they became. in the face of advertisers and others. One’s crystal ball becomes very cloudy.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s


%d bloggers like this: