RE: CBV

> From: Mark Shewmaker
> Sent: Saturday, May 15, 2004 12:46 PM
>
>
> 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.)

A new idea to foil replay attacks was introduced more recently by Stuart
Gathman.  Basically, his idea was to associate a MAIL FROM: with a given set
of RCPT TO: addresses.  This would limit the replay attack to the same
address that harvested the return path, making the replay attack useless.
This makes it unnecessary to include a body check and also makes it possible
to detect the replay attack before DATA, which is what we really want.  It
is possible to use an extended precision timestamp as the database key and
it still works with one CBV.  See my next post in this thread for details.
I think this beats our solution, but maybe not.

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

Except that it requires you to download the whole message, including
attachments.

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

Agreed.

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

That would be great.

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

If the spammers are aware that it is pointless to forge an SES return path,
why do you think they would be any more willing to forge anything else that
could be detected by the same protocol?  Either a site implements SES or it
doesn't, no?

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

Well, the after-DATA checks kind of made SES look like a watered-down PKI
scheme, which made all of us a little twitchy, yourself included, if I
recall.  I included the body check scheme in my next post which lists the
current SES variations, but I think that Stuart's RCPT TO: idea makes it
possible to foil the replay attack before DATA, so I think that one is the
best so far.

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

Responding to the second CBV is extra work and bandwidth for the domain MX.

>
> 2.  The extra work on the recipient?
>
>     (Mine is only slightly more complicated, imho.)

Doing a second CBV is extra work and bandwidth for the recipient MTA.

>
> 3.  The extra work on the mail server checking CBV's?
>
>     (Admittedly, the mail server has to check among two types of
>     validity here.)

This isn't so bad, and you do get extra information for your work.

>
> 4.  The need for multiple CBV's?
>
>     (You really don't need to do more than one CBV for either method.)

This is the main objection that I would have.  It may not bother some people
as much, but it has been hard to get some people to accept CBV's at all.

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

It can.  It's only a minor complication.

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

I can't think of any reason that it wouldn't.  SRS should be able to
encapsulate any valid address and the final gateway MTA should be able to
unencapsulate it after any number of forwarding hops.

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

Exactly.  No one but the sender needs to be able to evaluate it.

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

Yes, and even that could be changed if future developments in the crypto
world make a SHA-1 MAC insecure.

--

Seth Goodman