Previous Topic

Next Topic

Book Contents

Book Index

Limitations of the ASx Protocols

When used properly, ASx protocols solve a number of traditionally vexing secure file transfer issues, but they do not solve all problems. Some of the cases that require additional thought and planning are described below.

ASx's "Two-Way Handshake" Does Not Let Receiver Know Sender Got MDN

As described above, properly configured MDNs provide a high degree of non-repudiation. The sender knows that the recipient got his/her file, and the recipient knows that he/she is looking at an exact copy of the original content. However, the recipient never knows for sure whether the sender received or verified a requested MDN.

TCP networking uses a "three-way" handshake to avoid a similar problem. The three handshakes in TCP are:

  1. Client sends a "SYN" to the server to ask for a connection.
  2. Server sends an "ACK" packet back to the client to confirm the connection and also sends an "ACK" to the client to confirm opening the connection.
  3. Client sends an "ACK" back to the server to confirm that the client knows the connection is open.

The ASx protocols specify only two of three possible "handshakes": an ASx file recipient never finds out what the file sender thinks of the MDN the file recipient created. This limitation can lead to several issues:

ASx MDNs Represent Handoffs of Responsibility, Not Fitness

The ASx protocols require that MDNs get sent as soon as an ASx message recipient can decrypt, validate the signature of and verify the contents of a data file.

In other words, after an MDN has been successfully sent, it is now the recipient's sole responsibility to not lose the decrypted file (or at least retain and be able to decrypt the original file at will). If internal processing or delivery errors crop up, they are the file recipient's sole responsibility and MDN technology can not be used to notify the sender about any data file format or content problems.