[messaging] Provable (private) conversation while allowing (somewhat) precise redaction

Dave Crocker dhc at dcrocker.net
Thu Oct 9 19:10:04 PDT 2014


On 10/9/2014 6:49 PM, Tamme Schichler wrote:
> The requirement isn't exactly "hard", it would technically be enough to
> display a very clear warning if no proof arrives for one of the messages.

Again, interesting.

One of the odd challenges for doing security mechanisms for 'everyday'
use -- that is, usage that is not part of military or national security
-- is that it can be ok to make things less rigorous, if it makes it
more broadly usable.


> I'd prefer to require it for protocol compatibility though, which should
> be possible by making the protocol sequential. 

Compatibility with what?


(It still wouldn't be
> simultaneous, but new messages couldn't be sent before receipts for the
> previous ones. Group conversations would be fairly unstable with the
> simplest implementation though.
> 
> Maybe having the latter isn't that important for this protocol though,
> since then there would be witnesses in the first place... or not.

One of the fun aspects of conversation is that a reply can implicitly
(or even explicitly) constitute an acknowledgement of receipt for the
predecessor message.


>> http://security.stackexchange.com/questions/29550/recipient-non-repudiation-in-secure-e-mail-transport
>>
> 
> I think this part of the accepted answer sums it up nicely:
> 
> | Summary
> |
> | This is a hard problem for which no solution exists yet; the
> | technical tools are ready (e.g. asymmetric signature algorithms), but
> | it also needs some infrastructure which will need official support,
> | will be expensive, and won't be of any use until is has become so
> | important that it cannot be ignored. This looks like a problem which
> | will not be solved any time soon.
> 
> Implementing non-repudiation for conversations may be a lot easier
> though, since what must be proven is not that a message was received but
> what something was in reply to.

In terms of email constructs, perhaps enhance the In-Reply-To header
field to include a protected hash of the message that's being replied to?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net


More information about the Messaging mailing list