Subject: Re: [Asrg] Its all over for Challenge Response

From: Seth Breidbart <[email-masked]>
Date: Tue, 2 Mar 2004 22:01:25 -0500 (EST)

Andreas Saurwein <[email-masked]> wrote:
> At 4/2/2004 01:27 Wednesday, Seth wrote:

>>That can always be done by selecting a different ISP.  Therefore, any
>>problem is self-limiting.
>
> Not always you have to choice of ISP. There are still lots of places where 
> you have to be thankful that you HAVE internet access.

If I can run ssh on my own computer, I can use my chosen ISP.  I
haven't dialed in to Panix this century.

>>Would you also want to limit the ability of a church that provides
>>email accounts for its members to limit the ability of opposing
>>religions to send mail to its members?
>
> Yes

Why won't you let the owner of the equipment decide how it may be
used?

>>Would you also want to limit the ability of a company to limit the
>>ability of headhunters to solicit its employees?
>
> Again Yes.
> Thats what we call "policy". As a member or employee you accept the policy 
> or you go somewhere else.

So why are you _limiting_ the ability of the company?  You mean the
company has to allow the employees to do whatever they want, and just
fire them if it doesn't like it?

Seth

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Andreas Saurwein <[email-masked]>
Date: Wed, 03 Mar 2004 12:11:33 -0300

>haven't dialed in to Panix this century.

How many average users you'll find able to use ssh? Forget for a moment 
that there are some people (about 0.01% of the internet users?) who know 
what the heck they are doing.

>fire them if it doesn't like it?

Quite the other way round: the company sets the policy and the employees 
have to accept it, if they dont like it, they are free to go.
So, where is that limiting?

Andreas

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 03 Mar 2004 14:17:50 -0500

Andreas Saurwein <[email-masked]> wrote:
> How many average users you'll find able to use ssh?

  This is not an argument.  Those users are using MUAs.  The authors
of those MUAs can do the work, and add a checkbox that the idiot users
can use.

  And yes, we already know that solving the spam problem may require
software upgrades.  Saying that there will be cost and time to deploy
updated software isn't a useful argument, either.  If there is
sufficient incentive to upgrade, people will do so.

  And we already know that people who won't upgrade won't be doing
anything to help solve the spam problem.  We can ignore any arguments
about their needs, as they've already made their choice to accept the
current situation.

  Alan DeKok.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 4 Mar 2004 06:20:25 +0900

Alan,

>> How many average users you'll find able to use ssh?

AD>   This is not an argument.  Those users are using MUAs.  The authors
AD> of those MUAs can do the work, and add a checkbox that the idiot users
AD> can use.

For the IETF, it is the _only_ argument.  Folks forget that we exist
to produce specifications that get used.  Not "implemented" but
actually used.

For an example of the "it got implemented" criterion that ignored the
"it gets used" criterion, please refer to the history of OSI.

AD>   And yes, we already know that solving the spam problem may require
AD> software upgrades.  Saying that there will be cost and time to deploy
AD> updated software isn't a useful argument, either.  If there is
AD> sufficient incentive to upgrade, people will do so.

That is my point.  The nature and amount of incentive needed depends
on the cost and the benefit (along with a few other factors, of
course.) Any scheme that proposed massive change needs to pay quite a
bit of attention to the both of these.  That requires detailed
thinking, not a simple handwave.

AD>   And we already know that people who won't upgrade won't be doing
AD> anything to help solve the spam problem.  We can ignore any arguments
AD> about their needs, as they've already made their choice to accept the
AD> current situation.

That line of thinking is quite popular in the technical community, and
often even in the management community.  It accounts for a massive
number of companies' failures.  As well as standards' failures.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Seth Breidbart <[email-masked]>
Date: Wed, 3 Mar 2004 16:30:34 -0500 (EST)

> to produce specifications that get used.  Not "implemented" but

I gave ssh as an example to disprove the "I have to use the mailserver
provided by somebody who owns a wire to my house" claim.  Most MUAs
today are perfectly able to connect to arbitrary POP/IMAP servers and
MTAs, the user just fills in the boxes with the names of the machines
to use.

> course.) Any scheme that proposed massive change needs to pay quite
> a bit of attention to the both of these.  That requires detailed

It also depends on who needs to do what.  Something done at the server
level is likely to happen sooner than something done at the client
level, because there are fewer servers, their administrators tend to
be more knowledgeable, and the benefits can be greater.

Seth

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 03 Mar 2004 17:56:21 -0500

> to produce specifications that get used.  Not "implemented" but

  I believe the original point was about roaming users sending mail
via SSH tunnels in an LMAP-aware world, where their dynamic IP wasn't
listed in LMAP.  They could then use SMTP over an SSH tunnel to send
mail via a machine in the domain, versus using naked SMTP themselves.

  SSH exists and has been widely deployed for years.  SMTP exists and
has been widely deployed for years.  There is no need for additional
standards work.  There is only a need for MUA authors to implement and
deploy existing protocols.

  Nothing in that process requires input from the IETF or any other
standards body.

> > [ incentive to upgrade ]
> course.)  Any scheme that proposed massive change needs to pay quite a bit of
> attention to the both of these.  That requires detailed thinking,
> not a simple handwave.

  I agree.  But when a proposal is being opposed, we similarly need a
cost/benefit reason for opposition, not a simple hand-waving of "it
will cost more than most people think."  Such arguments don't help
move the discussion forward, either.

> number of companies' failures.  As well as standards' failures.

  I'm not sure how that comment is relevant to what I said.  I'm not
saying we deny them their needs, I'm saying that their anti-spam needs
aren't really relevant for input to the design of an anti-spam system,
as they chose not to participate in that system.

  In simple steps:

  a) If we design an anti-spam system which, by design, has zero
     impact on non-implementors when they interact with implementors,
     then it will also have zero impact on spammers.  (Who, by
     definition, won't implement it, or will implement it solely to
     abuse it.)

  b) If we design an anti-spam system which DOES require people to
     participate to get its benefits, then people who DON'T participate
     may not reap its benefits.

  c) That's OK, because they chose not to participate.

  d) People who don't implement an anti-spam system shouldn't be
     affected by it, unless they choose to interact with someone who
     does implement it.

  e) In that case we already know that communication is solely by
     mutual consent.

  f) Any anti-spam system MUST permit the implementor to choose to
     communicate with non-implementors, otherwise it is a draconian
     system, and will not be implemented by anyone.

  g) In which case, everyone is happy.  People who implement it will
     reap the benefits with other implementors.  People who don't
     implement it won't have their interaction with non-implementors be
     affected.

  The interaction between the two groups is solely at their own
discretion, which means local policy, which means it's outside of the
scope of ASRG & the IETF.

  I hope that makes my intentions clearer.

  Alan DeKok.