Daniel S explains what is needed to provide repudiation for file downloads, so I'll explain why you cannot prove a file was downloaded in the typical situation when using regular TLS.
When a server establishes a TLS session with a client, a master secret is exchanged. This secret is used to derive a key that is used for encryption as well as a key used for integrity. To provide integrity, the encrypted data is hashed using an algorithm called a MAC. Unlike most cryptographic hashes, a MAC hash is keyed. Even for the same message, the digest will be different if the key is different.
Before data is transmitted, the MAC is keyed and is used to hash the ciphertext. The hash is then transmitted along with the ciphertextasciphertext as a tag. The receiver then uses the same MAC key to hash the ciphertext it receives and compares it against the tag. If it differs, the data may have been tampered with and the session will be torn down.
Even though you, as the client, know the master secret and thus also the MAC key, you cannot prove to anyone that the session that you have recorded is legitimate even if you also prove that the master secret itself is legitimate. This is because you could change the data and re-hash it with the MAC without ever calling into question the authenticity of the master secret. At most, you could prove that a given handshake occurred and that it was authentic, but you can't prove what happened afterwards.
See also Does a trace of SSL packets provide a proof of data authenticity?.