The concept of "receipts" for email messages is one that is certainly used in
various environments with varying degrees of protection for the parties. I am
not convinced that any existing system currently implements receipt capability
with the "strongest" level of protection for both the sender and recipient.
That
strong level can be described as:
Alice wants to send message, M, to Bob. She wants to get a receipt proving
that
Bob received M from Alice. She does not want Bob to see or read M before she
is
capable of having the receipt. Bob wants to make sure that if he signs a
receipt, that Alice will let him see the message M. In otherwords, the system
must make it possible for Alice to receive the receipt at the same time that
Bob received the message. Both parties are protected from the other cheating.
This is possible and is discussed in depth in "Certified Electronic Mail" by
Professor Doug Tygar and myself presented at ISOC 94. (see www.eit.com/~ali)
This capability is very useful especially in electronic commerce.
I've read your paper and I must confess that I don't see what the problem is.
First of all, your paper describes two ways of doing this: B-CEM and S-CEM.
S-CEM is one of the so-called "baby step" methods and hence not well suited
to email. I therefore conclude that B-CEM is the method you're proposing
for use in email.
B-CEM makes use of a trusted third party (TP). The core protocol seems simple
enough: (1) A sends M to the TP. (2) The TP encrypts M with a random encryption
key E and sends the encrypted result EM to B. (3) B sends back a signed receipt
acknowledging the receipt of EM to the TP. (4) The TP sends E to B, thus
effectively providing B with M. (5) The TP sends back B's signature of EM and E
to A as proof that B actually got the message and signed for it.
I've ignored various signatures and at least one encryption needed to verify
the parties to each other and to protect the message at various stages, but I
think this presents the parts of this scheme that are relevant to the topic at
hand. (These details are covered quite thoroughly in the paper.)
I see nothing that cannot be implemented using existing protocols as building
blocks. All you need are signature services, encryption services, receipt
notification services, and the ability to combine them all in arbitrary ways.
We have all of this already. Its true that there isn't any specific support for
this model in security multiparts or in the receipts work, but there is no need
for specific support.
We don't provide specific support for trusted third parties, for that matter,
because there is generally no need to provide for such things in on-wire
protocols. Third parties are defined by message routing and the specific keys
and signatures used, not by the encapsulation or security services themselves.
(Actually it would help a lot to have a definitive form for a time-stamp used
by notary services, but that's not relevant here.)
I believe the central issue here is to see security multiparts for what they
are: Building blocks used to construct various useful services rather than
complete services in their own right. While it is true that simple application
of each of the individual building blocks leads to a useful service, this
doesn't mean that the only way these building blocks can be used is by
themselves between only two parties. All sorts of combinations are possible,
and I suspect we've yet to come up with many if not most of the important ones.
In the strongest system, MSP, I believe it is possible for the recipient to
read
the message before signing the receipt. This implies that the message is
available in cleartext in the system and if the recipient finds a way to
bypass
the UA, they could read the message without generating a receipt. (Steve,
please correct me. I had a copy of MSP but since I moved, I would be
interested
to have a pointer again...)
Actually, if what Steve says is correct (and I have no reason to believe it
isn't) there may be a problem implementing your protocol on top of MSP.
Specifically, Steve said that MSP returns signatures over decrypted messages in
its receipt function. If this is always the case, this scheme won't work
because it calls for a receipt to be computed over material that is still
encrypted. In fact it isn't possible to decrypt until after the receipt is
received and the encryption key is sent back by the TP.
The IETF receipt working group is deliberately not going to address "strong"
receipt capability. It can be called a simple receipt notification capability
similar to the delivery notification. As I recall from the last meeting, the
recipient has the option to not generate the receipt at all, even after
reading
the message! One easy way for Unix users to do this is: cat
/usr/spool/mail/xyz
There really isn't any need for them to address it. All they are providing is a
building block for you to use. They aren't saying how it can be used -- it has
a direct and obvious application but nothing prevents it from being used in
more complex applications, yours included. You can sign a receipt and have
proof of delivery services, for example. Of you can use it as part of a scheme
like yours to provide a more sophisticated service.
As for return of receipts being optional, this is not a problem when receipts
are used simply as a component in your scheme. B may elect not to send a
receipt back to the TP. But then B never gets the encryption key and is left
holding a bunch a useless encrypted garbage. So B gets nothing for nothing.
Where's the problem in this?
In conclusion, I caution the reader that just because someone claims they have
do "receipt", it does not mean that they do it "all"...
I disagree. I see no reason why your scheme cannot be implemented with the
building blocks we have now. See above.
One final note. I'm not convinced that your scheme actually provides the
service you claim it does. Specifically, you stated that:
She wants to get a receipt proving that Bob received M from Alice.
and that:
Both parties are protected from the other cheating.
I don't think this is actually the case. Suppose the entire process runs to
completion without any apparent problems. A now asks B to pay for the material
B received. B then claims that he received EM all right, sent the signed
receipt to TP, but then never received E. B further claims that he got tired of
waiting for E to arrive and bought the material from someone else, and that he
now has no intention of paying for the material twice.
I don't see any way of proving that B is lying here. In fact B may not be lying
at all -- it is actually quite possible that B is telling the truth. You may
argue that in some cases A is the sole provider of M and B's possession of M
constitutes proof that he really did receive E. But it should not be necessary
to rely on such considerations if the protocol really delivers what it says it
does.
The underlying technical issue here is that the receipt that A receives
actually says nothing about B receiving M -- all it says is that B received EM.
And these are not the same thing at all -- EM is useless without E, and the
protocol cannot prove that B ever received E.
I hope I've missed something here, but if I haven't I think this pretty much
blows B-CEM out of the water, as least as far as time-critical material and
material available from multiple sources are concerned. As for S-CEM, I don't
think it has any comparable problem, but I do think it will have the usual set
of problems "baby step" protocols have when the two parties either have
considerably different amounts computational power available to them or when
temporal concerns are paramount. (The fact that the protocol insures that one
party has at most a 2:1 computational advantage is meaningless when one of them
only has an Apple ][ and the other a high-end multiprocessor Alpha.) Anyone who
is interested in these protocols should see page 121 of Applied Cryptography
2nd Edition by Bruce Schneier (red cover, blue is 1st edition) for a discussion
of these issues.
Ned