This question can be rephrased as: Is there a situation in which the attacker can compromise TLS, but not additional encryption? The answer lies in the implementation of either system.
The API will be using the HTTPS protocol, but management thinks that is not sufficient and that we need to encrypt the data itself before it is sent.
Management always seems to think that more is better, but you have to think about where the keys are in order to develop a threat model. Are the servers which have the data the same servers that are establishing the TLS connection? If so, then encrypting it before being sent would provide no benefit, since a compromise of those servers would simultaneously provide both encryption keys.
Is SSL/TLS sufficient for safe transit of the file?
Assuming it is properly configured, it is safe and sufficient. You want to select a secure cipher suite. There are online guides for selecting a good TLS suite. For an internal API, not all of this is needed, as you can act as your own CA safely.
Does HTTPS/SSL protect binary data or just plain text?
In the HTTP protocol, the only thing that hints at the type of data is the
Content-Type header. This header tells the end application how to interpret what it receives. TLS operates on a layer above that, and as such the encoding is irrelevant. It blindly encrypts all data, including headers.
Does the length of time that it will take to transfer a file of that size pose additional security risks over plain text?
The amount of time it takes to transfer data over TLS does not impact its security. No modern cipher is going to weaken just because you are encrypting a large amount of data. TLS is fast enough that, on all but the oldest hardware, it will perform equally well as a plain connection.
Is the concern with the additional layer of encryption justified?
Assuming your network topography is such that TLS will provide end-to-end encryption, then no, there is no justification for additional crypto. The added complexity may introduce bugs. If you control both servers, you can use a self-signed certificate and verify the fingerprint, so you do not need to rely on a CA for authentication.
In other words, the only time that it would not be sufficient is if any of the following is true:
- There is a weakness in the design or implementation of TLS.
- A feature you require is not present in TLS.
- There is a situation where an attacker can obtain the TLS key without obtaining the other key.
If none of these are true, then TLS will provide three primary guarantees:
- Authentication - You can be sure that the connection on the other end is who they say they are.
- Integrity - In-transit data cannot be modified without the other end being aware of it.
- Confidentiality - All traffic will only be readable to intended parties.
Extra encryption using GnuPG for example will provide no additional guarantees.