On Tue, 10 Feb 2004, wayne wrote:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)53(_dot_)0402110051270(_dot_)29116(_at_)astray(_dot_)com>
Shevek <spf(_at_)anarres(_dot_)org> writes:
I hope that this resolves any outstanding questions[0]. I await with
trepidation the comnents of the community[1].
It appears that you are using base64 to encode stuff and putting in
the local part. Base64 uses both upper and lower case characters. If
I recall correctly, the local part is supposed to be case sensitive,
but in practice, there are systems that change the case of letters in
it. IBM mainframes come to mind, but I suspect there are others.
Can you really get away with using mixed cases in practice?
Hm. This is an interesting point. I have borne it in mind that the prefix
SRS0 is case insensitive. I don't _think_ it would weaken the system if we
did the entire hash validation in lowercase. Certainly not compared to
cutting the hash length. I will ask our crypto group today.
As Daniel Roethlisberger points out, you really don't need a complete
MD5 hash. My gut feel is that even 16 bits of the hash would prevent
any useful spoofing of the SRS system, and I think it would be very
useful to calculate a lower bound. Then, you can use base32 encoding
or something more resilient to strange MTA manglings.
I agree. This has also been under discussion. I am thinking to allow any
prefix of the hash. Actually, the only requirement on the hash is that it
be a single +-separated token. The reason I didn't bring this up before is
that today I'm going to ask our crypto group for their opinions, after
which I will know The Answer(tm).
What each host MUST do is to set a minimum security level for the hash.
Say we're case insensitive and permit something as short as 1 character.
Now a spammer need only fake 34 emails.
I will update the spec tonight (UK time) and release new versions of code
and documentation addressing these concerns.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/