You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Marc Perkel <su...@junkemailfilter.com> on 2010/12/14 15:28:54 UTC
DNSBL for email addresses?
Are there any DNSBLs out there based on email addresses? Since you can't
use an @ in a DNS lookup - how would you do DNSBL on email addresses? Is
there a standard?
--
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400
Re: DNSBL for email addresses?
Posted by Benny Pedersen <me...@junc.org>.
On tir 14 dec 2010 15:28:54 CET, Marc Perkel wrote
> Are there any DNSBLs out there based on email addresses? Since you
> can't use an @ in a DNS lookup - how would you do DNSBL on email
> addresses? Is there a standard?
no std, but there was a test with emailbl, google it
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: DNSBL for email addresses?
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Tue, 14 Dec 2010, Marc Perkel wrote:
> Are there any DNSBLs out there based on email addresses? Since you can't
> use an @ in a DNS lookup - how would you do DNSBL on email addresses? Is
> there a standard?
>
Why do you say "Since you can't use an @ in a DNS lookup"??
Unless you're using obsolete software there's no reason you cannot.
EG:
% nslookup 'acc@khath.com.phish.icaen.uiowa.edu'
Server: dns2.icaen.uiowa.edu
Address: 128.255.17.20
Name: acc\@khath.com.phish.icaen.uiowa.edu
Address: 127.0.0.2
% nslookup 'acck@khath.com.phish.icaen.uiowa.edu'
Server: dns2.icaen.uiowa.edu
Address: 128.255.17.20
*** dns2.icaen.uiowa.edu can't find acck@khath.com.phish.icaen.uiowa.edu:
Non-existent host/domain
and that's with bind-9.4, not a particularly new revision.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: DNSBL for email addresses?
Posted by mouss <mo...@ml.netoyen.net>.
Le 23/12/2010 19:40, Chris Owen a écrit :
> On Dec 23, 2010, at 12:35 PM, mouss wrote:
>
>> do you really think there is a need to list email addresses? if yes,
>> then may be you can define a subset instead of all possible addresses.
>> after all, spammers don't use all possible representations, do they?
>
> May not, but they'd definitely start using anything that didn't fit into your model once you started having any success with it.
>
that's not a problem. we don't want to block every possible thing. we
want to block common things. if spammers start using "special" forms, we
can deal with that.
Re: DNSBL for email addresses?
Posted by Chris Owen <ow...@hubris.net>.
On Dec 23, 2010, at 12:35 PM, mouss wrote:
> do you really think there is a need to list email addresses? if yes,
> then may be you can define a subset instead of all possible addresses.
> after all, spammers don't use all possible representations, do they?
May not, but they'd definitely start using anything that didn't fit into your model once you started having any success with it.
Chris
--
-------------------------------------------------------------------------
Chris Owen - Garden City (620) 275-1900 - Lottery (noun):
President - Wichita (316) 858-3000 - A stupidity tax
Hubris Communications Inc www.hubris.net
-------------------------------------------------------------------------
Re: DNSBL for email addresses?
Posted by mouss <mo...@ml.netoyen.net>.
Le 14/12/2010 15:28, Marc Perkel a écrit :
> Are there any DNSBLs out there based on email addresses? Since you can't
> use an @ in a DNS lookup - how would you do DNSBL on email addresses? Is
> there a standard?
>
you an still use something like
john.doe@example.com => john.doe._address.example.com
but you still need to convert those special chars which are allowed in
local parts.
do you really think there is a need to list email addresses? if yes,
then may be you can define a subset instead of all possible addresses.
after all, spammers don't use all possible representations, do they?
Re: DNSBL for email addresses?
Posted by Yet Another Ninja <sa...@alexb.ch>.
On 2010-12-14 15:28, Marc Perkel wrote:
> Are there any DNSBLs out there based on email addresses?
nope
> Is there a standard?
nope
Re: DNSBL for email addresses?
Posted by Oguz Yilmaz <og...@gmail.com>.
You can try right hand side black lists (RHSBL) for domain part.
On Tue, Dec 14, 2010 at 4:28 PM, Marc Perkel
<su...@junkemailfilter.com> wrote:
> Are there any DNSBLs out there based on email addresses? Since you can't use
> an @ in a DNS lookup - how would you do DNSBL on email addresses? Is there a
> standard?
>
> --
> Marc Perkel - Sales/Support
> support@junkemailfilter.com
> http://www.junkemailfilter.com
> Junk Email Filter dot com
> 415-992-3400
>
>
Re: DNSBL for email addresses?
Posted by Marc Perkel <su...@junkemailfilter.com>.
On 12/14/2010 2:38 PM, Big Wave Dave wrote:
> On Tue, Dec 14, 2010 at 6:28 AM, Marc Perkel
> <su...@junkemailfilter.com> wrote:
>> Are there any DNSBLs out there based on email addresses? Since you can't use
>> an @ in a DNS lookup - how would you do DNSBL on email addresses? Is there a
>> standard?
>>
>> --
>> Marc Perkel - Sales/Support
> While not an actual DNSBL, and only loosely related... I have been
> reading about:
> http://code.google.com/p/anti-phishing-email-reply/
>
> Dave
>
Thanks - looks useful.
--
Marc Perkel - Sales/Support
support@junkemailfilter.com
http://www.junkemailfilter.com
Junk Email Filter dot com
415-992-3400
Re: DNSBL for email addresses?
Posted by Big Wave Dave <bi...@gmail.com>.
On Tue, Dec 14, 2010 at 6:28 AM, Marc Perkel
<su...@junkemailfilter.com> wrote:
> Are there any DNSBLs out there based on email addresses? Since you can't use
> an @ in a DNS lookup - how would you do DNSBL on email addresses? Is there a
> standard?
>
> --
> Marc Perkel - Sales/Support
While not an actual DNSBL, and only loosely related... I have been
reading about:
http://code.google.com/p/anti-phishing-email-reply/
Dave
Re: DNSBL for email addresses?
Posted by Bowie Bailey <Bo...@BUC.com>.
On 12/14/2010 8:31 PM, Philip Prindeville wrote:
> On 12/14/10 3:35 PM, Cedric Knight wrote:
>> On 14/12/10 14:28, Marc Perkel wrote:
>>> Are there any DNSBLs out there based on email addresses? Since you
>>> can't
>>> use an @ in a DNS lookup
>> Actually, you can use '@' in a lookup. You just can't use it in a
>> hostname.
>>
>> Or you could convert the '@' to a '.' as is the format still used in SOA
>> records.
>
> Not just SOA records, but the MB records were supposed to use this as
> well. They just never caught on.
So how does this work for an address like first.last@example.com? This
would be converted to first.last.example.com, which is ambiguous and
likely decoded to first@last.example.com.
--
Bowie
Re: DNSBL for email addresses?
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
On 12/14/10 3:35 PM, Cedric Knight wrote:
> On 14/12/10 14:28, Marc Perkel wrote:
>> Are there any DNSBLs out there based on email addresses? Since you can't
>> use an @ in a DNS lookup
> Actually, you can use '@' in a lookup. You just can't use it in a hostname.
>
> Or you could convert the '@' to a '.' as is the format still used in SOA
> records.
Not just SOA records, but the MB records were supposed to use this as well. They just never caught on.
-Philip
Re: DNSBL for email addresses?
Posted by Cedric Knight <ce...@gn.apc.org>.
On 15/12/10 00:43, RW wrote:
> On Tue, 14 Dec 2010 15:52:28 -0800 (PST)
> John Hardin <jh...@impsec.org> wrote:
>
>> On Tue, 14 Dec 2010, Cedric Knight wrote:
>>
>>> So a hash is best,
>>
>> Agreed.
>>
>>> and I'd suggest SHA1 over MD5.
>>
>> Just out of curiosity, why? An MD5 hash is shorter than an SHA hash
>> (an important consideration when you're making lots of DNS queries of
>> the hash), MD5 is computationally lighter than SHA, and MD5 is robust
>> enough for this purpose, even though artificial collision scenarios
>> exist.
Maybe I was being over-cautious, based on articles (which I can't find
online any more) suggesting MD5 is likely to become trivial to crack in
future owing to mathematical shortcuts. It's not as if you can recover
the data from a hash, or even (as I read it) that you can create a
collision for any given hash yet, but there may be a problem in any
context with assuming something is secure when it's only semi-secure.
I am not a mathematician or security expert, therefore I am swayed by
pronouncements from US-CERT:
"Do not use the MD5 algorithm
Software developers, Certification Authorities, website owners, and
users should avoid using the MD5 algorithm in any capacity. As previous
research has demonstrated, it should be considered cryptographically
broken and unsuitable for further use."
http://www.kb.cert.org/vuls/id/836068
OK, so this isn't a cryptographic application. I'm just thinking
future-proofing. Some background for non-experts like me:
http://www.maa.org/devlin/devlin_02_06.html
SHA1 is 40 characters, as against MD5's 32, which isn't such a great
difference, considering an IPv6 lookup is 64 under rfc5782.
>> Granted I wouldn't sign a legal document with it any more, but for a
>> private perfect hash of an email address, why not?
>
> I don't see that there's all that much added security anyway.
>
> I don't think spammers are likely to intercept dns as a way of
> harvesting addresses.
>
> As far as general privacy is concerned, without a shared-secret anyone
> can generate the hash and look for known addresses. And if you don't add
> salt to the hash, it's going to be fairly easy to perform an efficient
> dictionary attack, in which case the choice of hash function makes
> little difference.
I wasn't thinking of harvesting by spammers, but by (say) a government
authority that does not already have a dictionary of addresses that is
known to be complete. This is information in non-spam bodies that might
be looked up (well it would be if you want to use it to block 419
scams). Also, possibly people might want to use the same hashing
standard for a DNSWL of (maybe DKIM-verified) email addresses, meaning
that list would be abusable by spammers who are able to create a hash
collision.
CK
Re: DNSBL for email addresses?
Posted by RW <rw...@googlemail.com>.
On Tue, 14 Dec 2010 15:52:28 -0800 (PST)
John Hardin <jh...@impsec.org> wrote:
> On Tue, 14 Dec 2010, Cedric Knight wrote:
>
> > So a hash is best,
>
> Agreed.
>
> > and I'd suggest SHA1 over MD5.
>
> Just out of curiosity, why? An MD5 hash is shorter than an SHA hash
> (an important consideration when you're making lots of DNS queries of
> the hash), MD5 is computationally lighter than SHA, and MD5 is robust
> enough for this purpose, even though artificial collision scenarios
> exist.
>
> Granted I wouldn't sign a legal document with it any more, but for a
> private perfect hash of an email address, why not?
I don't see that there's all that much added security anyway.
I don't think spammers are likely to intercept dns as a way of
harvesting addresses.
As far as general privacy is concerned, without a shared-secret anyone
can generate the hash and look for known addresses. And if you don't add
salt to the hash, it's going to be fairly easy to perform an efficient
dictionary attack, in which case the choice of hash function makes
little difference.
Re: DNSBL for email addresses?
Posted by RW <rw...@googlemail.com>.
On Thu, 23 Dec 2010 19:31:23 +0100
mouss <mo...@ml.netoyen.net> wrote:
> if you're worried about performace, don't hash at all. would you use a
> cesar/base64/... ? either you need security and you use an algorithm
> that's not considered broken, or you don't.
The breaks in md5 would allow an attacker to generate a second email
address that collides with a given address. I don't see how that
compromises anything since presumably the intent is to avoid an
attacker inferring an address from a hash.
From the security point of view the scheme itself is far more broken
than md5 is. A secure hash function can only protect addresses that
are both secret and contain a cryptographically secure amount of
entropy.
I'm curious as to the point of this. Phishing/fraud contact addresses
might be better left to AV software that already have the
infrastructure to push this kind of information without any
side-channel leakage. Abusive marketers use fixed from addresses
but their status is often subjective. If the intent is to catch lazy
spammers, I think it'll be a very short-term win.
Re: DNSBL for email addresses?
Posted by mouss <mo...@ml.netoyen.net>.
Le 23/12/2010 22:56, Bob Proulx a écrit :
> mouss wrote:
>> John Hardin a écrit :
>>> Just out of curiosity, why? An MD5 hash is shorter than an SHA hash (an
>>> important consideration when you're making lots of DNS queries of the
>>> hash), MD5 is computationally lighter than SHA, and MD5 is robust enough
>>> for this purpose, even though artificial collision scenarios exist.
>>
>> because it's good to abandon weak algorithms, once for all. the small
>> wanna be performance benefit that you might find is useless.
>
> But the logical conclusion of that argument is that all hashes are
> insecure and none should ever be used. Because even though SHA is
> considered secure today the expected trend is that it will also fall
> to attacks in the future and be replaced by something heavier.
>
yes, defences must evolve. today, we need defences that resist current
and near future threats.
>> we keep seeing people using weak stuff because "it's enough" and "it's
>> faster/lighter/..." with the results that you know.
>
> And there is a reason for that. Right-sizing is also important. It
> isn't good to use a large construction bulldozer when a single shovel
> is all that is needed. If MD5 is the optimal size then it is the
> right size to use regardless of vulnerabilities when used in a
> security critical role.
>
but you must also take into consideration the possibility and costs of
upgrade to another algorithm if MD5 falls completely. if you believe
that the probability for MD5 and SHA to fall completely in the near
future are the same, then go for MD5.
>> if you're worried about performace, don't hash at all. would you use a
>> cesar/base64/... ? either you need security and you use an algorithm
>> that's not considered broken, or you don't.
>
> You have hit the problem exactly. If we follow the line of logic you
> have presented then we can never hash. Because there isn't ever going
> to be a hash that doesn't ever have collisions.
>
no, see above.
>>> Granted I wouldn't sign a legal document with it any more, but for a
>>> private perfect hash of an email address, why not?
>>
>> it's weak. don't use it anymore. we have many "secure" alternatives, why
>> go for "bugward compatibility"?
>
> Until SHA falls too.
>
in the long run, we will all be dead ;-p
today, we take medicine that is considered good/safe/... today.
Re: DNSBL for email addresses?
Posted by Bob Proulx <bo...@proulx.com>.
John Hardin wrote:
> Bob Proulx wrote:
> >If MD5 is the optimal size then it is the right size to use
> >regardless of vulnerabilities when used in a security critical
> >role.
>
> One of my core points was this _isn't_ a security-critical role. I
> hope you mistyped there, Bob.
I think we are in agreement. I don't think I mistyped anything. I
read that through several times just now and it reads okay to me. But
the author is always blind to their own mistakes. Let me clarify by
saying it differently.
I acknowledge that it is possible to generate hash collisions for md5
hashes making it no longer suitable for use in security applications.
But since this isn't being talked about in a security role that
restriction doesn't apply. It is not relevant to the discussion.
With that in mind then if md5 is good algorithm to use then it is a
good algorithm to use. Let's not place additional unrelated
restrictions upon it.
Using heavy algorithms inappropriately just slows down programs
without need. It is inefficient and inelegant.
I pretty much agreed with everything else you so eloquently wrote.
With the exception of this following item.
> To digress, I would suggest the solution to that (and what I wish
> PGP had implemented from day one) is to sign using two different
> cryptographic hash algorithms (e.g. MD5 _and_ SHA1). It's extremely
> unlikely that two different hash algorithms would have the same
> collision failure mode - i.e. it would be effectively impossible to
> generate a single plaintext that would generate the desired hashes
> for _both_ algorithms.
Using two algorithms combined is really just another algorithm itself.
Call it md5sha1 and there you have it. If such came into wide use it
would also be a target of study and attack. And counter intuitively
sometimes the very act of having the same plain text encrypted using
two different algorithms actually weakens the result!
Bob
Re: DNSBL for email addresses?
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Thu, 23 Dec 2010 18:16:31 -0800 (PST)
John Hardin <jh...@impsec.org> wrote:
> The response time for listing an email address in a phishing emailRBL
> may be too great to see much benefit.
We see a pretty good benefit from the anti-phishing email reply list.
It's not so much a good tool to catch phishers as it is a good tool to
block spam sent from phished accounts. (This is a particular attack
whereby phishers obtain email credentials, typically at a university,
in order to send tons of spam from the compromised account.)
Regards,
David.
Re: DNSBL for email addresses?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 23 Dec 2010, David F. Skoll wrote:
> On Thu, 23 Dec 2010 17:08:11 -0800 (PST)
> John Hardin <jh...@impsec.org> wrote:
>
>> But the known-evil addresses aren't the data being protected (however
>> poorly) - the email addresses from your inbound mail that you're
>> checking against the list of evil addresses (which may include
>> correspondents who don't want their email addresses spread about
>> publicly) are what you're protecting.
>
> Ah, I see. You want to protect the email addresses you're checking
> from a malicious DNS server that might harvest the addresses... OK.
Or from sniffers on the public network capturing the DNS query off the
wire.
> I'm not sure a DNSBL of email addresses would be effective. We see
> spammers mutating addresses all the time. I expect that's why there
> haven't been any widely-used email address DNSBLs.
The context for this is where the sender of the message wants to get a
reply, typically for phishing. Those addresses will likely be valid and
stable (if only for a fairly short period of time) where a commercial
spammer will gladly forge all contact addresses to prevent identification
or in an attempt to leverage whitelists.
The utility of this is questionable - in the past few days I saw a report
that some large portion of the identity data captured by phishers was
obtained in the very early stages of the attack, before the phishing had
been reported to authorities who investigate and shut down the
phishers' accounts/websites.
The response time for listing an email address in a phishing emailRBL may
be too great to see much benefit.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
2 days until Christmas
Re: DNSBL for email addresses?
Posted by Henrik K <he...@hege.li>.
On Thu, Dec 23, 2010 at 09:02:50PM -0500, David F. Skoll wrote:
> On Thu, 23 Dec 2010 17:08:11 -0800 (PST)
> John Hardin <jh...@impsec.org> wrote:
>
> > But the known-evil addresses aren't the data being protected (however
> > poorly) - the email addresses from your inbound mail that you're
> > checking against the list of evil addresses (which may include
> > correspondents who don't want their email addresses spread about
> > publicly) are what you're protecting.
>
> Ah, I see. You want to protect the email addresses you're checking
> from a malicious DNS server that might harvest the addresses... OK.
>
> I'm not sure a DNSBL of email addresses would be effective. We see
> spammers mutating addresses all the time. I expect that's why there
> haven't been any widely-used email address DNSBLs.
Over a year ago an experimental emailbl was tested here on the list. It
worked fine for many people. But it would be impractical FP and bandwidth
wise to run such list without specified set of domains, like freemails. More
and more hacked accounts from universities etc are used these days, which
would make the task harder. Running a respected public list would need some
_serious_ resources.
Re: DNSBL for email addresses?
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Thu, 23 Dec 2010 17:08:11 -0800 (PST)
John Hardin <jh...@impsec.org> wrote:
> But the known-evil addresses aren't the data being protected (however
> poorly) - the email addresses from your inbound mail that you're
> checking against the list of evil addresses (which may include
> correspondents who don't want their email addresses spread about
> publicly) are what you're protecting.
Ah, I see. You want to protect the email addresses you're checking
from a malicious DNS server that might harvest the addresses... OK.
I'm not sure a DNSBL of email addresses would be effective. We see
spammers mutating addresses all the time. I expect that's why there
haven't been any widely-used email address DNSBLs.
Regards,
David.
Re: DNSBL for email addresses?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 23 Dec 2010, David F. Skoll wrote:
> On Thu, 23 Dec 2010 16:33:59 -0800 (PST)
> John Hardin <jh...@impsec.org> wrote:
>
> [...]
>
>> To digress, I would suggest the solution to that (and what I wish PGP
>> had implemented from day one) is to sign using two different
>> cryptographic hash algorithms (e.g. MD5 _and_ SHA1). It's extremely
>> unlikely that two different hash algorithms would have the same
>> collision failure mode - i.e. it would be effectively impossible to
>> generate a single plaintext that would generate the desired hashes
>> for _both_ algorithms.
>
> I'm sure I read somewhere that in many cases, hashing with two
> different hash functions is as strong as the stronger of the two
> functions, but not any stronger than that.
>
> It's still a good idea if you don't know for sure *which* one is the
> stronger function.
>
> See "Concatenation of cryptographic has functions" at
> http://en.wikipedia.org/wiki/Cryptographic_hash_function
Thanks, I'll read that.
> Back on-topic: I don't think it's a problem to have a reversible way
> of encoding email addresses if they're used for blocking. The
> anti-phishing email reply address project produces a cleartext list of
> known phishing senders. These are (typically) compromised email
> accounts where the sender cannot continue to use the account and also
> change the sending address, so it does no harm to leave it in the
> clear.
But the known-evil addresses aren't the data being protected (however
poorly) - the email addresses from your inbound mail that you're checking
against the list of evil addresses (which may include correspondents who
don't want their email addresses spread about publicly) are what you're
protecting.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
2 days until Christmas
Re: DNSBL for email addresses?
Posted by "David F. Skoll" <df...@roaringpenguin.com>.
On Thu, 23 Dec 2010 16:33:59 -0800 (PST)
John Hardin <jh...@impsec.org> wrote:
[...]
> To digress, I would suggest the solution to that (and what I wish PGP
> had implemented from day one) is to sign using two different
> cryptographic hash algorithms (e.g. MD5 _and_ SHA1). It's extremely
> unlikely that two different hash algorithms would have the same
> collision failure mode - i.e. it would be effectively impossible to
> generate a single plaintext that would generate the desired hashes
> for _both_ algorithms.
I'm sure I read somewhere that in many cases, hashing with two
different hash functions is as strong as the stronger of the two
functions, but not any stronger than that.
It's still a good idea if you don't know for sure *which* one is the
stronger function.
See "Concatenation of cryptographic has functions" at
http://en.wikipedia.org/wiki/Cryptographic_hash_function
Back on-topic: I don't think it's a problem to have a reversible way
of encoding email addresses if they're used for blocking. The
anti-phishing email reply address project produces a cleartext list of
known phishing senders. These are (typically) compromised email
accounts where the sender cannot continue to use the account and also
change the sending address, so it does no harm to leave it in the
clear.
Regards,
David.
Re: DNSBL for email addresses?
Posted by John Hardin <jh...@impsec.org>.
On Thu, 23 Dec 2010, Bob Proulx wrote:
> mouss wrote:
>> John Hardin a �crit :
>>> Just out of curiosity, why? An MD5 hash is shorter than an SHA hash
>>> (an important consideration when you're making lots of DNS queries of
>>> the hash), MD5 is computationally lighter than SHA, and MD5 is robust
>>> enough for this purpose, even though artificial collision scenarios
>>> exist.
>>
>> because it's good to abandon weak algorithms, once for all. the small
>> wanna be performance benefit that you might find is useless.
>
> But the logical conclusion of that argument is that all hashes are
> insecure and none should ever be used. Because even though SHA is
> considered secure today the expected trend is that it will also fall to
> attacks in the future and be replaced by something heavier.
>
>> we keep seeing people using weak stuff because "it's enough" and "it's
>> faster/lighter/..." with the results that you know.
>
> And there is a reason for that. Right-sizing is also important. It
> isn't good to use a large construction bulldozer when a single shovel
> is all that is needed. If MD5 is the optimal size then it is the
> right size to use regardless of vulnerabilities when used in a
> security critical role.
One of my core points was this _isn't_ a security-critical role. I hope
you mistyped there, Bob.
MD5 is a well-known commonly-available computationally
relatively-inexpensive (near-)perfect hashing algorithm that allows us to
generate a fixed-length hash string that is DNS-friendly from an email
address that is of any length and contains any characters, including
characters such as periods that are _not_ DNS-friendly.
The rarity of collisions and the low (effectively nil) value of the target
mean that MD5 is still (IMHO) suitable for _this application_, and its
computational burden and hash size make it more attractive than SHA.
Quantifying _how much_ more attractive is a topic for discussion. The size
of IPv6 DNS queries is a good argument that the size of the hash isn't a
compelling factor, but I suggest that the brokenness of the MD5 algorithm
_isn't_ a good argument against MD5 _in this application_. So we're left
with relative computational burden.
>> if you're worried about performace, don't hash at all. would you use a
>> cesar/base64/... ? either you need security and you use an algorithm
>> that's not considered broken, or you don't.
Security in this context is a red herring. The most security desired for
this application is obfuscation to keep private email addresses from being
trivially recovered from third-party DNS server queries or logs of public
network traffic.
Simply base64-encoding the email address would make it DNS friendly, but
wouldn't hinder recovery.
> You have hit the problem exactly. If we follow the line of logic you
> have presented then we can never hash. Because there isn't ever going
> to be a hash that doesn't ever have collisions.
To digress, I would suggest the solution to that (and what I wish PGP had
implemented from day one) is to sign using two different cryptographic
hash algorithms (e.g. MD5 _and_ SHA1). It's extremely unlikely that two
different hash algorithms would have the same collision failure mode -
i.e. it would be effectively impossible to generate a single plaintext
that would generate the desired hashes for _both_ algorithms.
>>> Granted I wouldn't sign a legal document with it any more, but for a
>>> private perfect hash of an email address, why not?
>>
>> it's weak. don't use it anymore. we have many "secure" alternatives,
>> why go for "bugward compatibility"?
>
> Until SHA falls too.
Again, in this application I argue that a truly secure (at least for the
moment) hash algorithm isn't critical. Other factors are more important.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
"Bother," said Pooh as he struggled with /etc/sendmail.cf, "it never
does quite what I want. I wish Christopher Robin was here."
-- Peter da Silva in a.s.r
-----------------------------------------------------------------------
2 days until Christmas
Re: DNSBL for email addresses?
Posted by Bob Proulx <bo...@proulx.com>.
mouss wrote:
> John Hardin a écrit :
> > Just out of curiosity, why? An MD5 hash is shorter than an SHA hash (an
> > important consideration when you're making lots of DNS queries of the
> > hash), MD5 is computationally lighter than SHA, and MD5 is robust enough
> > for this purpose, even though artificial collision scenarios exist.
>
> because it's good to abandon weak algorithms, once for all. the small
> wanna be performance benefit that you might find is useless.
But the logical conclusion of that argument is that all hashes are
insecure and none should ever be used. Because even though SHA is
considered secure today the expected trend is that it will also fall
to attacks in the future and be replaced by something heavier.
> we keep seeing people using weak stuff because "it's enough" and "it's
> faster/lighter/..." with the results that you know.
And there is a reason for that. Right-sizing is also important. It
isn't good to use a large construction bulldozer when a single shovel
is all that is needed. If MD5 is the optimal size then it is the
right size to use regardless of vulnerabilities when used in a
security critical role.
> if you're worried about performace, don't hash at all. would you use a
> cesar/base64/... ? either you need security and you use an algorithm
> that's not considered broken, or you don't.
You have hit the problem exactly. If we follow the line of logic you
have presented then we can never hash. Because there isn't ever going
to be a hash that doesn't ever have collisions.
> > Granted I wouldn't sign a legal document with it any more, but for a
> > private perfect hash of an email address, why not?
>
> it's weak. don't use it anymore. we have many "secure" alternatives, why
> go for "bugward compatibility"?
Until SHA falls too.
Bob
Re: DNSBL for email addresses?
Posted by mouss <mo...@ml.netoyen.net>.
Le 15/12/2010 00:52, John Hardin a écrit :
> On Tue, 14 Dec 2010, Cedric Knight wrote:
>
>> So a hash is best,
>
> Agreed.
>
>> and I'd suggest SHA1 over MD5.
>
> Just out of curiosity, why? An MD5 hash is shorter than an SHA hash (an
> important consideration when you're making lots of DNS queries of the
> hash), MD5 is computationally lighter than SHA, and MD5 is robust enough
> for this purpose, even though artificial collision scenarios exist.
>
because it's good to abandon weak algorithms, once for all. the small
wanna be performance benefit that you might find is useless.
we keep seeing people using weak stuff because "it's enough" and "it's
faster/lighter/..." with the results that you know.
if you're worried about performace, don't hash at all. would you use a
cesar/base64/... ? either you need security and you use an algorithm
that's not considered broken, or you don't.
> Granted I wouldn't sign a legal document with it any more, but for a
> private perfect hash of an email address, why not?
it's weak. don't use it anymore. we have many "secure" alternatives, why
go for "bugward compatibility"?
Re: DNSBL for email addresses?
Posted by John Hardin <jh...@impsec.org>.
On Tue, 14 Dec 2010, Cedric Knight wrote:
> So a hash is best,
Agreed.
> and I'd suggest SHA1 over MD5.
Just out of curiosity, why? An MD5 hash is shorter than an SHA hash (an
important consideration when you're making lots of DNS queries of the
hash), MD5 is computationally lighter than SHA, and MD5 is robust enough
for this purpose, even though artificial collision scenarios exist.
Granted I wouldn't sign a legal document with it any more, but for a
private perfect hash of an email address, why not?
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Mine eyes have seen the horror of the voting of the horde;
They've looted the fromagerie where guv'ment cheese is stored;
If war's not won before the break they grow so quickly bored;
Their vote counts as much as yours. -- Tam
-----------------------------------------------------------------------
Tomorrow: Bill of Rights day
Re: DNSBL for email addresses?
Posted by Cedric Knight <ce...@gn.apc.org>.
On 14/12/10 14:28, Marc Perkel wrote:
> Are there any DNSBLs out there based on email addresses? Since you can't
> use an @ in a DNS lookup
Actually, you can use '@' in a lookup. You just can't use it in a hostname.
Or you could convert the '@' to a '.' as is the format still used in SOA
records.
But both of these would have privacy issues: say you've received an
email via TLS, your anti-spam system suspects it might be a 419, so you
look up a Reply-To address or body email address, and you send a query
to the RBL via DNS. But it turns out the message was private ham, and
you've lost the protection of TLS.
So a hash is best, and I'd suggest SHA1 over MD5. And I do think the
idea is worth trying; although freemail identities are cheap, there is
still some time and effort and risk of detection involved in creating
and checking them.
CK
Re: DNSBL for email addresses?
Posted by Daniel McDonald <da...@austinenergy.com>.
On 12/14/10 8:28 AM, "Marc Perkel" <su...@junkemailfilter.com> wrote:
> Are there any DNSBLs out there based on email addresses?
No. There was an experimental list for a while.
> Since you can't
> use an @ in a DNS lookup - how would you do DNSBL on email addresses?
# This plugin creates rbl style DNS lookups for email addresses.
# There isn't any official emailbl standard yet(?) so we:
#
# 1) make md5hash of lowercased email address (no other normalizations)
# 2) lookup <hexmd5hash>.zone.example.com.
>Is
> there a standard?
Nope, but it works. I use it locally with the emailBL.pm plugin.
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281