crypto flaw in secure mail standards

[John Kelsey]

At 11:51 AM 6/23/01 -0400, Jeffrey I. Schiller wrote:
>On Fri, Jun 22, 2001 at 06:23:46PM -0400, Radia Perlman - Boston Center for 
>Networking wrote:
>> Actually I don't think Don was talking about that. Instead he was
>> talking about the danger of leaving things out of the
>> signature like the subject
>> line, the to field, the date, etc., that would allow someone to
>> take Alice's message out of context, and other people on the list
>> have explained that you need to have all stuff that matters be
>> covered by the signature, perhaps by having the user consciously
>> know what matters and include it in the body.
>
>Ah. This is why I always replicate the Subject field (and other important)
>fields in message that I sign for posterity (such as IESG action requests).

Basically, Don's attack amounts to showing that you can't safely use
PGP-signed or SMIME-signed messages by themselves to make a secure protocol
for contract signing.  It's a good thing to point out, but the basic
problem is hardly new--everyone knows that you can't, in general, make a
protocol between two machines secure when each signs their messages, but
neither includes anything to prevent cut-and-paste or replay attacks.  Now,
the specifics of how and whether the attack works depend on the details of
the messages--if each party quotes the whole of the previous message in
each new message, the attack will fail.  If each party sticks a timestamp
into the body of the message, some but not all attacks will fail.  (We
still fall prey to the interleaving attack, where Alice runs the
contract-signing by e-mail protocol with Bob and Charlie at the same time,
and Bob gets a signature on a statement "It's a deal!", and then gives that
to Charlie to claim that Alice said the same thing to him.

Also, note that anyone who understands what assurances the crypto can and
cannot provide here will not end up convinced that Alice intended to sign a
contract, they will end up convinced that they haven't enough evidence to
decide whether Alice intended to sign a contract.  (Unfortunately, there's
not much reason to expect a judge to know a lot about cryptography, so who
knows how this would really play out in court?)

It's easy enough to fix in various ways, by making the sequence of messages
between Alice and Bob part of a cryptographic protocol--make up a unique
session ID for this conversation, make sure Alice and Bob agree on it, and
then include that plus a message sequence number in each successive message
in the conversation.  Or whenever an e-mail is replying to an earlier
e-mail, include the SHA1 hash of the replied-to e-mail in this e-mail's
signature.  But none of that fixes the underlying problem, which is that
secure and signed e-mail is fundamentally a different thing that a
contract-signing protocol.

>			-Jeff
>
--John Kelsey, kelsey.j at ix.netcom.com



---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com