email hashes in PGP keys as protection against spam

[Hauke Laging]

Hello,

I would like to propose a small change to gpg (which I cannot do myself as
I am not a programmer) which should solve the spammers harvest key servers
problem.

The description is on my web site:
http://www.hauke-laging.de/ideen/gpg-hash/index.en.html

Google told me that several people are aware of the problem but that it's
importance is assessed differently. One mentioned the idea I had, too, but
thought it was not possible with openpgp. So I hope that my suggestion is
new (I haven't found anything about that in the mailing list archive).

I hope that somebody with the necessary capabilities finds this interesting
and easy enough to give it a try. :-)

Of course, I am interested in comments in order to improve the concept if
necessary.


Hauke

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Daniel Kahn Gillmor-7]

Hi Hauke--

Interesting proposal (about digesting User IDs), but i suspect that the
ietf's openpgp working group is a better place to discuss this kind of
change than the tool-specific gpg-devel list.

For that reason, i'm sending my reply there, and i've set Reply-To there
as well.  i hope that's OK with you.

On 10/04/2009 10:08 PM, Hauke Laging wrote:
> The description is on my web site:
> http://www.hauke-laging.de/ideen/gpg-hash/index.en.html
 [...]
> Of course, I am interested in comments in order to improve the concept if
> necessary.


 (full message here:
http://lists.gnupg.org/pipermail/gnupg-devel/2009-October/025378.html )

some questions your proposal raises for me:

 0) you only talk about digesting the e-mail part of the address.  what
about the human-specific name?  Would this need to be digested also?
Why or Why not?

 1) your proposal lacks a concrete example case; What would the User ID
for 'Jane Doe <jane@...>' look like under this policy?  The
devil is often in the details, and an explicit example would help sort
out the details.

 2) Would the act of keysigning need to change under your proposal?  If
so, what would keysigners need to do differently than they currently do?

Regards,

        --dkg



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Robert J. Hansen-3]

I have removed the IETF list from the follow-up.  I don't think this
proposal is ripe for consideration by the specification community.

>> The description is on my web site:
>> http://www.hauke-laging.de/ideen/gpg-hash/index.en.html

Proposals like this come up a lot.  I have yet to see one which I think
really understands the problem.

Spam depends on:

        1. High volume.  If the spammer can't spam millions
           upon millions of emails, the spammer loses.
        2. Permissive SMTP.  The SMTP protocol has nothing
           in it to constrain spammers.
        3. Financial instruments.  Spammers have to get paid
           somehow.
        4. Email lists.  The spammer has to have some way to
           target people.
        5. Permissive law enforcement.  Spammers thrive on
           the lax enforcement of anti-fraud and anti-spam
           laws.
        6. User interaction.  The user has to see the spam.

What we can handle via technical means are #s 1, 2 and 6 (graylisting,
SMTP security, and Bayesian spam filtering).  Those three work pretty
well.  Graylisting alone reduced my spam by 99%; between that and a good
Bayesian filter, I can go for a week or more without seeing one.

Targeting #s 3 and 5 requires significant government intervention.  We
can't do that by ourselves; we have to get law enforcement to
participate, too.  In today's climate, that's just not happening.

Targeting #4 is a lost cause.  Taking away one resource is pointless,
given how many resources the spammers have.  Even if you remove all of
them, the spammers can still use statistical models of email addresses
to get messages out without impairment.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Hauke Laging]

Am Montag 05 Oktober 2009 schrieb Robert J. Hansen:

> Proposals like this come up a lot.  I have yet to see one which I think
> really understands the problem.

It seems we have to make clear what the problem is we are talking about. I
think for you the problem is "fighting spam in general". That is a noble
aim but has nothing to do with my proposal.

My aim is to let people publish their keys without being afraid that *this*
action leads to (more) spam. Have you considered that some people are not
willing to use spam filters for certain addresses?

My aim is not to get rid of spammers by blocking their main source of new
email addresses. Obviously that would not be key servers.

It is not the task of gpg development to solve the spam problem. But IMHO
it is one of its task to avoid unnecessary spam problems which arise
directly from the use of the software.


A second reason to do this is privacy. There is no reason to allow easy
queries the email addresses somebody or an organization uses.


