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 file recipients must retain MDNs of any ASx message that requested one unless the recipient can absolutely not deliver the MDN.
• "Duplicate posts" are possible if an ASx sender is set to resend files until a valid MDN is received and an ASx recipient believes that it has successfully posted a valid MDN back to a sender's server.

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.

ASx Protocols Do Not Provide the AES Encryption Algorithm

The encryption ASx provides is essentially a tightly defined subset of SMIME. Unfortunately, one of the encryption algorithms left out of the specification was AES, the latest symmetric encryption algorithm approved by the federal government. In other words, the only FIPS-validated encryption algorithm ASx products can provide when encrypting or decrypting ASx messages is "triple-DES" (3DES), and the highest number of encryption bits available will be 168 (not AES's 256).