Encrypt at which level?


Mike Muuss (mike@BRL.ARPA)
Mon, 7 Apr 86 20:03:10 EST


Mike Padlipsky asked why I thought Level 6 was the right place to implement
encryption, and even though my answer is sketchy, I figured I'd share it
with everybody.

It seems to me that code translation, e2e encryption, and some sort of
standard data compression ought to be available as "protocol family"
services to *any* application, just for the asking. At the right point in
the dialog (perhaps before the first data byte, perhaps after some initial
exchange), the user program should make some kind of call to the next lower
level interface and say "please begin encrypting with a key of XXX".

The exact implementation point of e2e encryption isn't REALLY important
though, as long as a good place for it in the protocol suite exists, and
most everybody can be made to agree to do it there. It could be provided by
a library function, or as direct code within each application, or as an
operating system capability, I dont really care, but I feel that some basic
level of encryption should be available as a primitive capability.

It would be nice, for example, to consider an extention to the SMTP protocol
to go something like:

220 brl-sem Server SMTP (Complaints/bugs to: mmdf@brl.arpa)
HELO brl-sem
250 brl-sem
CRYPT
250 encryption with our common key being enabled.
MAIL FROM:<MAIL FROM:<mike@brl-sem>
250 OK

and thus have both the address and data portion encrypted (as an option).

TELNET IAC-DO-ENCRYPT etc etc might also be nice.

Government sites handling what used to be called "For Official Use Only
(FOUO)" data and researchers with unpublished data to exchange would
be the most likely candidates to desire this type of capability.

The key management issues would be a drag. Host-pair, Group-pair, User-pair
basis, or what? How to update? What to do when the keys don't match?
Handling the user interface issues would also take thought and work, but
encryption is something that WOULD be useful to have.

How this fits together with Multi-Level Secure hosts interfacing to
BLACKER isn't clear either. The simple answer is: "not at all -- BLACKER
is different", yet having BLACKERs protecting gateways to LANs *still*
does not handle the complete end-to-end requirement. BLACKERs
protecting hosts would. I need to think about this more.

        -Mike



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:05 GMT