Hauke

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Robert J. Hansen-3]

Hauke Laging wrote:
> My aim is to let people publish their keys without being afraid that *this*
> action leads to (more) spam. Have you considered that some people are not
> willing to use spam filters for certain addresses?

Sure, but this just goes to show you that people are awful at estimating
risks.  Take flying as an example: driving to the airport is the most
dangerous part of the trip, but people are more afraid of the plane
crashing than them getting into a fatal car accident.  Likewise, anyone
who keeps their keys off the keyservers because they're afraid of
getting spam is fantastically missing the point.

If this is really your aim, then I think this proposal needs to get shot
down.  The protocol can either address real concerns or else it can make
people feel better about things without actually doing anything at all.
 The former is engineering; the latter is snake-oil.

> A second reason to do this is privacy. There is no reason to allow easy
> queries the email addresses somebody or an organization uses.

So run a private keyserver.  Bang, problem solved.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[John Clizbe-2]

Robert J. Hansen wrote:

> Hauke Laging wrote:
>> My aim is to let people publish their keys without being afraid that *this*
>> action leads to (more) spam. Have you considered that some people are not
>> willing to use spam filters for certain addresses?
>
> Sure, but this just goes to show you that people are awful at estimating
> risks.  Take flying as an example: driving to the airport is the most
> dangerous part of the trip, but people are more afraid of the plane
> crashing than them getting into a fatal car accident.  Likewise, anyone
> who keeps their keys off the keyservers because they're afraid of
> getting spam is fantastically missing the point.

They are also not so good at estimating the incidence of "Keyserver SPAM".
Yes, it happens. But when I tried to measure it, it was of a level statistically
indistinguishable from random noise.

> If this is really your aim, then I think this proposal needs to get shot
> down.  The protocol can either address real concerns or else it can make
> people feel better about things without actually doing anything at all.
>  The former is engineering; the latter is snake-oil.

I see this proposal breaking a lot of applications to "solve" a minute level of
SPAM. It's a security blanket that really doesn't address the problem, only a
perceived cause.

>> A second reason to do this is privacy. There is no reason to allow easy
>> queries the email addresses somebody or an organization uses.
>
> So run a private keyserver.  Bang, problem solved.

LDAP servers make a great keyserver for this sort of application

--
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys@...?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Hauke Laging]

Am Montag 05 Oktober 2009 schrieb Robert J. Hansen:

> Sure, but this just goes to show you that people are awful at estimating
> risks.

Maybe. But I would not call it science that you imply that harvesting from
key servers will result in about the same amount of spam as pure address
guessing by the spammers would.


> Likewise, anyone
> who keeps their keys off the keyservers because they're afraid of
> getting spam is fantastically missing the point.

Your point maybe. It seems a bit strange to me that you believe to be
capable of calculating everyone's personal spam risk.


> If this is really your aim, then I think this proposal needs to get shot
> down.

Because you want to decide for others what risks they have to take and
which not. You may make fun of afraid flight passengers but nonetheless
such assessments should be up to the user.


> The protocol can either address real concerns or else it can make
> people feel better about things without actually doing anything at all.
>  The former is engineering; the latter is snake-oil.

There is a clear technical effect and an unclear estimation how completely
different problems might create the problem which shall be guarded against
this way. Snake-oil refers to fooling somebody. I don't do that. I do not
claim that an email address is spam safe just because the key server
problem is solved.


> > A second reason to do this is privacy. There is no reason to allow
> > easy queries the email addresses somebody or an organization uses.
>
> So run a private keyserver.  Bang, problem solved.

You are funny. You are promoting to avoid key servers thus not being
reachable any more for most users as the superior solution to hiding the
critical data in hash values? "people are awful at estimating"? Sometimes.


Hauke

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Hauke Laging]

Am Montag 05 Oktober 2009 schrieb John Clizbe:

> They are also not so good at estimating the incidence of "Keyserver
> SPAM". Yes, it happens. But when I tried to measure it, it was of a
> level statistically indistinguishable from random noise.

And some are not good at reading.

My description states twice that this is not a problem today but could
easily become one in the future if (what I think we all hope) more and
more people use PGP.

