tahoe-lafs/trac-2024-07-25

Non-Repudiation Not covered in Integrity #1874

New issue

Closed

opened 2012-11-22 07:00:39 +00:00 by calltodsi · 6 comments

calltodsi commented

2012-11-22 07:00:39 +00:00

Owner

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.

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.

tahoe-lafs added the

labels 2012-11-22 07:00:39 +00:00

tahoe-lafs added this to the 1.11.0 milestone 2012-11-22 07:00:39 +00:00

davidsarah commented

2012-11-22 07:25:02 +00:00

Author

Owner

Duplicate of #1422.

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

Duplicate of #1422. Note that "supercritical" priority is only for things that require an immediate point release.

tahoe-lafs added

major

and removed

supercritical

labels 2012-11-22 07:25:02 +00:00

tahoe-lafs added

code-frontend-cli

duplicate

and removed

code-mutable

labels 2012-11-22 07:28:06 +00:00

tahoe-lafs modified the milestone from 1.11.0 to eventually

2012-11-22 07:28:06 +00:00

davidsarah closed this issue

2012-11-22 07:28:06 +00:00

davidsarah commented

2012-11-22 07:30:50 +00:00

Author

Owner

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 commented

2012-11-22 07:46:32 +00:00

Author

Owner

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

davidsarah commented

2012-11-22 22:47:46 +00:00

Author

Owner

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.

Replying to [calltodsi](/tahoe-lafs/trac-2024-07-25/issues/1874#issuecomment-131918): > 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 commented

2012-11-22 22:51:28 +00:00

Author

Owner

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

tahoe-lafs removed the

duplicate

label 2012-11-22 22:51:48 +00:00

davidsarah reopened this issue

2012-11-22 22:51:48 +00:00

zooko commented

2013-01-04 21:34:29 +00:00

Author

Owner

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.

tahoe-lafs added the

invalid

label 2013-01-04 21:34:29 +00:00

zooko closed this issue

2013-01-04 21:34:29 +00:00