Non-Repudiation Not covered in Integrity

[calltodsi]

I have been testing the LAFS-Tahoe V1.9.2 package. It is observed that during the user/storage-server uploading and downloading(files) processes there is a lack that one critical link missing that is required to track data stored in cloud storage.

Though communication is happening over SSL, a user/server may refuse the sender's/receiver's certificate. So any one of them could be malicious.

Atleast there should be a signed message digest.

So, while uploading a document how a user can trust the Storage Server.

[davidsarah]

Duplicate of #1422.

Note that "supercritical" priority is only for things that require an immediate point release.

[davidsarah]

By the way, the relevant security property here isn't nonrepudiability. That would be the inability for the server to deny that it had performed some operation. SSL/TLS does not provide nonrepudiability.

[calltodsi]

Do You mean that non-repudiability is not the security properties of LAFS? And is it not covered in LAFS?

[davidsarah]

Replying to calltodsi:

Do You mean that non-repudiability is not the security properties of LAFS? And is it not covered in LAFS?

That's right. Are you sure you're not confusing it with another property? Nonrepudiability is normally relevant only for things like contract signing, where a party wants to make a binding commitment that can be verified by anyone who has their public key. I don't think I've seen any storage system that provides it -- although of course you can store signed documents in Tahoe-LAFS.

[davidsarah]

Ah, do you mean how can a client know which servers are in a grid?

[zooko]

I'm not sure what this ticket is about. How about if I close it and then calltodsi can re-open it and say what the is the security property that he wants to ensure, such as "I want to ensure that a client can tell which servers are on the grid." or "I want to ensure that a client only connects to certain servers." or something.