RE: CBV

> From: Tony Finch
> Sent: Friday, April 30, 2004 8:03 AM
>
>
> On Fri, 30 Apr 2004, Seth Goodman wrote:
> >
> > Harvesting an SES address does you little good if it contains a hash of
> > the message body and some headers, which your spam won't match.  It's
> > not ideal, in that the MAIL FROM: would be accepted, but the body check
> > based on the hash embedded in MAIL FROM: would fail and you would wind
> > up rejecting the message at the end of DATA (ugh).
>
> In what way is this operationally different from putting the hash in the
> header?

You are right in that logically it belongs with the message content.  I
suggested putting it in the MAIL FROM: specifically to foil replay the
replay attacks that Meng proposed and Wayne provided an exploit method for a
spammer to obtain a signed return path.  By including the body hash inside
the MAIL FROM:, that signed return path would be useless for any message
besides the one you originally sent out.

>
> There isn't enough space for an address signature and a message contents
> hash in the reverse path address. Since it must be possible to validate
> the address reasonably securely in the absence of any other information,
> the message content hash does not help.	The message content
> hash is only
> useful when you have the message content to check it against, so the right
> place to put it is with the message content.


> From: wayne
> Sent: Friday, April 30, 2004 7:56 AM
>
>
> In <[email protected]> Mark
> Shewmaker <[email protected]> writes:
>
> >
> > Could the SES address contain a truncated body checksum?  [...]
> >
> > Even a truncated body checksum could help against that sort of replay
> > attack.
>
> You would have to make sure that you didn't truncate the checksum too
> short.  If a spam has 20 lines in it and you have a 20bit checksum, you
> can create 2^20 variations of the spam by simply adding or deleting a
> space at the end.  Spammers can use to hundreds of thousands of
> trojaned PCs to do this kind of calculation.
>
> Then you also have the problem of things like mailing lists or MS
> Exchange munging the email, thus causing the checksum to fail.

Let me try to address both Tony's and Wayne's questions at the same time.
Wayne's second point is a valid objection about mailing lists breaking
content checks.  This is a real problem today and it breaks any content
check, including S/MIME.  Though something ultimately needs to be done about
this in general, let's assume that nothing changes and we have to deal with
the status quo.  For the purpose at hand, which is preventing a harvested
SES address from being used for spoofing, I will change my proposal and
suggest that we only need to protect the headers, not the body content to
avoid Wayne's valid objection.

In Wayne's exploit of SES, the spammer harvests signed addresses from
responses sent from general sales accounts or other loosely administered
accounts at large sites.  Since this method of exploit is now known, you can
protect yourself against it by limiting the outgoing mail to a single
recipient and include a hash in the MAIL FROM: that protects the same
headers that S/MIME would protect.  Please correct me if I have these wrong,
but I believe that these are To:, cc:, bcc:, From:, Sender: and Date:.  With
a single recipient on the outgoing message and a hash that protects these
headers, the signed return path would only be useful for the spammer to spam
himself.

Wayne's first point was that we couldn't really protect the content with a
checksum.  I certainly agree with that and I proposed a SHA-1 hash rather
than a checksum to fix this.  If we are protecting only headers and not the
message body, I think it becomes an intractable problem to synthesize a
group of headers that generates the same SHA-1 hash as the original message
headers.  Since we would not include the full hash, but the first so many
bits of it, we don't have the full security provided by SHA-1, but remember
that the signed return path includes a timestamp and it will expire in a
week or two.  If we make the header-protecting hash long enough, that will
not be enough time to produce another set of headers that match the same
hash.

This leads to Tony's objection that there is not enough space in the return
path for an extra hash.  The recipient does have to verify it without any
additional information, but that doesn't mean it has to take up a lot of
space.  The header protecting hash can simply be a SHA-1 hash of the header
lines using no hash secret.  An SES return path is shorter than an SRS
return path, so there is some extra space to work with.  Here is one
possible SES address format for everyone to throw darts at that I think may
satisfy the requirements.

SES0=HHHH=TT=hhhh=local-part@domain

where
   HHHH = first four base 64 digits of the
          SHA-1 hash of the remainder of the
          address prepended with the hash
          secret (MSA login password) for
          local-part@domain

   TT   = first two base 32 digits of the UNIX
          integer day number mod 1024 (same as SRS)

   hhhh = first four base 64 digits of the
          SHA-1 hash of the specified header
          lines

This local-part of this address format requires 18 characters in addition to
user's local-part.  This means that the user's local-part can be 46
characters without breaking the 64-charachter local-part limit.  When a
recipient gets a message with this MAIL FROM:, they do a CBV to the MX for
"domain" to verify it.  If it verifies, that tells you the header protecting
hash is valid.  You then go on to the DATA phase and calculate the SHA-1
hash of the specified header lines.  If that does not match with the header
protecting hash in MAIL FROM:, you know this is a forgery and you can reject
it at the end of DATA.  Since the sender of such a spoof knows that their
message will likely be rejected, trying to use this exploit would be just as
successful as forging mail from a domain that publishes an SPF record.  Both
would likely fail and neither would be a particularly usable exploit.

If we want to use the header protecting hash as a unique message ID, it will
have to be longer.  Let's say a given mailer sends out 16 million messages
per day.  That is 2^24, and considering the birthday bound, you would need
about 48 bits of hash to avoid a collision in a single day's message
traffic.  That amounts to eight base 64 characters instead of four, which
reduces the maximum local-part length from 46 to 42 characters before
breaking the 64-character local-part limit.

--

Seth Goodman