RE: CBV

On Thu, 6 May 2004, Mark Shewmaker wrote:
>
> 1.  Imagine an SES-enabled MTA sends out emails with the following
>     mail_from format, slightly different from the above:
>
>     SES0=H27=T4=L27=local-part@domain
>
>     Or:
>
>     SES0=   Unchanged.
>     H27=    A 27-character base-64 representation of all 160 sha1
>             bits of all of the following:  ("SES0", local secret,
>             T4, C27, local-part@domain).

Note that this simple form of hash is not as safe as you might expect. I'm
told by a security expert: "MD5 and SHA-1 output an intermediate value of
their computation from which a hash of the original string plus an
extension can be calculated. They can therefore not be used safely to
calculate a MAC as h(key, string), hence HMAC." So we should use RFC2104
hashes.

>     But we're not supposed to make local-parts that are larger than
>     64 characters, and we can't exactly say that the included local-part
>     has to be shorter than negative two characters long.
>
>     So, change the format definition again and say that in making a new
>     mail_from of the format SES0=H27=T4=L27=local-part@domain, that
>     the H, T, and L components can be made using "up to" 27, 4, and 27
>     characters.
>
>     So, the SES sender will truncate H, T, and L such that the total
>     new local-part doesn't exceed 64 characters in length.

I like this idea! Thanks.

>     Note that as a protection against replay attacks, the sending
>     machine could note how many CBVs it's recently been requested to
>     do for any particular T, L, and local-part@domain combination,
>     perhaps slowing down the response to CBVs with that combination
>     after a time, perhaps even invalidating that combination after
>     some threshold of number/timing of CBVs have been made.
>
>     This protection against replay attacks requires a database
>     of sorts for the MX machines, but it can be pretty ephemeral,
>     keeping stat info that ages out for instance.  That would
>     protect against replay attacks of a million copies of the same
>     mail_from within a half-hour interval, but not replay attacks
>     of large numbers of separately harvested mail_froms.
>
>     A more extensive database, keeping track of the number of
>     recipients for any T, L, local-part@domain combination can
>     help tune the triggering of CBV-response slowdown and lockouts.

This information could be held in the signed sender address.

> 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

I'm currently inclined to use a special signed address in the message
header for message data integrity checks, so that the envelope sender
address is not encumbered with a second hash. The message data hash in
this address can cover all the relevant data needed to prevent attacks
that replay only part of the message header, body, or envelope. So I don't
see any advantage to putting the MDH in the envelope to compensate for
the length disadvantage.

> 5.  Since I didn't specify that CBV checks from (3) or (4) have
>     any different format, the Sending machine has to potentially
>     do two tests

I'm specifying a naming system for signed sender addresses that's easily
extensible, so that this kind of confusion can be avoided.

-- 
Tony Finch  <[email protected]>  http://dotat.at/