RE: CBV

On Thu, 2004-05-06 at 22:36, Seth Goodman wrote:
> > From: Mark Shewmaker
> > Sent: Thursday, May 06, 2004 6:04 AM

[Deleting a lot of stuff on how and where we're in agreement, (very well
worded stuff, btw, helpful for people following along in the archives
later.)]

> Computing
> the outer hash that protects the MAIL FROM: requires knowing the hash
> secret.  Unless you can crack that, you can't verify that a modified address
> string will produce the correct outer hash value.  Therefore, the outer hash
> length only has to be long enough to prevent cracking the hash secret.

I would note that it's harder for an attacker to find valid
inner-hash/outer-hash pairs than to simply figure out a valid inner
pair, because while doing a brute force test of an inner hash is a
cpu-bound activity that can be done entirely on the attacker's machines
in a couple milliseconds, checking to see if any particular inner/outer
pair matches Because checking to see if a forged header/body matches
requires a CBV test--far more expensive in terms of clock-time, and
detectable by the server.

> >     For completeness:
> >
> >     B27=    A 27-character base-64 representation of all 160 sha1
> >             bits of all of the following ("SES0", TT,
> >             local-part@domain, message body.)
> >
> >             Note that C27 is not included in this mail_from, but
> >             it is included in the computation of H27.
> 
> I assume that B27 above was a typo and you meant C27.

Basically yes, or rather they're the same.

I messed up with editing my response to you there.  Before sending it
out, I figured 'B' for "body (more or less) checksum" might be easier to
follow along than using a generic 'C' for "checksum", but proceeded to
change only some of the C's to B's.  Oops!

> As I've argued above, the outer hash doesn't need to be 160-bits long.
> Since the attacker would need the hash secret to check possible new return
> paths, the outer hash only needs to be long enough to prevent cracking the
> hash secret.  Shevek did look into this and suggested 24-bits as adequate.
> Therefore, I suggest that we stay with a 24-bit outer hash.

I am not at all confident that that is a good idea.

24 bits gives just 16 million combinations.

Since the end verification takes place on the server, an attacker would
have to present ~8 million combinations to expect a 50% chance of
getting making a match by chance.

We can detect that many attempts. :-)

However, with that small an outer hash, validation might become possible
without contacting the server because an attacker will have many valid
mail_froms to look at.

(We should assume a dedicated attacker can  collect many valid MAIL
FROMs for any given inner-local-part, hundreds, thousands maybe.  It's
not unrealistic to think this--places that send enormous amounts of
emails for constant local-parts are the very places most valuable for an
attacker to focus on.)

While having many valid H27=sha1(rest_of_mail_from+secret)'s from many
different mail_froms might result in the secret being hard to compute
when sha1 outputs 160bit, the secret may not be as hard to find when the
output is truncated to 24 bits.

I worry that
truncated_to_24_bits(H27=sha1sum(rest_of_mail_from+secret_1)) is
equivalent to simpler_hash(rest_of_mail_from+secret_2), in which secret
is much easier to find and vulnerable to a known plaintext attack.  In
fact, I would also worry that there could be *many* potential secret_2's
for any secret_1.

If, let's say, an attacker can collect 4000 good mail_froms from a
single day, then he'll have 1/4000 of the whole problem space to study,
(4k/16M=1/4k), which I think is a conveniently large percentage to have
at hand for a known plaintext attack.

So if there's no reason to keep HHHH at 4 characters, I'd suggest making
it of variable length.

> Next let's consider the timestamp.  The timestamp has two possible
> functions:  to date the signed return path so it can be expired and to act
> as a salt for the outer hash.  For the purpose of expiring the timestamp,
> all we really need is resolution in days.  Once we add an inner hash, there
> is no longer a need to salt the outer hash calculation.  Therefore, I
> suggest that we stay with two base-32 digits with one day resolution.

I can grudgingly accept that logic.  I would suggest that while a two
digit timestamp seems sufficient, that there is still no need for SES to
nail it down to two digits as a requirement.

If we later find that there is a need for sub-second timestamps here,
(doubtful), and servers start using T6's, recipients parsing the SES
format should be required to still deal with such a longer T.

(Or SES sending machines might have other reasons to later overload the
T field by adding in another character of information.  There's no need
to cut off that possibility.)

-- 
Mark Shewmaker
[email protected]