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.