Paul Leyland <firstname.lastname@example.org> - Piete Brooks <email@example.com>
15 May 1996
UKERNA commissioned a study and report describing the options for improving the security of electronic mail for academic community users in the JANET community. The study was funded by the Joint Information Systems Committee (JISC). Paul Leyland and Piete Brooks submitted a proposal in response to this request. The salient features of their proposal are:
The proposal was accepted and a one-year contract started on 15 May 1995. Three interim reports and one final report were to be issued quarterly; this is the final report.
We start by explaining several fundamental concepts[+], then discuss in turn MUA integration, key service and international collaboration. We conclude with a description of what we consider will need to be done in the next few months.
The word ``secure'' has three important connotations in the context of this study. Email is secure, for our purpose, if it is adequately private, adequately authenticated and has an adequate assurance of integrity. We use the word ``adequate'' deliberately: any security mechanism can be circumvented if sufficient effort is applied. We are assuming that protection against the determined efforts of a major government intelligence agency is not possible with the resources that the majority of the members of the UK academic community has available and at the level of inconvenience which it is prepared to tolerate. We do require, however, that it be possible for the community to be reasonably satisfied that privacy, authenticity and integrity are protected against other members of the community (including systems staff), against plausible threats from service providers, against commercial organizations (such as customer database providers) and against most illicit monitors of network traffic (compare the ``internet sniffer'' attacks against host/account/password triples).
In this context, ``privacy'' means that information is intelligible only to its rightful recipients. Although third parties may be able to read (a copy of) the message sent, they must not be able to make sense of it.
``Authenticated'' means that the recipient may reasonably be certain that a message was truly created by its purported author, and has not been forged by some other party. Implicit in this definition is the assumption that the true author has taken care to prevent misuse of its identity by unauthorized entities and that if forgery has taken place, it is without the collusion of the author. The related concept of ``non-repudiation'' implies that it is infeasible for the purported author to collude in this manner.
A message has its ``integrity'' protected if it is infeasible for its contents to be changed in transit without any such changes being instantly obvious to the recipient.
Note that any particular message need not have all three of these characteristics. In particular, a public announcement by someone in authority should probably not be private, but it very probably ought to be extremely difficult for anyone to change it indetectably; neither should anyone else be able to create a counterfeit announcement supposedly from an authoritative source. Conversely, a whistle-blower may not want to give incontrovertible proof of authorship, but would want sensitive information to remain private. Another situation may apply if the message is a program: an assurance that the code has not been modified (to install a Trojan Horse, for example) is valuable but the privacy or authorship of public-domain software may be unimportant.
An additional desirable characteristic of a robust email system is assured delivery or guaranteed notification of non-delivery. We are not concerned with this aspect in our study.
A fundamental assumption we make is that any data traffic on JANET cannot be made unreadable. In order to assure privacy, therefore, we must ensure that the data is unintelligible. This is the role of encryption. The encryption mechanism must be such that the intended recipient can make the data intelligible, but that it is infeasible for anyone else. PGP is easily adequate for this task, is freely and widely available and is rapidly becoming the de facto international standard.
Making data unintelligible requires an encryption algorithm and a relatively small item of data known as the encryption ``key''. The algorithm is fixed and used by both parties when exchanging information. Within PGP there are two encryption algorithms, called RSA and IDEA, used in different circumstances to be explained shortly. To restore the data to intelligibility requires the same algorithm and a decryption key. It is always assumed that the details of the algorithm are public knowledge, and that the only thing preventing bystanders from decrypting an encrypted message is that the decryption key is known only to the rightful recipient.
If the encryption and decryption keys are the same (or one is trivially derivable from the other) the method is called ``symmetrical encryption'' or ``conventional encryption''. Note that if conventional encryption is employed, both parties must keep their keys confidential. IDEA is a conventional encryption method. The encryption and decryption keys are essentially identical and each datum is 128 bits in size, meaning that there are approximately 3.4 times 10 to the power of 38
different keys available. It is completely infeasible to search this number of keys in an attempt to find the one used to protect a particular message. No-one has yet published an attack on IDEA which runs faster than exhaustive search of the key space --- though that is not a guarantee that a better method doesn't exist.
An alternative is found in ``asymmetrical encryption'', also known as ``public key encryption''. Here, the two keys are related to each other but in a non-trivial manner. It is assumed that it is extremely difficult to derive one key, given possesion of the other. RSA is an example of an asymmetrical encryption method. The non-trivial relationship between the keys in RSA is essentially that of determining the prime factors of a large integer. Anyone with prior knowledge of the primes (the creator of the keys, for instance, or an eavesdropper observing their creation) may easily generate one key from the other; anyone else must solve a computationally difficult problem. The size of the integers used in the RSA algorithm is potentially unbounded; in practice integers of 512 to 2048 bits are used. The larger the integer, the slower the algorithm runs. Current state of the art suggests that 512-bit integers are vulnerable to a rich and dedicated attacker, such as a large government security agency, but that 1024-bit keys will remain safe for a decade or two, despite plausible improvements in computer hardware and factorization algorithms.
Public key encryption has some rather useful properties. Since the decryption key cannot practically be derived from the encryption key, the latter may as well be public knowledge, hence the more common term: ``public key''. If this is done, then anyone can encrypt data with that key. The corresponding decryption key is kept private, hence the term ``private key''; only the possessor(s) of that key can decrypt the encrypted data. Thus: if each person has a public key published in a directory, anyone may send that person a private message. No-one else, not even the author, can decrypt that message because they do not have and cannot derive the corresponding private key. There is no necessity to exchange keys ahead of time as there would be if conventional encryption were used.
The two keys, public and private, are reciprocal in the RSA algorithm. If either is used to encrypt, the other can be used to decrypt. Consider the situation where one party encrypts a message with the private key. We assume that that individual is the only one capable of doing this, because only they have possession of the private key. Anyone with the public key may decrypt the message. If the message is also published, anyone may be satisfied that the first party performed the encryption and no-one else. This characteristic is analogous to a signature on a document, and has become known as a ``digital signature''. Digital signatures may be used to implement the desirable property of authenticity.
Privacy and authenticity may both be achieved by using the same key pair for each. It may be convenient, however, to reserve one key pair for privacy and to use another for authenticity. The reason for this apparently odd behaviour becomes apparent when we consider either key escrow or enforced decryption of private material. Suppose that an organization wishes to be able to gain access to material encrypted by an employee, or that a court orders some information to be made legible. The organization may require that a copy of the decryption key be provided to them when it is made, or the court may force it to be revealed. If the same key pair is used in both roles, revealing the private key so that material may be decrypted also permits the organization or court-authorized investigator to forge the signature of the individual. This could be regarded as undesirable. Versions of PGP prior to 3.0 draw no distinction between privacy keys and authenticity keys. It has been stated by the developers that version 3.0 will support both types and the distinction will be explicit.
Since public key encryption has such attractive properties, it might be wondered why conventional encryption is used at all. The reason is efficiency. The best asymmetric methods are much slower than strong symmetric methods. PGP uses both, as has been mentioned. When it is used for privacy, the program picks a random number of 128 bits, called a ``session key'' and uses that as the key for IDEA to encrypt the bulk of the message. It then encrypts the relatively small session key with (each of) the public key(s) of the intended recipient(s) and adds it to the encrypted data. The recipient(s), on receipt of the message, can then use their private key to decrypt the session key and use that to decrypt the main information.
RSA would be too slow to be used to sign an entire message. Remember that signing is merely encrypting with the private key. Instead, PGP generates a ``cryptographic hash'' of the message with a function called MD5 and that hash is then signed. MD5 (Message Digest version 5) is a function which takes an arbitrary amount of data and generates a 128-bit number. It is believed to be extremely difficult to find two different messages with the same hash, and even more difficult to generate a message with a specified hash value --- that of a particular message, for instance. Note that we can now provide integrity. If it is difficult to generate another message with the same MD5 hash as a prototype message, then it is difficult to replace that prototypical message with a forgery and not be detected.
A complete secure email system needs to protect rather more than its messages and its session keys. The integrity and authenticity of the public keys must be protected, as must the privacy of the private keys. PGP maintains collections of public and private keys in files called ``keyrings''. In normal usage, there are two keyring files, called pubring.pgp and secring.pgp[+], though more may be used if required.
The secring file contains the private keys belonging to a particular person. It is normally protected by IDEA encryption, with a passphrase to prevent its contents being used by anyone but the owner. Note that a person may have several private keys in use --- each may correspond to that person acting in a different role, for instance --- and that copies of a private key may exist on several keyrings --- e.g., that for a group of people sharing a role such as Postmaster.
Public keys, by their very nature, do not need their privacy protecting, and so are not normally encrypted. However, maintaining and examining their integrity and authenticity is of great importance. A public key consists of some binary data (the details of which are unimportant here), a ``keyID'' and a collection of ``userID'' records. The keyID is an eight-digit hexadecimal number which identifies a particular public key.[+]
A userID usually contains the name and email address of the owner of the key; there may be more than one userID on any one public key. The PGP program itself does not normally allow anyone but the owner of the corresponding private key to change the userIDs in a public key, but it is possible for them to be changed. A malicious eavesdropper (traditionally called ``Eve'') could, therefore, add their own email address to someone else's (``Bob's'') key and attempt divert email away from the rightful recipient.
When ``Alice'' wants to send private email to Bob, she may unwittingly send it to the phoney address, that is to Eve. Eve is unable to decrypt and read the email intended for Bob, as Eve does not have Bob's private key, but neither will Bob be able to read it, as he never received the mail. This is a denial of service attack. (Incidentally, it also demonstrates why one should resist the urge to use a PGP public keyring as an address book.)
Much worse is that Eve could create a new key pair (private and public) and attach a userID of some other person or role, Bob's for example. Unwittingly, Alice would then be transmitting mail securely to Eve, if we assume that Eve can intercept the email before it actually reaches Bob. Such interception could be quite simple if Eve were the Postmaster for Alice's site. Eve can now read the mail and send on a copy to Bob, suitably encrypted in Bob's real public key. If Eve were dastardly enough to pull the same trick on Alice, she could even use her fake Alice-key to pretend that Alice had signed the forwarded mail. The standard term for Eve's actions (i.e., those of an active participant as distinct from a passive eavesdropper) is a ``man-in-the-middle attack''.
To guard against some of these attacks, userIDs can and should be signed (in the digital signature sense) by one or more private keys. A signature on a userID indicates that the owner of the private key making the signature believes that the userID on the public key truly belongs to that key's apparent owner. In particular, self-signing a userID (using the private key corresponding to the public key on which the userID appears) guards against malicious addition of extra userIDs. More important in practice, however, is that userIDs be signed by trustworthy owners of private keys elsewhere. If Alice signs a userID on Bob's public key, it is a public statement that Alice believes that that public key and userID truly belongs to Bob. If Charles now obtains a copy of Bob's key, he may be satisfied that the key truly belongs to Bob (that is, the person named in the userID) if he (Charles) believes Alice to be trustworthy. In the jargon, Alice is acting as an ``introducer'' or a ``certifier''. It is possible to set up chains of trust (Dora trusts Charles' assertion that Alice is trustworthy ...) and PGP supports this notion in a simple manner. A simple chain of trust is traditionally known as a ``certification heirarchy''. In the JANET environment, for example, each institution could sign the keys of its members, with the institutional key itself being signed by a UKERNA-held key. PGP actually provides rather more than a single chain of trust --- userIDs may be signed by several keys, and each signer may be assigned a degree of trustworthiness by the user of the public key. In this manner, a complicated ``web of trust'' may be built up.
A particularly disastrous loss of integrity of a public/private key pair occurs when the private key and its protective passphrase is acquired by someone not entitled to use it. The key has become compromised, and any material encrypted with the public key can be read by the new owner; likewise that owner can forge the signature of the legitimate owner of the key. PGP uses ``revocation certificates'' to minimise the damage when a key has been compromised. The true owner generates a special form of PGP message which contains the revocation certificate and then distributes it widely, so that the key is flagged as compromised. When a certificate is added to a public key, that key may no longer be used to encrypt material, though it can still be used to check signatures (a warning is given if this is done). The private key is needed to generate a revocation certificate, to prevent malicious attacks.
PGP can be a rather unfriendly program, especially to those uncomfortable with using a command line in the MS-DOS or Unix tradition. Even to those users who are happy with a command line interface, it is undoubtedly inconvenient to have to compose mail into a file, run PGP on the result and finally include the encrypted information into a message using the MUA's import facility in order to send secure email. Reading incoming mail is just as arduous if it has first to be saved to a file and then decrypted outside the MUA. If only this method is supported, secure email will tend only to be used for ``special'' messages.
The ideal would be for PGP to be virtually invisible to the email user. The MUA would itself decrypt incoming email and check signatures, displaying the result for the user. It would fetch the public key required for signature checking, either from the user's public keyring or from some on-line key service. Outgoing mail would be automatically signed, if required, and encrypted in the public keys of the recipients. Again, any needed public keys would be fetched rapidly and invisibly if they were not available on the user's keyring.
This ideal is unlikely to be achievable, even in principle. For a start, signing and decrypting require access to the user's private key. This is normally kept encrypted to protect it from compromise, so the user is asked for a passphrase --- violating the invisibility requirement. The passphrase could be requested at the beginning of a session and be kept in memory or in a file. This may be acceptable to some users on some systems. However, this solution carries the risk that the passphrase becomes visible to third parties if they can examine memory and/or disk storage. That risk may be unacceptable. Additional problems arise when a necessary public key cannot be obtained. For signature checking this might not be important: the user can be informed that the signature could not be checked because the key was unavailable. When a recipient's key cannot be found, however, we may be in a quandary. All the obvious solutions are flawed: rejecting the mail and bouncing it to the sender is not very friendly; sending it out unencrypted removes all security and even the half-way solution of encrypting and mailing to those keys which can be found and rejecting it for the others begs the question of how email may be sent to those without keys.
The ideal is impossible to achieve for another, practical, reason. There are a large number of MUAs in use in the JANET community, and not all of them are amenable to modification, either because of their structure or because their source code is not available. Further, although a MUA might be modifiable in principle, it may be used by so few people that the required effort could not be justified.
If the ideal cannot be achieved, a compromise must be sought. We must accept that the user will be required to do more to send and receive secure email than insecure email. We must find ways of coping with missing keys and we must permit users to store private key passphrases if they wish to take the risk but we should minimise that risk and inform the users that they are taking a risk. Those MUAs which are difficult to modify will have to be inelegant; those which are impossible to modify must either be circumvented (perhaps by intercepting the incoming and outgoing email streams before or after the MUA gets a chance) or the user will have to use PGP on external files.
At the start of the study, we recognized that we knew relatively little about the levels of usage of various mail user agents in the JANET community. We could guess that some would be popular (Eudora and Pine, for example) and that others would be less so (for instance, binmail on Unix machines). So that we could make an informed decision on where effort should be applied, a survey was undertaken. Sue Weston compiled a brief questionaire and sent it to the mail-managers and uk-security mailing lists. Each contact was asked to summarize which MUAs were in use at that site for each of the four major platforms (IBM-PC, Macintosh, Unix and VMS) and to give an estimate of how many people used each MUA. Fifty-seven organizations responded, representing about a quarter of a million users. The results of the survey are given in Appendix A.
From the Appendix, it can be seen that 95% of MUA usage is taken up by 17 different packages. Almost a third of the usage comes from Pegasus, running on MS-DOS and/or MS-Windows machines. Three more account for another forty percent: Pine and Elm on Unix systems and Digital's Open-VMS MAIL. We were surprised at the relatively low usage claimed for Eudora, which came in ninth with only 2.4% of the population. It was decided that attempting to give at least 95% of the community at least a basic level of integration would be a worthy and achievable goal.
As part of the survey, it was asked whether anyone at that site would be interested in assisting the PGP integration project. Approximately 20 people expressed an interest in the project, and a meeting was organized at University College London on 13 July 1995. At the meeting, the aims and role of UKERNA was described, followed by a description of resources presently available and the nature of the problems to be identified and solved. Each participant then described their personal and their institution's usage of secure email and PGP. After an explanation of the results of the MUA survey, participants volunteered to examine one or more MUAs in some depth and to report back their findings. The detailed minutes of this meeting are presented in Appendix B.
A follow-up meeting at Imperial College on 18 December 1995, had an attendance of twelve. There were concerns about the procedures for mass generation of keys, and Key Escrow. There was a brief description of pgp.net and the TERENA CD. Various key lookup protocols were discussed. Each site then gave a progress report on their MUA integration. The minutes of this meeting are presented in Appendix C.
At the 1996 NetWorkshop, Paul Leyland presented a paper describing the progress of the secure email study. Later that same day, 27th March 1996, an open meeting was held for any delegates wishing to contribute to the study. Those attending the two earlier meetings were also invited, whether or not they were also attending NetWorkshop. The meeting was split into two halves, the first of which dealt with issues of MUA integration and the second with key service and authentication. Because relatively few people present had attended earlier meetings, most of the MUA business covered previous ground. A conclusion was that Netscape should be added to the list of MUAs to be considered. At the key service session, a brief description of the present position was given, together with a few details of research presently underway into second-generation key servers. The meeting then considered the problems of key authentication and management for a site with a turnover of a few thousand individuals per annum. The minutes of this meeting are presented in Appendix D.
At the time of writing (May 1996), tools exist to give an excellent level of integration of PGP with a few mailers. The most commonly used of these is Elm, at 12.7% of usage. The elm-2.4pl24me8.tar.gz package available at ftp.pgp.net provides menus for encryption and signing of the message being composed; it automatically detects encrypted incoming email and offers to decrypt it; it checks signatures automatically. In an especially nice touch, the PGP-aware Elm checks to see whether the user has set up PGP's keyrings and configuration file and, if not, the mailer does not display its PGP-related functions to avoid confusing the user.
An alternative approach has been taken with privtool-0.85.tar.gz which re-implements Sun's mailtool agent from scratch. Reports suggest that PGP is well integrated, but that there are niggling differences between privtool and mailtool which some users find objectionable. Sun's mailtool is eleventh on the usage list, with 1.4% of the population.
Two minority interest mailers, exmh and Emacs' RMAIL, also have extremely well integrated PGP functions but neither of these appear in the top 95% usage. The authors of this report use these two MUAs.
A tolerably good level of integration is available for a few more mailers, including Pegasus on MS-Windows, Pine on Unix and Eudora on Macintosh and MS-Windows. The authors are familiar only with Pine out of these three and have to rely on third parties for opinions of the quality of the integration for the others. The Pine mailer is typical of many in that almost the only hook available for attaching PGP to it is its ability to use an external editor. The integration package ( mkpgp1.6.tar.gz) overloads this hook more than somewhat. The result is clunky and inelegant but usable. The editor approach has been used to attach PGP to a number of other mailers, including Open-VMS MAIL. Pine is relatively unusual, however, in that the source code is freely available and a well-integrated secure mailer could be produced if the effort was properly commissioned.
The inverse approach is taken by Private Idaho, a PGP front-end for MS-Windows 3. x systems. Rather than hook PGP into a mailer, it hooks mailers into PGP. Private Idaho provides a graphical interface to PGP and also knows about the email format used by a variety of Windows mailers. The user interacts with Private Idaho, which then communicates with the underlying mailer. Although this is an elegant solution to the problems of integrating many and varied MUAs, it does mean that the user has to learn yet another interface. Private Idaho's principle strength is that it makes the use of anonymous remailers very simple (a characteristic shared with the Emacs package mentioned above) but this is not particularly useful for most users of email.
On Microsoft Windows platforms, it would be possible to integrate PGP into mailers relatively easily if a DLL (Dynamic Link Library) of cryptographic functions were available. At the time of writing, a PGP DLL is in beta test but has not yet been released. Note, however, a DLL is of use only to those mailer authors who choose to use it. It is likely that some commercial mailers will not use this technique.
Unix machines running sendmail as the message transfer agent have an entirely different option available. The PGPsendmail package, written by Richard Gooch, is a wrapper for the true sendmail. When the wrapper is running, it intercepts all email to sendmail and ensures that it is encrypted before passing it on to sendmail for transfer. PGPsendmail first detects whether the user is using PGP by checking for the presence of an environment variable. If it is found, a per-user configuration file is read. The file specifies actions such as what to do if a required key is missing. If PGP is not in use, mail is passed on unchanged. The package also includes PGPdaemon (run by each user) which can automatically sign or decrypt PGP messages. This daemon, of course, must be given the user's passphrase so that it can access the private key required. On a multi-access computer this may be unacceptable. One of us (Leyland) has had over a year's experience with PGPsendmail and PGPdaemon. By and large, it is effective and almost invisible --- so much so that there is a temptation to encrypt mail before sending it and not realise that PGPsendmail will encrypt it a second time before transmission. PGPdaemon is more problematical. When it works, it is again effective and almost invisible. Unfortunately, the stored passphrase is lost when the machine reboots and it has to be re-entered by hand.
In order to use PGP to communicate securely with another person (or program) the sender must have the recipient's public key available. There are two criteria here: a key must be available and that key must belong to the recipient. It has already been explained how signatures on a key's userID(s) can be used to reassure the sender that the key is authentic --- that it truly belongs to its apparent owner.
Ultimately, only the user of a public key can decide whether to trust its authenticity. Whether that trust is possible in a particular circumstance depends on the history of the key, the use to which it is about to be put and the skepticism or gullibility of the user. We will concentrate on only the first of these, though we note in passing that the user should probably take greater care to verify the authenticity of a key which is about to be used to encrypt a confidential report than the one used to check a signature on a Usenet posting to talk.bizarre.
As with the early Internet, currently the majority of PGP users are hackers (in the old sense!), many of them downloading and building their own PGP binaries. Most understand the workings of PGP, generate their own keys and have them signed by other users of PGP. An anarchic but apparently effective web of trust is built up.
Some groups of PGP users have a slightly more organized approach. For example, many representatives of security incident response teams use PGP for their private communications. At meetings between representatives (the FIRST workshops held each year are particularly good examples) a ``key-signing party'' is held. Each holder of a key proclaims the authenticity of that key and the other representatives decide whether to trust the assertion. If they are satisfied that the key's ownership has been verified, they will sign that key (usually after returning from the meeting) with their own private key. The keys of most teams and their members are now cross-verified in a tightly-knitted web of trust.
These approaches to key certification may be adequate for the enthusiastic users of PGP and may be tolerable for those who deal with especially sensitive information. They are not appropriate for the great majority of JANET users.
To make PGP easy to use by the majority of JANET users, at least four things are required. First, the users' keys must be easy to generate in the first place. Second, it must be easy for a key to acquire at least one trustworthy signature. Third, there must be a simple but adequately secure way to recover access to the private key should the protective passphrase be forgotten. Fourth, it must be easy to revoke the key, should it be compromised.
An institution should consider offering a key generation service for its members. This service must be optional or the members of the institution will claim, quite rightly, that their privacy may compromised by anyone with access to the key generation process. Those members, however, who are not concerned with intra-institutional threats but require privacy only for communications with other institutions may feel the simplicity of not having to generate a key outweighs the disadvantages. We feel strongly that if an institution should offer a key generation service, it should also make the disadvantages clear to its members.
Confidence in the authenticity of a public key is enhanced by the key being signed by a trustworthy certifier. Additional reassurance comes from having signatures from several keys, so that if one should be compromised, the remaining signatures still vouch for the authenticity of the key.
It is recommended that each institution create two or more PGP key pairs to be used only for the purpose of signing the public keys belonging to members of the institution, thereby vouching for those keys' identity. We deliberately leave unspecified the term ``institution''; we expand on the meaning of ``member'' below. Depending on circumstances, an institution might be an Oxbridge college, a university department, an entire university, or UKERNA as a whole. The vital requirement is that signatures made by a certification key on other keys be beyond reproach.
In practice, this means that the following criteria must be met:
It is recommended, though not obligatory, that the only keys to be signed with a certification key be those belonging to members of the institution; those used by services provided by the institution; and the certification keys of sub-institutions. So, for instance, the Department of Experimental Theology at Neasden University would certify keys belonging to their staff and also the key used by Postmaster@expth.neasden.ac.uk; the departmental certification keys would themselves be signed by the university's certification keys. The university would be willing to sign the key of any member of the university as well as its departmental certification keys; its keys would themselves be signed by the master UKERNA keys, which would themselves be signed by other similar organizations. Some departments may be so small that they would not have certification keys; their members would rely on the university's certificates.
If a trustworthy certification heirarchy can be set up in this manner, we would expect PGP users to trust their department, university and UKERNA to act as introducers and, thereafter, keys signed by any of these would be accepted as genuine without the user being questioned by PGP. To verify the authenticity of a key supposedly belonging to a member of a different institution, the user would need at least one of the public keys of its certifiers, at least one of the certifiers of that key, and so on until a key is reached which has been signed by an authority present in the chain of certifiers of the user's own key. In an ideal world, these intermediate keys would be fetched automatically and invisibly by the MUA as required.
As signatures cannot be revoked (at least under PGP 2. x), it would be useful to include an expiry date in the certifying key's userID. Some time before expiry of the key, all users have to ask to have their keys re-signed with new keys before the old ones are revoked. Version 3.0 of PGP is expected to implement signature revocations, and it may be that this will be sufficient.
It is an unfortunate fact of life that people invariably forget passwords. Help-desks have had to develop procedures to enable forgetful users to regain access to their accounts. For an interactive account on a multi-user machine, it is easy for a system administrator to bypass the user's security and to set the password to a known value. If the passphrase protecting a PGP private key is forgotten, its owner is in a much more serious predicament. Any mail encrypted to that key will be unintelligible. The user will not be able to sign outgoing mail, which may perhaps be regarded as a relatively minor inconvenience. Further, the user will not be able to create a key revocation certificate, to be issued as a signal to the remainder of the community that the public key is effectively useless, because the private key is needed to perform this action.
It is suggested that a key-escrow facility be offered by each institution. A copy of a user's private keyring should be made with a standard passphrase (which may be null) and that keyring serially encrypted in the public keys of the institution's certification keys. Should the user lose access to their private key(s), they would then be able to regain a usable private keyring on application to the certification authority. Needless to say, they would have to provide adequate proof of identity! This escrow facility should be optional. Users wishing to keep control over who has access to their keys should be permitted to do so, at their own risk.
Eventually, a public key will need to be removed from service. This may be because that the corresponding private key has been compromised or irretrievably lost. ``Role'' keys, such as those for Postmaster, provide good examples of innocently compromised keys. When a member of staff leaves an institution, it is undesirable that they should still be able to read mail addressed to Postmaster, or to be able to sign documents as if they still had that role. Key revocation is the manner in which PGP public keys are permanently retired.
It is suggested that a key revocation certificate should be generated as soon as the key pair is created. This certificate should be held by a trusted third party, exactly as the key-escrow facility described above. Once more, adequate proof of identity will be required before the certificate is released and issued, to guard against malicious denial of service attacks. If the keys are generated by the institution, there will be no difficulty in also generating the revocation certificate and storing it securely. If the user generates the key pair, they must be able to obtain advice on how safely to create, store, recover and use a revocation certificate. The present PGP documentation is rather lacking in this respect.
When a public key is needed for use, it must be made available to PGP. The program itself looks for it on a special file called pubring.pgp in a standard place. This keyring is a simple collection of public keys. If the required key cannot be found, the user is asked for the name of an alternative keyring file. If the user does not possess the required key at all they must either acquire a copy or accept that they cannot process the information in question, whether that is encrypting for privacy or checking a signature to test for integrity and authenticity.
At the moment, there are a number of ad hoc means of acquiring someone's public key, and a couple of semi-automated methods. The former include asking the person concerned for a copy by email; on a diskette sent by conventional post; by using the finger utility (a number of PGP users make their keys available by this means), looking in a web page and so on. The key is then added, by an interactive run of PGP or by a front-end program, to the personal public keyring.
The semi-automated methods use the first-generation key server network. A number of machines around the world each maintain a large pubring.pgp containing over twenty-five thousand public keys (as of May 1996). The servers communicate with each other by mail or ftp in an attempt to ensure that all machines hold the same keys. It must be acknowledged that the attempts are not completely successful and different servers hold slightly different sets of keys. These servers are also available to PGP users. By sending appropriate electronic mail, or by accessing a Web page, the servers will respond with email (or whatever) containing the required key or keys. A few utilities, especially the Emacs RMAIL add-on mentioned earlier, are capable of interrogating the servers for required keys and adding the reply to the user's keyring. Most MUAs are not so obliging. Keys may be added, of course, by submitting them to a keyserver by email; similarly help (in any of several European languages) and an index may be obtained
The first-generation keyservers have a number of flaws, some of which are visible to the end-user. For instance, it is not possible at present to remove signatures and complete keys from the database. There are also problems with the size of the monolithic ring, which is almost beyond PGP version 2. x's capabilities. The more important one is that they use PGP itself to maintain the keyrings, and PGP was not designed to handle large keyrings. This problem is not directly visible to the clients, but rather it is the consequences that they notice. Responses to queries can take hours or days, though ten to fifteen minutes is more typical. The email servers generally queue requests as they arrive and run a batch job to clear the queue every fifteen minutes or so. The Web servers are better in this respect, giving almost instant responses, but some contain read-only copies of the email servers' keyrings and arrange that updates are sent to a suitable read-write server. Although next-day delivery may be acceptable to people wishing to send important information securely but not necessarily instantly, it does not permit MUAs to acquire needed keys invisibly between the user clicking the Send button and dispatch of the mail. If PGP is to become truly easy to use by non-specialists, rapid key provision will be essential. Rapid means a few seconds delay at most.
The present keyserver network is in serious trouble. There are over 25,000 keys on the keyrings, and PGP takes several minutes to add a new key to the ring when running on a mid-range workstation. When PGP was designed, expectations were that a user would have a dozen or two keys on their keyring. Adding a key, and checking its signatures, is done with an inefficient algorithm which takes time proportional to the square of the number of keys on the ring multiplied by the number of signatures on the key. The rate of growth in the key servers' keyrings is such that the present mechanism will be unusable within a year, even on fast machines.
There are two possible ways out of this situation. It has been stated that the next version of PGP to be released will have a vastly improved keyring maintenance mechanism. It should be able to handle rings with many thousands of keys in seconds, rather than minutes, and it should exhibit a much slower rate of increase in processing time as the rings become larger. It is not yet clear whether PGP version 3.0 will become available within the next few months. The other solution is a second generation key server, which distributes the data in a manner similar to the DNS, and which does not use PGP to manipulate the keys.
As PGP becomes more popular it will become ever more inappropriate for the servers to attempt to maintain copies of the global keyring. It will be essential that a distributed database be set up and managed. Compare the situation with internet name resolution: a single file, /etc/hosts, is adequate for a network of a few dozen machines, unwieldy for a few hundred and totally unusable when there are a million. The Domain Name Service was invented to solve this problem. The design of the analogue to the DNS for PGP keys is presently underway. The DNS as it currently exists cannot be used for a number of reasons, one of which is that keyIDs do not heirarchically parallel the key management structure. A group (of which both authors are members) is investigating these matters and, at the time of writing, believes that most of the problems in producing a service capable of handling keys by the million have been identified. We hope that the first implementations will become available towards the end of 1996.
PGP is widely used around the world. The development of PGP and its associated packages is carried out in many countries. Accordingly, it is vital that any UKERNA-sponsored initiatives are fully compatible with international developments. It is also important, in our view, that any local contributions to developments are made available to the global community. If we wish to have a system which we find satisfactory in our environment, we will need to argue our case and create tools which will be adopted by the rest of the community.
A number of ad hoc collaborations already exist at the personal level. As an example, the people running the first-generation email-based public key service are all members of a closed mailing list; they contribute to software development, co-operate in problem solving and so on.
Official interest in PGP services has been late starting but now seems to be picking up. The IETF has a secure-email working group and we believe that UKERNA should make a formal offer to assist with their work. The Dutch academic network, SURFnet, is setting up a PGP-based secure email infrastucture. They started almost a year before the UKERNA study and are beginning the implementation phase. A SURFnet representative, Teun Nijssen, came over to London to discuss secure email implementation in a large academic community. Among the topics discussed were the operation of certification authorities; key server provision in an international environment; user and institution support mechanisms; the populating of pgp.net (below); standards initiatives and co-ordination of national bodies such as UKERNA and SURFnet. That meeting was felt by the participants to be very useful to both communities. It is hoped to have a similar meeting with DFN (the German research network) shortly. There are no plans, as yet, to meet with analogous organizations in the rest of the world, particularly in the US, though we recognize that they most probably would be valuable.
The first concrete example of official international collaboration appeared in March 1996. At the meeting between SURFnet and UKERNA mentioned above, it was decided that a CD-ROM should be produced, containing a comprehensive collection of PGP-related material. The project was adopted by TERENA, and the CD was jointly produced by all three organizations. Four thousand copies were made in the first instance so that they could be distributed to academic institutions throughout Europe. The CD contains the latest versions of PGP for all common architectures (Amiga, Archimedes, Atari, Macintosh, MS-DOS, MS-Windows, Unix and Open-VMS); integration tools for mailers, editors and newsreaders; two keyservers (email and WWW); PGP's on-line help in fifteen languages; documentation in a number of languages; a complete keyring from the UK keyserver. In all there is over fifty megabytes of material on the CD.
A unified interface to services based around PGP would be easier to implement if a standard nomenclature for resources was available. At the moment, an ad hoc collection of machines on the internet run email-based PGP public key servers; another, overlapping, collection permit keys to be fetched by anonymous ftp and another collection have a WWW-based interface. Software is available by anonymous ftp but it is not always obvious where to look for a particular package, despite the best efforts of the authors of Frequently Asked Questions lists. Given the propensity for services to be run by graduate students without official permission from their institutions, it is not surprising that services disappear or migrate with very little warning.
In 1994, the domain pgp.net was created to allow a uniform naming scheme to be implemented. Each major component, such as public key service, or anonymous ftp access to packages, would reside on ` service .pgp.net' with that name pointing to the physical machine providing the service. With this structure, if a service is moved from one machine to another, a simple change to the DNS will record that fact --- client software need not know that any change has taken place. Examples of pgp.net addresses include ftp.pgp.net which currently points to the anonymous ftp archive at Oxford and its mirror sites, and keys.pgp.net which is a set of equal-priority MX records pointing at the current set of stable email keyservers.
It was recognized that the pgp.net resources would need to be distributed among a number of sites. (By ``distributed'' we mean simply that data may be found at more than one site; we do not say whether or not the data at one site is an identical copy of that held at another.) Accordingly, the domain has been split into regional portions by inserting ` region.' before the pgp.net. Thus, the key service intended primarily for German clients would be keys.de.pgp.net whereas British academia's ftp archive would be ftp.ac.uk.pgp.net. Note that this structure permits local customizations, such as help texts in an appropriate language, without altering the location independence of services.
At the time of writing, pgp.net is being populated. There are four sites in ftp.pgp.net --- located in Hamburg, Oxford, Paderborn and Tromsø. A mirror site in Korea is likely to come on-line shortly. The email key service has sub-domains in Germany (two servers, forming keys.de.pgp.net), Finland, The Netherlands, Norway, the UK and the USA; a Korean site is being tested. Other services implemented include www.pgp.net for a World-Wide Web interface to PGP-related resources, with sub-domains including www.de.pgp.net, www.no.pgp.net and www.ac.uk.pgp.net. The last consists of two machines, one each at UKERNA and Cambridge. The final resource presently implemented is mail.pgp.net, which provides a uniform and location-independent email address for the administrators (whoever they may be at the time) responsible for resources available within pgp.net domain. Valid addresses include firstname.lastname@example.org and email@example.com. The pgp.net domain is expected to grow substantially over the next year.
When we began this study, we were fairly sure that PGP would be sufficiently flexible and powerful to be used as a basis for JANET-wide secure email. After reviewing its capabilities, and especially, its limitations, we retain that view. Nonetheless, some substantial work needs to be done before convenient and secure email can be provided for the majority of JANET users.
It is quite clear that PGP can be integrated into mail user agents not originally designed for that purpose. The truly excellent work done by the authors of the Elm, Emacs and exmh packages is proof of that. The users of those packages find that PGP is easy to use in a manner that is perfectly natural in that context. It is equally clear that the majority of email users are not so fortunate, and that varying degrees of effort will be required to bring their tools up to the standards of the first three. Those MUAs for which source code or an API is easily available, such as Pine, should be straightforward though possibly laborious to bring up to full functionality. It is likely that some commercial mailers, such as OpenVMS MAIL, are likely to prove difficult to integrate fully. Even these utilities are not hopeless, however, as long as they provide hooks which can be used (or abused!) to call external programs in a few useful contexts such as composing and viewing a message.
We recommend that UKERNA commission workers to integrate PGP fully into those mailers for which source code is available. The outstanding candidate is Pine. We also recommend that UKERNA commission workers to integrate PGP into those mailers which are not quite so amenable but are in widespread use and which existing attempts at integration have demonstrated that it is possible to a large extent. The prime candidates in this class are Pegasus and Eudora. The final class of popular mailers (we ignore those used only by a tiny minority) are those which are closed commercial products. Some suppliers may be amenable to requests from UKERNA to make hooks available and/or publish an API so that PGP may be added alongside their product. We recommend that this be given serious consideration. An alternative approach would be to follow the leads shown by Private Idaho and privtool: to create a wrapper which calls the underlying mailer or to write an emulation of a popular mailer. Neither of these is completely satisfactory. The wrapper approach requires that the user learns another interface, hardly a characteristic of the ideal invisible software. The second, while superficially much more attractive also has problems. Not only may there be messy arguments over copyright of interfaces, re-writing a complex tool from scratch is a lengthy and expensive process --- not least because the emulation has to be extremely precise for it to become popular. We feel that we are not able to give concrete recommendations on how to procede with these closed commercial mailers, other than to suggest that the subject be investigated more deeply in the near future.
Our investigation of the present state of key service for PGP users has turned up several serious deficiencies, and good grounds for expecting that these can be remedied relatively easily. It is apparent that the present keyservers are adequate, barely, for the use being made of them. It is equally obvious that they will become swamped by the demand placed on them by the PGP-using community before the end of 1996. These characteristics are just as obvious to the present suppliers of the services and they are being addressed. We can reasonably expect that some sort of keyservice will come into being, just in time, irrespective of whether UKERNA contributes to the process. Nonetheless, we strongly recommend that UKERNA does so contribute.
We make this recommendation for the following reasons:
Accordingly, we recommend that UKERNA fund a one-year pilot project to prototype a key service which is both appropriate to JANET's requirements and consistent with developments elsewhere in the world.
Electronic mail is a global phenomenon. PGP is used throughout the world. Both are used by all groups within the community, by individuals and multinationals, by academics, medics and military personel. JANET users communicate with all of these. It is essential, in our view, that JANET marches in step. Accordingly, we recommend that UKERNA plays an active role in developing national and international standards, such as IETF Internet Request For Comments.
Virtually all PGP-related material at present is either public domain, freeware or purchasable at very low cost. This has undoubtedly been a major contribution to its widespread distribution, availability and popularity, themselves being stimuli for the building of further products. We therefore recommend that software, specifications, procedures and similar intangible products created as a consequence of UKERNA-sponsored activity be released freely back to the community which has provided so much already.
Strongly authenticated keys are essential to any secure email system worthy of the name. PGP, with its web of trust, provides the underlying mechanisms required to implement strong authentication. More is needed, though, than digital signatures. Trustworthy signatories must be created. We recommend that a distributed set of certification authorities be set up, with authority delegated to appropriate levels but the whole tied together in a heirarchy with UKERNA at the top level. In the first instance, this should be prototyped in a small-scale pilot study, the object of which should be to investigate the procedures required for the production signatures truly worthy of trust by even the most suspicious members of the JANET community.
We have received much valuable assistance from many people around the world; it is impractical to name them all but we wish to record our gratitude to them. We particularly thank all the people who assisted with the MUA investigations; the key server and ftp site administrators; the software authors who let us place their work on the CD-ROM and TERENA, UKERNA and SURFnet who funded it. Some individuals made especially substantial contributions. In alphabetical order, they are: Dennis Jackson, Teun Nijssen, Alan Robiette, Sue Weston and Jonathan Wignall. Finally, we thank Oxford and Cambridge Universities for letting us use their time, equipment and network bandwidth to support our portions of pgp.net.
We give only a few sources here. Consult the first book and selected entries in its bibliography for an introduction to cryptography.
There are many on-line sources of material on cryptography, PGP and data security, but most of them are quite ephemeral. The Frequently Asked Questions posted periodically to the alt.security.pgp and sci.crypt Usenet newsgroups are informative and provide up to date references to on-line material. Information about PGP and related matters can be found at the URL http://www.pgp.net/pgpnet/ and links therein. PGP distributions, documentation, integration tools and such like are available by anonymous ftp from ftp.pgp.net in sub-directories of /pub/pgp --- get README.html in the first instance.
Schneier has written the definitive reference work for modern computer cryptography. Several chapters give an introduction to the field; many more go into details of cryptographic algorithms, protocols and implementations. It is especially valuable for its comprehensive bibliography with over 1500 pointers into the literature.
Bruce Schneier, Applied Cryptography: Protocols, Algorithms, and Source Code in C, 2nd edition, Wiley, 1996, ISBN 0-471-11709-9
A general survey of secure electronic mail, including descriptions of both PEM and PGP is given by:
Bruce Schneier, E-Mail Security: How to Keep Your Electronic Mail Private, Wiley Publishing, 1995, ISBN 0-471-05318-X
Three books concentrating on PGP in particular. We prefer Garfinkel's version, but all are good treatments of the program and its use.
Simson Garfinkel, PGP: Pretty Good Privacy, O'Reilly & Associates, 1994, ISBN 1-56592-098-8
William Stallings, Protect Your Privacy: The PGP User's Guide, Prentice Hall, 1994, ISBN 0-13-185596-4
Philip R. Zimmermann, Official PGP User's Guide, MIT Press, 1995, ISBN 0-262-74017-6
User Agent Usage No of sites %of total (154058) Pegasus ? 70890 (on Windows and DOS). 17 sites 27.51% VMSMAIL* 37296 (although numbers reducing) 14 sites 14.47% PINE* Approximately 27070 + more undefined. 29 sites 10.51% Elm* Approximately 26452 + many more 26 sites 10.27% Eudora* 11830+ significantly more on all three platforms. 32 sites 4.59% Wordperfect Office 11220 (will move to GroupWise) 3 sites 4.35% ECSMAIL/* 11153 (on Windows and DOS). 12 sites 4.33% Simeon cc:Mail 8920 + more on all three platforms. 6 sites 3.46% (the 8000 will be replaced next year.) Pathworks 8400 1 site 3.26% MXMail in OpenVMS 5000 1 site 1.94% Mail 5555 7 sites 2.15% MSMail 4260 (on Windows and DOS) rising to 14260 when Microsoft Exchange available. 11 sites 1.65% Unixmail /Berkeley Mail /Mailx* 4280 plus a small number. 9 sites 1.66% (someone has offered to look at mailx) Novell Groupwise* 3532 2 sites 1.37% mailtool 3471 + small number of others 12 sites 1.35% MH/XMH /EXMH* 2902 + undefined. 11 sites 1.13% (a number of sites have offered to look at MH and EXMH ) Whitemail 2500 (Windows). 1 site 0.97%
Nupop 2250 (DOS). 2000 may move to Pegasus. 1 site 0.87% SMTP mail on VMS 2200 1 site 0.85% First Class 2000. Will be 50000 next year 1 site 0.78% GlasgowVME 2000 1 site 0.78% SunOS Sendmail 1230. 1 site 0.49% NeXTMail 830 1 site 0.32% X.400 (unspecified UA) 500 1 site 0.2% Popmail2 A few (MAC). 330 on PC 3 sites 0.125% Mail-it Several hundreds 1 site 0.125% Emacs 250 + a small number. 2 sites 0.1% Route400 206 (PC+MAC). 2 sites 0.08% All-In-One 200 1 site 0.08% mailx 200 1 site 0.08% NFS Mail 200 1 site 0.08% NFS Lifeline 155 1 site 0.06% Dxmail 100 + a small number 3 sites 0.04% B&W 100 (DOS). 1 site 0.04% PMDF 40 1 site 0.02% Select Mail 5 1 site 0% SGI Sendmail 2. 1 site 0% Binmail Small number. 1 site (It is considered that it would be too hard to provide a reasonable interface to Binmail. This will not be looked at further.) EMMA Homegrown, available on a number of platforms 1 site Hundreds of users. Looking at PGP. Lotus No numbers given. On all three platforms. 1 site mush Small number. 1 site PC-Pine* No numbers given. DOS. 1 site. Pmail Numbers unknown. All three platforms. 1 site ream Small number. 3 sites rmail Small number 1 site VM ? 2 sites Winqvt ? 1 site Xmail Small number 2 sites Zmail A few. 3 sites
Minutes of a meeting held at University College London on 13 July 1995. The business of the meeting was to introduce the UKERNA Secure Email project to interested parties; to describe the current state of integration of PGP into mail user agents; to ascertain the current level of usage of PGP in the community and to formulate plans for improving the integration of PGP into commonly used MUAs.
The following people attended the meeting.
Adrian Barker UCL Piete Brooks Cambridge Alan Cox NERC Ines Day RAL Morna Findley Edinburgh Clifford W Fulford North London M Gahan UCL Simon Greaves Heriot-Watt Martin Hamilton Loughbrough R J Hynds IC Dennis Jackson UKERNA Paul Leyland Oxford Peter Macdonald Cambridge Daniel R Moore IC Philip Overy RAL Alan Robiette Warwick Sue Weston UKERNA Jonathan Wignall UKERNA Adrian Winckles NENE
Sue Weston introduced the Secure Email project, giving UKERNA's view of what was required and described UKERNA's role. Paul Leyland then gave a description of the capabilities of PGP at present, and what infrastructure presently exists. ``Infrastructure'' included: expertise; software archives; availability of PGP for various platforms; public key servers; integration with MUAs, newsreaders, editors and windowing interfaces; available literature; sources of expertise.
A brief statement of the legal position of PGP in the United Kingdom was given in response to questions from those present. Paul Leyland then reminded the meeting that UKERNA had commissioned a report, and that implementation would be the task of a follow-on study. However, it was expected that implementation of an enhanced infrastructure would be undertaken anyway.
The second part of the meeting consisted of a description, by Paul Leyland and Piete Brooks, of the scale of the problem. The email-using population of JANET is approximately one million people, the vast majority of whom know little or nothing about secure email. The size and nature of the community has several consequences: the infrastructure must be robust despite having to support a hundred times as many people who are presently using PGP world-wide; the integration with standard utilities must be a seamless as possible and there must be extensive back-up in the form of education, training, documentation, expertise and the like. The international and commercial environment must also be taken into account: JANET users communicate widely and secure email with non-JANET colleagues will be expected to be available; conversely, since PGP is an internationally used system, JANET must track changes elsewhere and contribute to them. At least part of the problem is deciding where efforts should be concentrated, which was the purpose of the original survey. Paul Leyland concluded by describing some of the parallel efforts which, although were not directly concerned with PGP --- MUA integration, were important background information. These included the setting up key certification services and public key servers; the development of a consensus on what is ``acceptable'' for the community in using PGP; the work being done by SURFnet in the Netherlands on a similar secure email system.
The following session had each person in turn describe their personal and their institutions' usage of secure email and views on the PGP. It became clear that a good number of individuals within the academic community are PGP users, but that very few institutions had formulated any kind of policy on secure email. A number of sites were concerned about legal constraints, largely arising from the manner in which some versions of PGP had escaped from the United States in violation of US export regulations. Uncertainty over whether ``commercial'' use of PGP was permissible in the United Kingdom was expressed; it was agreed that this topic required clarification. One representative pointed out that the Data Protection Act required personal data to be safeguarded, and that robust encryption was a good tool for that purpose. A number of people mentioned that certain users in their institutions were forbidden to send sensitive information by electronic mail. Several institutions were more interested in authenticity and integrity than privacy, examples of information required to be tamperproof including course-work sent by tutors to students. A fairly wide range of MUAs were in use by those present, but almost everyone described the integration with PGP as being barely adequate, at best.
Sue Weston then went through the results of the mail user agent survey. She stressed that the survey had been carried out to provide guidance only, and not with any ulterior motive, as some respondents had been worried that their favourite agent had not been in the top 95%. She reassured them that minority users would not be forbidden from using PGP, only that UKERNA-promoted efforts would be concentrated on the popular MUAs. She asked whether anyone present felt strongly that particular MUAs below the 95% cut-off should be included, but none were mentioned. Paul Leyland then gave a summary of the software in the Oxford anonymous ftp archive, indicating that some, though not all, of the groundwork had already been performed. The major omissions were, naturally, commercial mail utilities such as Simeon.
The meeting concluded with a call for volunteers to investigate and report on one or more MUAs of interest to them. The list of software, platform and investigators is as follows:
Philip Overy (RAL) will investigate interception on PC's to convert mail between mail agents and POP account. Private Idaho shell and PGP clip DOS mailers will be looked at by Pete Macdonald (Cambridge), UKERNA + Morna Findley and Clifford W Fulford will investigate their windows mailers using PGP
Minutes of a meeting held at Imperial College London on 18 December 1995.
Meeting started at 10.45am
In Attendance Institution Initials Email Address
Paul Allatt Imperial College PA firstname.lastname@example.org Jason Bain Imperial College JNB email@example.com Adrian Barker UCL AB A.Barker@ucl.ac.uk Piete Brooks Cambridge PB firstname.lastname@example.org Morna Findlay Edinburgh MF email@example.com Jeff Goldberg Cranfield JG J.Goldberg@cranfield.ac.uk Stan Houghton Bradford SH S.J.Houghton@bradford.ac.uk Bob Hynds Imperial College RJH firstname.lastname@example.org Dennis Jackson UKERNA DJ D.Jackson@ukerna.ac.uk Dan Moore Imperial College DM email@example.com Philip Overy RAL (CLRC) PO P.J.Overy@rl.ac.uk Alan Robiette Warwick AR A.Robiette@warwick.ac.uk
Dennis Jackson welcomed those present to the 2nd meeting of the Secure Email Group.
Apologies for absence were received from Sue Weston (SCW), UKERNA and Paul Leyland (PCL), Oxford.
These were accepted as accurate.
The action on SCW to talk to the JISC about the legal position had not been done.
DM said that he was worried about the legal position, specifically if the community was to set up a secure email service, someone may then say that we can't. DJ to follow this up. [Action:DJ]
AR stated that he was worried about the European context. For example, France had banned the use of any encryption.
PCL had provided PGP and MIME information requested.
PB outlined the work that had been done at Cambridge and Oxford. The 1st quarterly report had been produced and distributed. This will be the format of the final report but will be updated at regular intervals. Comments are welcome.
DM said that he was worried that many institutions are trying to solve the same problem, e.g. generating random numbers used for keys. PB said that this wasn't very difficult. DM then asked how PGP could be modified to accept and external source of random numbers. PB replied that PGP should be able to take this information now. JG suggested it may require a simple modification to the code. PB agreed to look at how this problem can be solved, and look at how others are doing it. This information will be added to the report [Action:PB]
RJH said that for such information to be useful for the start of the 1996-97 academic year, Computer Centres need this information by May/June 1996. PB said that recommendations for a College/University- wide service would not be available until later in 1996. DM remarked that the real problem with a College/University-wide service is how to generate and distribute keys to 5000 students at the beginning of the new academic year.
RJH then said that he thought the next problem to look at would be pass phrases. He suggested that Key-Escrow would be necessary. PB agreed and said that keys should be held centrally in a secure format. Pass phrases would then be the responsibility of the users, probably held on a disc. DM said that he was still worried that institutions would work on this problem in isolation and requested a UK-wide recommendation. DJ suggested that there were two problems: One generating a large number of keys, and secondly keeping Escrow copies of this keys.
PB then went on to discuss other areas of activity. He reported that a CD-ROM with PGP 2.62i would be produced in conjunction with SURFnet, TERENA and others in Europe (possibly DFN). Information contained on such a CD would be binaries, sources, documentation and integration tools. It was hoped that PGP 3 would be available to add to this disc, but this may not be possible. About 5000 copies would be produced, and it is hoped that 2/3 would be sent to each JANET institution.
PB also reported that he had taken charge of the pgp.net DNS domain. This domain contained a set of equal priority MX records pointing to the current set of stable email key servers. JG enquired if PGP documentation would be changed to reflect this new domain. PB responded that he didn't think it would in the short term, but the machines listed in the current documentation actually form servers in the new domain. Within the domain there will be country codes, such as uk.pgp.net. You can also prefix each domain with ftp and WWW. e.g. ftp.uk.pgp.net points to the server at Oxford. JG asked PB about his work on a key lookup server. PB said that he didn't like mail interfaces - he would prefer an on-line system. He said that he had written a PERL script that would contact a WWW server to retrieve keys. He said that this was slow using the current implementation of keys servers since they were not designed to cope with the current 12000 key load. He went on to describe another PERL script that he had written which put keys into an associative array with dbm lookups - this was much faster. He suggested that we needed a DNS like service to do this, but agreed that reverse lookups would be difficult to do.
JG enquired when (a subset of) the protocol to the WWW interface would be made available. PB replied that he had distributed this to any developer that had asked.
AR how would the selection of tools for the CD be made. DJ said that most software that existed would be put onto the disc. Documentation would be made available for the good software, less for the poor software. DJ suggested that WWW pages may be made available on the CD as well. RJH enquired when the CD would be made available, DJ responded that is hoped to distribute it at NetWorkshop '96 or JENC 7 in May 1996.
It was agreed that the group would look at each MUA in turn.
Unix-Elm: PA said that Imperial had been looking at 2.4.24pgp3. Sendmail worked fine, but there were problems with the elm code on Silicon Graphics machines when trying to received mail. AR said that there were two PGP implementations of elm. The other was the ME version developed under Solaris. He suggested that Imperial should look at this. JNB enquired which flavour was the most popular in the community. JNB will discuss this with Martin Hamilton. [Action:JNB]
Unix-Pine: JG that he had used the MK PGP csh script. It can be used to decrypt incoming messages and validate keys. It wasn't fully integrated into Pine. AR said that he had used this software and thought it worked quite well. However, he did not think it would be a good idea to put them in front of naive users - since it was not integrated well with the MUA, it looked quite different from the rest of Pine. MF agreed to produce a report on Pine [Action:MF]
MF asked what type of report was necessary. DM suggested that any information about experiences using the software would be most useful. MF then asked where the reports should be sent. DJ responded that they should be sent to the mailing list, firstname.lastname@example.org.
Unix-UCB: PCL had circulated a report.
Unix-PGP sendmail: MF said it would be difficult to integrate this into a site like Edinburgh. It does encryption for the user, but the option of decryption is disabled by default! PB said that it would encrypt ALL messages. MF said that most people would not want to use PGP for all mail. PB suggested that an extra header field requesting encryption would be useful.
Unix-ML mailer: JG said that this was an X-windows IMAP based client. It claims to have PGP integration built in. He has seen a demo, but it tends to crash on DecStation and Alpha machines.
Unix-eXmh: PB said that this was a fully integrated product with a tcl/tk front end to mh.
PC-Attismail: SH said that this should be taken off the review list. It was developed in the Netherlands and was very difficult to get working.
PC-Pegasus: AR said that the Mac version was not very good. The DOS version suffered from the lack of multi-tasking in DOS. The Windows version has basic encryption and signing features. The author of Pegasus has produced an API to allow PGP hooks, and another person has developed the PGP software. There are a few rough edges.
PC-Private Idaho: PO said that this was a difficult package to obtain and was rather DIY. It wasn't very well integrated and required a good number of key strokes to encrypt a message. PB suggested that this would be tolerable if a person only sends one/two PGP messages per week. He thought that he would send one secret and one authenticated message per week, but would receive more authenticated messages. AR said we shouldn't waste too much resource on such packages. JG suggested that we should add new MUAs to the Oxford archive as and when we get them to save the time of people trying to transfer them from abroad.
PC-PGP Clip: AR said that this was OK as clipboard tools go.
MF reported that Edinburgh UCS were not too interested in PGP - they say that students will not use it and staff mostly use commercial MUAs. DM suggested that information about MUAs should be in a easily to use form. PA said that Imperial were hoping to use PGP with a small number of users first then growing. RJH said that users will use PGP - we can't stop students using it.
PA said that there was a real problem with Microsoft Mailers, especially since new versions of Windows are shipping with these products. He said it was difficult to link these products with existing email infrastructures. Users will then demand secure email via these products. It is difficult talking to Microsoft. AR suggested we need to recommend general tools (e.g. clipboard utilities) for these products, but mention the other supported (public domain) MUAs at the same time.
JG asked if anyone had looked at ECSMail/Simeon or other IMAP based mailers. RJH said that Peter Whitehead at RPMS should be approached. PA reported that Simeon version 4 should be available in January 1996 for Windows, Mac and Solaris 2. There will no security hooks, but some authentication using Kerberos. Future development will be with PEM. ECSMail will become a public domain product.
DM enquired if a WWW service on MUAs an configurations would be made available. AR suggested that we also need further information on installing and configuring tools (possibly example .INI files for Windows).
Mac-Eudora: DJ said that PGP 2.62i worked using the clipboard anyway. There is a released version for Eudora with Applescript integration tools. However, these scripts do have some bugs - decoding works fine, but signing only works on small messages. It doesn't handle attachments.
VMS: JG suggested that it may be possible to port the scripts used with Pine to VMS. He was thinking about rewriting these scripts into PERL. AR suggested that a PGP interface with an external editor might be a better solution.
SH enquired if we were talking about text only body parts, or would the MUAs cope with any type of attachments. DJ said that a small number of MUAs can copy with attachments, but most don't. PB said that MIME would be the only solution to this problem.
[Break for lunch and demonstrations at 12.55pm]
RJH said that administration wanted a method of digitally signing orders. AR went on to talk about MIME Objects Security Services (MOSS) - an IETF draft. He said that different implementations of MIME did different things with attachments. There is a commercial implementation using PEM. A MIME type application/pgp was an unofficial type used for multi-body parts. PB suggested that encrypting the whole message (all body parts) as a whole rather than individual body parts. AR said that most MUAs could not cope with this. It was agreed that a discussion document on this subject should be produced. JNB suggested that Martin Hamilton should be approached. DJ agreed to do this. [Action:DJ]
JG asked with MIME types could be stacked - can a multi-part message contain multi-part messages?
AR said that Warwick needed a way of signing word processor documents for administration. DJ suggested that the only solution at present was via a bi-lateral agreement.
JG suggested that PGP 3 would include enhancements. Work on this version was being co-ordinated by MIT. DJ believed that the patent problem had been solved as MIT had permission to use the patented techniques. The patent did not apply outside the USA and he thought there may be attempts to export the code legally. PB suggested that a book would be made available containing the new code which was legal to export outside the USA. AR reiterated the point made earlier that the situation within the UK should be clarified with the JISC.
Reporting back to the group on the use of MUAs
Milestones: MUA reports by the end of Feb. '96
PB/PCL work ends in July '96
A set of headings for inclusion in a MUA report were then agreed:
JNB will mail a template to the list, PB will produce a WWW form. [Action:JNB/PB]
It was agreed that the group should meet during NetWorkshop '96 at Sussex University. Non-NetWorkshop delegates should be able to attend an afternoon session about secure email. DJ to advise. [Action:DJ]
A number of useful books were discussed. Details from the JANET-CERT WWW pages.
The meeting closed at 3pm.
J.N. Bain, 20th December 1995
Minutes of a meeting held at NetWorkshop 24, University of Sussex, 27 March 1996.
In Attendance Institution Email Address
Kevin Barfield Coventry University email@example.com Philip Black Queen's University, Belfast P.Black@qub.ac.uk John Brooks Manchester Metropolitan University J.Brooks@mmu.ac.uk Max Caines University of Wolverhampton M.B.Caines@wlv.ac.uk Chris Chalk Cambridge University firstname.lastname@example.org Bob Chapman Queen Mary and Westfield MDS R.Chapman@mds.qmw.ac.uk Paul Cheetham Manchester Metropolitan University Julian Coleman University of Newcastle-upon-Tyne email@example.com Adam Cooney University College, Scarborough firstname.lastname@example.org Colin Cooper University of Glasgow C.Cooper@compserv.gla.ac.uk Francis Delafaille University of the West of England email@example.com David Dunham University of Surrey firstname.lastname@example.org Martin Edmunds Martin Edmunds Networks M.J.Edmunds@Greenwich.ac.uk Vin Everett Medical Research Council V.Everett@mrc-bsu.cam.ac.uk Joe Gluza Cambridge University JLG1@ucs.cam.ac.uk Patrick Gosling Cambridge University email@example.com Simon Greaves Heriot-Watt University S.J.Greaves@hw.ac.uk Mike Harron Queen's University of Belfast M.Harron@qub.ac.uk John Holman Queen Mary and Westfield College J.G.Holman@qmw.ac.uk Dennis Jackson UKERNA D.Jackson@ukerna.ac.uk John Landamore University of Leicester firstname.lastname@example.org Bob Lawrence University College, London email@example.com Zoe Leech Liverpool John Moores University Z.A.Leech@livjm.ac.uk Paul Leyland University of Oxford firstname.lastname@example.org Aidan McDonald Regional Technical College, Carlow email@example.com Diane McDonald University of Strathclyde D.McDonald@strath.ac.uk Vlaster Malinek Medical Research Council firstname.lastname@example.org Trevor Meighan Stranmillis College, Belfast T.Meighan@stran-ni.ac.uk Phil Overy Rutherford Appleton Lab P.Overy@rl.ac.uk Gareth Owen Aston University email@example.com Marcus Pattloch DFN, Berlin Pattloch@dfn.de Jon Peatfield Cambridge University J.S.Peatfield@damtp.cam.ac.uk Malcolm Ray University of Westminster firstname.lastname@example.org Bruce Rodger University of Strathclyde Bruce.Rodger@strath.ac.uk Alex Sharaz Hull University A.Sharaz@ucc.hull.ac.uk David Sheryn City University email@example.com Dave Shield University of Liverpool D.T.Shield@csc.liv.ac.uk Colin Silk Keele University C.L.Silk@keele.ac.uk Christine Stamp University of Greenwich C.Stamp@Greenwich.ac.uk Alan Stanier University of Essex firstname.lastname@example.org Mohammed Tariq University of Bradford M.Tariq@Bradford.ac.uk Peter Taylor Newcastle University Peter.Taylor@newcastle.ac.uk Alan Thew University of Liverpool Alan.Thew@liverpool.ac.uk Peter Tribble Medical Research Council P.Tribble@hgmp.mrc.ac.uk Mike Zanker Open University A.M.Zanker@open.ac.uk
The minutes were taken by Phil Overy, who has attended both the other PGP meetings. This meeting was very full, and almost none of the participants in previous meetings were present.
In previous meetings, the typical user for PGP was seen as a university department which would use private and public key pairs to exchange examination papers and the answers from individual students. Key creation for such a large number of users is seen as a big problem --- PGP was never designed with features that would make it easy to administer for a large group of people.
The final draft report about the first phase of the Secure Email project is on the URL http://www.uk.pgp.net/pgpnet/secemail/q3.html
The meeting started with the delegates introducing themselves. The representative from the German research network DFN said they intend to introduce PGP secure email in the way the UK and the Netherlands have already begun to do. Dennis Jackson and Paul Leyland said that UKERNA wanted to use PGP especially to communicate security problems with the CERT teams around the world and with site security contacts.
A continuing problem has been the bad integration of PGP into email user agents. None of the email authors is prepared to take the risk of selling a PGP-email product. However several systems allow library calls and user exits which would make it easier to build a more integrated PGP/email product.
http://www.ja.net contains some pages in which the earlier secure email meeting was discussed (linked from the JANET-CERT or Technology Group pages). http://www.pgp.net/pgpnet/ is another source of information.
Last autumn, a survey was made of different email user agents in use around the community. The result is being used to decide on the targets for creating integrated PGP email user agents. Pegasus, which is the product most used in the universities, is fortunately easy to integrate and some integrated versions are already written. The survey was representative --- 57 institutions replied, representing 1/4m users of email. The results showed that 33% use Pegasus 16% Pine 13% Elm 12% VMSMAIL. CCMAIL, mail (Unix mail), MSMail and Eudora were surprisingly low in the statistics. It was disputed that VMSMAIL is likely to disappear soon. The fact that Netscape 2.0 includes an email user agent led Paul Leyland and others to wonder whether Netscape should not be included as a mail user agent.
A typical PGP user will not in fact send many encrypted emails --- Paul Leyland said that editor or mailer call-outs might be useful to integrate PGP into the user agent or delivery agent; ideally Netscape would be set up with a seamlessly integrated PGP. Pegasus being the most important user agent, the experts wondered whether DOS (ie non-Windows) agents were still important --- it was felt that since most users now booted Windows from AUTOEXEC.BAT, it was unnecessary to worry too much about full-screen DOS versions. DOS Novell Netware ignores whether PGP is present or not --- Windows Pegasus does the typical PGP email functions, but does not include key management. The Pegasus-PGP integrated package is part of the CD-ROM distributed jointly by several bodies including UKERNA.
Would key management be needed in an email user agent? The experts felt that a user agent should be able to send / encrypt, sign, insert a public key and to receive / check signatures, fetch keys and decrypt automatically. For encrypting/ the PGP user agent should fetch, not store the user's public key (storing might mean that subverted and revoked keys continued to be used) although there is no problem that public keys will be cracked. Cracking takes a very long time for both RSA and IDEA. There are no known flaws in the randomisation of the 128-bit session key, and 512-bit public and private keys are the PGP default anyway, a 512-bit key ``can be broken in a year for an outlay of 1m dollars per key'' (Paul Leyland) while 1024-bit keys are ``1--10m times harder to crack''.
A questioner from the floor asked how the key servers will function --- the complicated reply was deferred.
Eudora was criticised on the Macintosh, however it was also said to be the best available (apparently mail user agents aren't very good on the Mac). The low usage of Eudora surprised Paul Leyland. Pine was discussed --- which form is most used? When it was stated that Pine on the PC was hardly used, Cambridge said that they had many users of the PC version of Pine --- Cambridge seems to be an unusual site in this respect.
How should PGP be implemented? It was suggested that it should be available on the platform at whatever level made calls to PGP were easiest to make, so that DOS and Windows setups would be done differently.
Is it pointless to run PGP on a shared computer, since the private key will be available to the systems administrator? Someone from the floor pointed out that it was assumed that the threat was internal, but many people were quite happy with their site security and only worried about attacks from the Internet. PGP encryption of a server's contents (without the private key on the server) also reduces a server theft's importance --- although the actually valuable server is gone, at least its data is of no use to the thief.
Continuing to discuss shared mail servers, unix mail and binmail were mentioned --- both are still in use. Silicon Graphics machines cannot run PGP 2.6.3 at the moment but Elm has been made to run with PGP on Solaris, however the updates are ``as is'' from a user in Finland.
The meeting was concerned that the UKERNA initiative might be overtaken by events if all the user agents acquire integrated PGP, and the existence of an initiative to use secure objects and MIME (MOS / SMIME) may be as useful as PGP in the future. Dennis Jackson was well aware of past mistakes of the JNT and said that if the initiative WERE to be overtaken by events, development would cease, however Paul Leyland pointed out that PGP developers perceive SMIME as a potential threat because its proposals are likely to be watered down by the US government: Give-away products and de facto standards may well undermine PGP, in which case the secure email initiative would cease working on PGP, but at the moment there is no sign of that happening.
Elm will continue to be used so there has to be some work on it. VMSMAIL is not such a problem --- it is being used as a server product so the user agent with IMAP or POP can be run with PGP from a workstation. It was stated that VMSMAIL contains the hooks to run multi-threaded processes, so calling PGP from VMSMAIL to read/send mail is in any case not difficult. When Dennis Jackson questioned whether it was worth the effort, it was pointed out that VMSMAIL is used on 10 sites in the UK. Sun mailtool covers only 10% of users. PP has a separate problem (how to encrypt mail to a list of users) --- Dennis Jackson proposed that VMSMAIL and DOS Pegasus be ignored as they were on their way out / little used. CCMAIL also poses a problem. Various people wondered how you could get users to change to another user agent --- it was pointed out that users can be ``re-educated'' and when their favourite interface is no longer supported, they gradually lose interest anyway. Dennis Jackson then pointed out that although a new intake of students will adapt to any kind of email they are offered, a staff member who has to cope with email going back 8 years will not want to read previous files in an incompatible interface. Dennis Jackson said that both the Macintosh and its Eudora user agent need to be worked on --- he could point out where bugs exist in the Applescripts if anyone wanted to volunteer to fix them. Were any other projects worth discussing?
ECSMail and Simeon --- both are commercial; it was made very clear that ECS were unlikely to do any work on their product. Netscape and other mail-capable Web browsers such as Microsoft Web Explorer should perhaps be added to the list of PGP integration projects. When Dennis Jackson asked for volunteers to produce PGP implementations on specific platforms, Paul Leyland pointed out that the shortly to be announced PGP 3.0 official version with APIs should make this job much easier to do. Dennis invited people to volunteer by email or after lunch.
The meeting resumed on the subject of key servers, with Paul Leyland and Piete Brookes' experience as implementers very much the main topic. A PGP email-driven key server has existed for one or two years and now contains 26,000 keys ``because everyone has email'' (PGP is NOT an email package; it is a way to encrypt data which has become associated with email). The delays in the servers can be minutes to days, because servers batch up requests and then reply, but the main problem is that PGP itself is the database engine, and is designed for relatively few users, so adding new keys can be very slow. Well within a year, Paul Leyland's key server will be no longer able to cope with new requests. A WWW-based key distribution is much quicker to FETCH keys, but this doesn't solve the update problem. Every key server maintains a copy of the global key ring: In the ``one and a half'' generation MIT key server now in beta test, the world's keys are still held on a global key ring, but by using proper database technology the global key ring has a faster update time. The second generation of key server is a rewritten DNS --- keys can be 5kbytes long, too long for DNS ``fetches'' and the DNS isn't designed for the hierarchical structure to be used for the PGP key server, but the mechanism is exactly the same as for the DNS in its intentions. There is a big drawback with PGP key servers as they stand --- PGP keys can't be removed even after the owner has forgotten the pass phrase, although the administrators can be asked to stop handing out such keys. There is also an attack on PGP by flooding the key server with bogus keys --- since the algorithm for key update slows down as the square of (even disabled) keys, this can cripple the key service.
Desiderata for a better PGP key server include:
There is no technical problem if users have different key lengths (384bit --- crackable, 512-bit --- secure, 1024-bit --- secure even to military organizations whose messages might be worth cracking by supercomputer over a year), and users might refer to, eg, POSTMASTER to retrieve keys --- X.500 was also a possibility, although not everyone can access X.500 (it is interfaced with the DNS, however). The meeting went on to discuss the problem of revoked keys (keys which have been misused by someone or whose owner has forgotten the password): Should key service implementations include an expiry mechanism? Ideally keys might time out, however not everyone would want this. Someone who has revoked their key is likely to tell friends and contacts about the revocation, but might not reach everyone: In the case most interesting to university, the keys issued to students and associated with their membership of the university could be given a ``time to live'' of perhaps 3 years so that when their courses end, they no longer have access to key-controlled privileges; it might then be necessary to be able to extend the life of a key with an expiry date. There then followed an exchange about cacheing --- the key server design is intended so that keys are always fetched and never cached, so that revoked keys never cause a problem (the ways of subverting a key are discussed in the PGP documentation): Paul Leyland: ``I would hope that key servers would respond fast enough that you don't need to cache PGP keys'' from the floor: ``that presupposes not implementing servers until everything works --- in reality people will cache'' ``agents will need local storage but local storage is a problem if you revoke keys'' ``but if you know who you gave keys to, you can tell them about the revocation'' Paul Leyland: ``For most purposes you fetch keys at the time --- you don't store them. There needs to be standards, draft RFCs or whatever to decide on a port number. As long as the API is clean we can progress to a DNS-like key service in pilot form at the end of '96. Only about 3 people in the world can say precisely what a key server should do.''
From the floor: ``why should keys grow?'' Paul Leyland: ``signatures --- there are people who trust that key''. ``You can chop off signatures from your own personal key, but there should be a way to stop other people signing your key if you don't want them to'' (although those who sign must use their private keys, they will frivolously sign and replace other people's keys --- the result is that a heavily-signed key is no guarantee of a trustworthy signature).
From the floor: ``Signing a key will be slow with 2000 users'' (Universities want to set up keys for every new student before the students arrive, so the computer managers have to generate about 2000 signatures in one batch). Paul Leyland ``A key signer will probably become available to every bozo on the Net --- it shouldn't be, but it will''.
Dennis Jackson invited suggestions of how to manage PGP keys for students, eg should you hand out an ``escrowed key'' so that in appropriate situations a site can decrypt the email etc.(``escrow'' means that a trusted party holds a copy of the key).
When a student leaves, there is no necessity to revoke the student's key, but in PGP3 you will be able to revoke a signature validating that key, so it becomes untrustworthy to the signature-checker.
Escrow has been contested successfully for signatures --- the US government has not been able to convince the US courts that it should be allowed to forge identities so an unencrypted but signed document using PGP can be legally used to verify someone's identity even in the USA. There continue to be reasons why the contents of documents should not be secret.
From the floor: ``Reading the messages is not the main worry, it just may be useful to be able to revoke student's keys when they leave.''
The subject changed to the way a PGP key is searched for in the key server. Paul Leyland: ``Principal user ID includes email address by recommendation.'' It has been suggested that servers should ONLY fetch exact matches --- some people don't like that. It has been suggested that super servers should try searching all round the world to find the right server for a particular key --- it will work for 100k users only, there should be a set of draft RFCs published. PGP 3.0 with its greater flexibility of signature keys --- or rather its unavailability, is a ``log jam'' which is delaying PGP --- users double every year. Paul Leyland's server has had 60k messages in its lifetime up to now. It will be trivial to move keys from the old system to the new because most keys will reside in local servers and not in the superservers; email will be only one of the access routes.
Dennis Jackson pointed out the mailing list email@example.com
Sue Weston ( S.Weston@ukerna.ac.uk) and Dennis Jackson ( D.Jackson@ ukerna.ac.uk) are the contacts for the Secure Email project.
Generated from the LaTeX source by LaTeX2HTML