% fortune -ae paul murphy

Domino, cryptology, and response

As regular readers know I like the Domino based e-communications infrastructure a lot - mostly because it does most of what the manual says it does and you really can load it up, run some basic tests to make sure it's right, and then leave it alone until the next upgrade.

One former client, for example, put up 8.0.1 in May of this year, had their Lotus wizard poached in June, and is only now becoming concerned that maybe somebody should be checking on patch or upgrade requirements - and the issue only came to anyone's attention because consultants hired by the larger organization within which which they function are apparently trying to "strategize" the use of Sun's "netlet" client applet to support client to client communication among the higher level organization's mobile computing users.

My friends think, as I'm inclined to, that this is really part of a move to reduce their IT independence by pushing through an organization-wide SameTime implementation and a larger role for the central data processing group paying the consultant's bills; but, organizational politics aside, the discussion brought some odd and unexpected things to light.

The odd thing is this: because the 8.0.1 release was the first to meet the U.S. FIPS (Federal Information Processing Standards) 140-2 standard for e-mail encryption other than for client to client communications, nobody paid attention to built in crytographics when Domino was first installed - and no one's updated the configuration for this since, not even the guy who did the upgrade in May.

The consultants suggesting that the group's domino services move to the central system also suggest that the move be paid for through chargebacks to user groups - but wouldn't say what the IBM cryptology boards would cost or how well they would work. Their "trust us" attitude infuriated some of their targets and, I think, ultimately reflected an unshared assuption: that whatever IBM offered would be the cheapest and fastest possible.

There are comparable accellerators available for the old SPARC gear Domino runs on now, but the unexpected thing was that no one had told them that the T5220s they've been tire kicking have a hidden feature: chip level hardware cryptology support.

The value is this: on a T5220 with the default Solaris 10 configuration, turning on two way encryption in the Domino configuration has no obvious effect on server performance - it does affect PC clients; apparently slowdowns can be significant.

I think the key reason no one has worried about this in the past is that the internal users are on Sun Rays or X-terminals and so cryptology was considered a network function. Now, however, there's presure to do something more to suppport secured external communications and so we get this proposal -or so we're told. Personally I don't think we can tell the cart from the horse here in the sense that the need to sell further communications centralization could just as easily have triggered the sudden criticality of external cryptographic communications support.

So how will this settle out? It's too early to know, and the central group will doubtless continue to push its position - but as more and more people become aware of the hidden cryptology power in the coolthreads line people are going to figure out that the T5220s cost - complete, installed, and ready to work - rather less than the cryptology accellerators for the z10.

And that fact leads to the bottom line: it would almost be worth traveling to the organization's head office just to see whether data processing's consultants can actually argue their case with a straight face.


Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 25-year veteran of the I.T. consulting industry, specializing in Unix and Unix-related management issues.