Strategy month

[fanf]

According to Our Glorious Leader the Computing Service's director, March is "strategy month" and we are supposed to come up with ideas. So, this is my long-term wish list. No restraint has been exerted in its compilation :-)

• Get the Chat service deployed!
  
• Hermes projects:
  
  • Re-do and improve the anti-spam and anti-virus infrastructure. This has three parts:
    
    1. Replace MailScanner with exiscan, so that we can scan messages at SMTP time, and reject those we don't like instead of discarding them. If we don't want to rely totally on ClamAV we'd need to replace McAfee with a better commercial AV scanner, because McAfee is not fast enough for non-batch-mode scanning; it's also pretty bad at promptly issuing new signatures. This would allow us to have a default SpamAssassin threshold (without the lost-email consent problems caused by the way MailScanner works) which in turn would help with our AOL problems.
       
    2. Allow per-user options at SMTP time, e.g. spam threshold, stricter sender verification, greylisting, etc. This requires some data-shifting infrastructure which I have made a small start at, and user-interface extensions to Prayer.
       
    3. Add a new component for per-user statistical spam filtering. This would live on the message store (with other per-user state), and hook into message delivery for initial filtering, and copying to or from the spam folder for training. Again we need user-interface changes to Prayer to present the results of the filter and allow users to train it - similar functionality to full MUAs like Mac OS X Mail or Thunderbird.
       
  • Shared folders. Requires a new IMAP proxy (like the Cyrus Murder) and changes to the replication system. Does Cyrus 2.3 have the necessary functionality?
    
  • Internationalized webmail. Replace (or run alongside) Prayer with some better-known software?
    
  • Finish the ratelimit project. Will require time to work on a user interface, so that it is sufficiently friendly. My current idea for how it would work requires the double-bounce patch mentioned below.
    
  • Deploy DKIM (server-side message signatures for anti-spam).
    
• Exim projects:
  
  • Improved hints DB infrastructure. The aim is to remove the performance bottleneck caused by whole-table locking, and make the back-end more pluggable so that we could have distributed hints databases. PPswitch would then act as a cluster with the machines sharing knowledge about other hosts on the net.
    
  • Concurrent DNS lookups during routing, to improve mailing list performance. I've done some work on this already.
    
  • Better handling of double bounces. If we can't deliver a bounce to recipient@domain, try postmaster@domain then postmaster@cam instead of freezing the message.
    
  • Finish the bounce address protection code.
    
• Service integration:
  
  • Kerberos. Proper single-sign-on! Users really hate typing in passwords.
    
  • Raven-authenticated webmail for more single-sign-on.
    
  • Mailing lists generated from Lookup groups. Lookup groups generated from data in CamSIS/CHRIS.
    
  • Web presence: an extension to the chat service which allows other Raven-authenticated sites (such as lookup and webmail) to display a presence icon next to a username. If I am looking at your lookup page and you are on my chat buddy list, then I can see whether you are currently on-line and I can click on the presence icon to chat with you. Depends crucially on transparent single-sign-on. In particular, the default for Raven at the moment is confirmed sign-on, which isn't transparent enough.
    
  • Short URL service, like go.warwick.ac.uk, which doesn't host content but instead redirects to full URLs. Mainly for use on printed material such as business cards, academic papers, posters, press releases, etc. Namespace divided into ~CRSID for homepages (using data from lookup) and ad-hoc names managed by user-admin. Could include societies.
    
• Web stuff, etc.:
  
  • Blogging service.
    
  • Web forums.
    
  • The two could be aspects of the same thing (e.g. Livejournal's blogs and communities).
    
  • Society information in Lookup, similar to the institution information.
    
  • More effective use of talks.cam.ac.uk.
    
  • Shared calendars / meeting manager.
    
• Networking:
  
  • Make it easier for depts and colleges to host conferences. e.g. at the Durham UKUUG I was given a short-term uid which gave me access to their PWF and wifi.
    

Comments

[fanf]

The whole point of Raven is to reduce password promiscuity. Radius would be going in completely the wrong direction. Kerberos support is much better now than it used to be.

[bens_dad]

Reducing the number of times a password is entered is certainly not the whole point of Raven, if that is what "password promiscuity" means. It isn't even a necessary feature of Raven, I can make Raven ask for my password for every site I visit, should I wish.

Sorry, I should have said 802.1x + Radius, which does restrict the applications for which it is a solution, but does mean that, as I understand it and with suitable EAPs, the service provider (web site or access point) doesn't get its hands on the unencrypted password. I'd forgotten that this last point may not be true without dot1x.

[fanf]

No, I mean giving the same password to multiple services. And .1x is network access authentication not application authentication, so it isn't comparable.

[bens_dad]

The way I see it Raven *encourages*, or even forces, sharing of passwords between services.

From best to worst for *technical* security:
1 Every service has a distinct password
2 Every password database has a distinct password
3 The same password appears in multiple password databases

In reality maintaining lots of distinct databases has risks to so 1 may result in more breaches than 2, although the damage from a single breach is much greater in 2.

Raven stops 3, which reduces password promiscuity, but it also stops 1, so it is anti "password monogamy".

Your experience is probably better than mine, so if you think that there is very little monogamy left to protect, Raven is good.
--
My authentication world is more about network access than about applications (although I concede that login *is* an application).

[fanf]

People use the same password all over the place. Building your security model on the assumption that the weakest parts (people) are behaving like security-paranoid geeks is foolish.

The effect of your model is that each person's password is separately transmitted to all places. (This is what I mean by promiscuity.) A security problem in any place compromises all of them. The problem is not just the database: an application compromise can allow password sniffing.

The Kerberos/Raven model is that there is one password which is transmitted to one place. A compromise in any place only compromises that place and does not compromise any passwords, unless the authentication server is compromised.

Furthermore, single-sign-on is attractive to users because they have to log in far less frequently. If more users were aware of the Raven unconfirmed login option, they would use it. People want convenience more than security, so you need to make security convenient if you want to make it popular. This is one reason that ssh took over from telnet: more functionality as well as more security.