It will take several years until we reach this point. So we have enough
time to make the technical preparations.


> I see this proposal breaking a lot of applications

Some examples (for breaking applications which get their keys from key
servers)? Even if this is the situation today probably no problem would
arise as there is enough time to introduce such a feature quite slowly.


> It's a security blanket that really doesn't address the
> problem, only a perceived cause.

It addresses the obvious future problem, not the irrelevant problem of
today. How shall I understand "security blanket"?

Anyway: If enough people "percieve" such a problem, do you think your "it
will never be a problem because it is none today" theory is a good enough
argument against that?


> LDAP servers make a great keyserver for this sort of application

Not being reachable is not the application I was talking about.


Hauke

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Robert J. Hansen-3]

Hauke Laging wrote:
> Maybe. But I would not call it science that you imply that harvesting
> from key servers will result in about the same amount of spam as pure
> address guessing by the spammers would.

Estimating how many email addresses are released to spammers via the
keyservers is a black art.  It has been attempted, though.  See, e.g.,
John Clizbe's result.

For your proposal to work, you can never have an email address exposed.
Ever.  Anywhere.  The instant you screw up and your email address gets
out, the game is over.  Soon a spammer will discover it.  Within days
all the spammers will have it, since spammers share email lists with
each other.

In the end, you haven't done anything to stop spam.  All you've done is
bought yourself a little time, and paid a very high price for it --
you've made it very difficult for people who want to talk to you to get
in touch with you.

> Your point maybe. It seems a bit strange to me that you believe to be
> capable of calculating everyone's personal spam risk.

Objective reality is the same for everybody.  The objective reality of
the situation is that as soon as your email address gets exposed
anywhere, spammers will get it.  Closing off just one avenue of address
collection is absurd; it's like facing a horde of army ants and thinking
that just by stomping on one you're going to do something about the swarm.

> Because you want to decide for others what risks they have to take
> and which not. You may make fun of afraid flight passengers but
> nonetheless such assessments should be up to the user.

It already _is_ up to the user.  Nobody forces you to put an email
address on your key.  You can leave it off if you want.  If you're
really that concerned about keyserver spam, then feel free.  Be my
guest.  The protocol accommodates you.

But I think it's a very bad idea to start changing the protocol just to
appease the phantom fears of a small number of users.  Once you do that,
then everyone who has a phantom fear will demand the protocol be changed
to support them.

> Snake-oil refers to fooling somebody. I don't do that.

You may be fooling yourself.



I have cc'd GnuPG-Users on this one.  There doesn't appear to be
anything in this thread that's related to ongoing GnuPG development, so
continuing it on -devel seems inappropriate.  Let's move it over there.

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[Max-175]

you can use http://retroshare.sf.net

as it is a web of trust, you can add friends without a key server, but only, if friends of friends know them.

but if you do not add them, you cannot get mail or spam.

RetroShare Email is spam-free.

Max

On Mon, Oct 5, 2009 at 4:08 AM, Hauke Laging <mailinglisten@...> wrote:

Hello,

I would like to propose a small change to gpg (which I cannot do myself as
I am not a programmer) which should solve the spammers harvest key servers
problem.

The description is on my web site:
http://www.hauke-laging.de/ideen/gpg-hash/index.en.html

Google told me that several people are aware of the problem but that it's
importance is assessed differently. One mentioned the idea I had, too, but
thought it was not possible with openpgp. So I hope that my suggestion is
new (I haven't found anything about that in the mailing list archive).

I hope that somebody with the necessary capabilities finds this interesting
and easy enough to give it a try. :-)

Of course, I am interested in comments in order to improve the concept if
necessary.


Hauke

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel

[John W. Moore III-2]

Hauke Laging wrote:

>> LDAP servers make a great keyserver for this sort of application
>
> Not being reachable is not the application I was talking about.

The PGP Global Directory is both an LDAP Keyserver _and_ Reachable.  :-\

JOHN ;)
Timestamp: Monday 05 Oct 2009, 18:45  --400 (Eastern Daylight Time)



_______________________________________________
Gnupg-devel mailing list
Gnupg-devel@...
http://lists.gnupg.org/mailman/listinfo/gnupg-devel