RE: CBV

On Fri, 2004-05-07 at 01:00, Seth Goodman wrote:
> > 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.

I don't know if I agree with that or not.  Combining the desired
functions of:

 o Asking the sender to verify-this-MAIL-FROM (normal CBV function), in
   a way that is mostly resistant to replay attacks, and works for
   anyone who does simple CBV checks, and
 o Allowing the recipient to verify checksums in a way that is totally
   resistant to replay attacks, but requires the recipient to understand
   how to do the check,

can be done in two separate CBVs as I described.  If they are done
separately, then each of the above two items can be almost perfectly
handled.  (If they are done with one mail-from, you have to make more
tradeoffs in numbers of bits available.)

But having two CBV types would require recipients to pick among separate
CBV checking strategies for each message.  For those who do CBV checks:

  o  If they don't understand this different SES type format, or
     are simply not interested in nonstandard checks:

     o  They'll simply do standard CBVs.

  o  If they do understand this different SES type format and want
     to do the extended checks, then they can:

     o  In your all-in-one CBV suggestion:

        o  Do a standard CBV check at the first RCPT TO:
        o  Reject before DATA if this CBV fails.
        o  Do the checksum test after DATA
        o  Reject if the checkum test fails.

     o  In my dual-CBV suggestion:

        o  Do a standard CBV check at the first RCPT TO:
        o  Reject if the CBV fails.
        o  Generate a checksum-containing MAIL FROM after DATA
        o  Do a second CBV check with this generated MAIL FROM
        o  Reject if this second CBV test fails.

        Note that if you're going to do the second CBV test, there's
        no real need to do the first one.

Now currently, for non-SES messages, CBV is so very effective that no
one in their right mind really wants to wait until after DATA to do the
the test.  You get rid of so many forgeries so quickly there's...well,
there's simply no reason at all to wait until after DATA; the idea is
simply so ridiculous as to be hard to even consider.

But.. let's assume that SES is extremely effective in actual practice. 
That is, let's assume that it's effective enough that forgers are likely
to use/make MAIL FROMs from machines that don't sign their MAIL FROMs
anyway.

Given that assumption, then any addresses that you recognize as
SES-signed are almost certainly valid.  Obviously, you're going to do
CBV checks anyway just to be sure, but unlike the general non-SES
CBV-check case where you'll end up rejecting the vast majority of the
emails after the first RCPT TO:, here the vast majority will presumably
past that first before-DATA check, meaning that for that vast majority
you'll be going through the DATA phase anyway.

So given that situation, (ie given the assumption that you're going to
be getting to the point where you're almost always accepting DATA
anyway), the arguments against DATA-time checks mostly disappear.

So a recipient wanting to do this second CBV test could simply create
the new MAIL FROM based on the DATA received, and do merely that second
CBV then.  (If you're going to do the second one, there's no real need
to do the first one.)

Given two types of callbacks, you get to keep and use more checksum bits
each way, compared to having to have one MAIL FROM that works for
everything.

The one disadvantage with this two-types-of-CBV's is that you don't know
a-priori what the good checksum will be, so you have to wait to
CBV-check that checksum until after DATA.  (You can't do any of the
tests ahead of time.)

So, you call this a complication, which..it is.

I guess my question is what part of the complication is objectionable to
you:

1.  The extra work on the mail server creating a MAIL FROM?

    Our suggestions require equivalent work here.

2.  The extra work on the recipient?

    (Mine is only slightly more complicated, imho.)

3.  The extra work on the mail server checking CBV's?

    (Admittedly, the mail server has to check among two types of 
    validity here.)

4.  The need for multiple CBV's?

    (You really don't need to do more than one CBV for either method.)

(As an aside, both of our schemes are similarly extendable to PKI-based
techniques.)

(I have to say that the need to only do only one CBV even for the
checksumming recipients only recently occurred to me, and it does depend
on the assumption that most SES'd messages are not forged and that
therefore even the pre-DATA CBV tests will mostly all pass for SES'd
messages, but I think that's a very reasonable assumption.)

>
>

[good hashing discussion deleted.]

>   We could really use an
> opinion from a crypto expert here.

We can hash out, (haha), some other more general vulnerabilities first,
but yeah, we do need a real crypto expert at some point.


> 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.

Hmm.  Although I'm still not convinced that single-type-callbacks are
the best way to go...

The fact that only one type of callback will exist does have the expense
of a maximum 23 character local-part, because C27 now can't be
shortened.

Let me suggest that HHHH could still be of variable length.

With a variable-length H, SES-aware recipients would still be able to 
extract C27 and do their checksum tests.

SES and non-SES aware recipients that do CBVs would still do their same
CBVs, unchanged.

On receiving a CBV test, the sending machine would be able to see from
the encapsulated local-part what size HHHH it would have made, so it
could still easily validate incoming CBVs on the fly.

And we'd get the advantage of longer H's when possible.

(Would this still survive SRS rewrites?  I..get confused here.)

Minor issues.

C27:  I don't know if the set of headers you suggest are the optimal
      set to use.  There may be some debate on this.

      (I'd suggest adding Message-Id: and References: .)

H4:  Note of clarification:

     We've been talking as if H4 or H27 has to be an (hmac'd) hash.
     In reality it could be any algorithm, even random numbers generated
     by the server and kept in a database.  If there are vulnerabilities
     found in doing (sha1sum(body+header+secret)), then any SES sender 
     can swap out that algorithm for another completely transparently to
     the receiving machine.

     It's only the meaning of C27 that has to be carved in stone. 

-- 
Mark Shewmaker
[email protected]