RE: CBV

> From: Mark Shewmaker
> Sent: Thursday, May 06, 2004 6:04 AM
>
>

Rereading your message, it looks like I misunderstood your proposal quite a
bit.  I didn't notice that both of your hashes in MAIL FROM: used the local
secret.  I also didn't really understand the subtleties of the two kinds of
CBV's.

Now that I understand it better, I think that the two forms of CBV's are a
complication that would be nice to avoid, if we can.


> 3.  Recipients who do simple CBVs will submit this
>
>     SES0=H27=T4=L27=local-part@domain
>
>     for validation.
>
>     In other words, they're submitting for CBV the same mail_from
>     line they received.
>
>     The sending-machine can look at the local-part and its policy,
>     and figure the needed lengths of H, T, and L, and figure out
>     whether the CBV's given local-part@domain and T match up with
>     its given L, *ignoring H27 altogether*.

This simple CBV form only verifies the return-path and therefore is
susceptible to replay attacks, as you pointed out.


> 4.  Recipients who are willing to do body checks can submit an
>     alternative mail_from of the format:
>
>     SES0=H27=T4=B27=local-part@domain
>
>     This is the same as the mail_from that the sender sent,
>     except the L section is replaced with the body checksum B.

This form of CBV is immune to replay attacks, but it can only be done after
receipt of the entire message because we nee the body hash for the CBV.
This takes away the ability to reject a lot of forgeries before DATA.

The alternate address formats I described include a body hash, so it ties
the MAIL FROM: to a particular message while still allowing the CBV to
happen before DATA.  This will tell you if the MAIL FROM: appears to have
originated from the MTA you are doing the CBV on.  If you choose, you can do
the body check and reject the message at the end of DATA if it does not
pass.  However, whether or not the recipient does the body check, the CBV is
always done before DATA and it is always done the same way.  This simplifies
the protocol for both ends.

I realized a couple of things about my alternative proposals after rereading
your message.  First, I realized that there is really no need for the
X-Content-Hash: header in the short inner hash version.  The body hash can
be calculated on-the-fly, just as you do it.  Thanks for another great idea!

However, I'm still bothered by the short inner hash that I proposed and
think I probably erred on this one.  One way to think about it is that the
full SHA-1 body hash maps the universe of all possible messages randomly
into a 160-bit number.  Rehashing that number and taking the first 24-bits,
assuming really good hash properties, randomly maps all possible 160-bit
numbers into a 24-bit number.  Since both hashes are good randomizers, I
_think_ this is roughly equivalent to mapping the universe of all possible
messages randomly into a 24-bit number and the 160-bit intermediate hash
becomes irrelevant.  I'm not at all sure about that, but if it is indeed the
case, then the vulnerability you first pointed out still exists and the
short hash can be beaten.  In that case, we would need to go back to a long
inner hash to properly protect the message content.  We could really use an
opinion from a crypto expert here.

Here's a slightly modified long inner hash SES address format:

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

where

   HHHH = first four base-64 digits of the SHA-1
          hash of "C27=TT=local-part@domain"
          prepended with the hash secret
          (MSA login ID + password) for
          local-part@domain

   C27  = 27 base-64 digits comprising the SHA-1
          hash of the concatenation of the From:,
          Sender:, Reply-To:, Date: and Subject:
          headers plus the unencoded message body

   TT   = first two base-32 digits of the UNIX
          integer day number mod 1024


This is longer than what I'd prefer, but it should be very secure.  The
outer hash is protected by the hash secret and the inner hash is too long to
brute force a forgery.  This version gives us 23 characters for "local-part"
before exceeding the 64-byte limit.  All CBV's are done the same way.  The
body hash in the envelope sender address ties this address to the message
content and replay attacks are not feasible.  Any of these address formats
would survive rewriting by SRS.

--

Seth Goodman