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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Mar 2004 14:56:14 -0800

> 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.

The IETF has been spectacularly unsucessful by this criteria. The
vast majority of the 'IETF' specifications predate the first meeting.
HTTP, SSL, LDAP were all successful before work started in the IETF.

Only in a very small number of cases has there been any success in
changing an already deployed protocol. This is not intrinsic to the
problem though, it is a fixable feature of the way the Internet is put
together. 

Thinking about deployment is important, but there is not a single
specification that does not require some change somewhere - otherwise
there would be no need for the spec.

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

The history of OSI shows less than many claim. OSI came into existence
because European computer makers and the US government feared that 
IBM's SNA would become a defacto proprietary standard in the same way 
that the IBM PC did.

OSI failed for one reason alone, it missed the window of opportunity by
a couple of years. The Web killed OSI, the Internet and the IETF had
nothing to do with it. Once the Internet became the 'anyone but IBM'
candidate the support of pretty much everyone apart from the US
civil service switched to it. And yes there are folk in the USG
still plotting the deployment of X.500

The Internet is under-engineered, OSI is over-engineered. Neither has
any real impact on the success of a computer protocol. The second,
third and even fourth rate succeed all the time. OSI is tame 
compared to the protocols used in telephony.

> 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.

It is not the benefit that matters, it is the perceived benefit. The
potential benefit does not move the market unless people have a very strong
belief that it will succeed and that there is an advantage to being 
an early adopter.

> 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.

The spam problem will not drive the deployment of any authentication
mechanism. That is not the problem they are designed to solve.

The problem they do solve is the 'get my email through' problem. This
is at least as large as the spam problem. I just got an email from someone
who owes me $1390 I did not know had not been paid. It had been marked
as spam.

		Phill

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 3 Mar 2004 18:32:34 -0800

> You could do end to end between MTAs via multiple hops as per 
> RFC 3183. 
> But STARTTLS is *always* hop-to-hop between MTAs.

If you were going to do end-to-end you would do S/MIME.

But then you have all those headers in the clear anyway so there
is still real value to using SSL.

		Phill

---

From: Mark Baugher <[email-masked]>
Date: Wed, 03 Mar 2004 22:50:10 -0800

At 10:32 PM 3/3/2004, Mark Baugher wrote:
>At 08:49 PM 3/3/2004, Hallam-Baker, Phillip wrote:
>>
>> > >Sure it looks great in theory, but the cost of deploying all
>> > >those end user certificates is simply beyond most enterprises.
>> >
>> > It seems to me that your pinning the apparent failure of X.509
>> > PKI on the end-to-end security concept.
>>
>>No, SSL and Authenticode are tremendously successful, the best
>>security we have on the Internet in fact.

You shifted the argument.  I said "PKI" and you said "SSL" and
they are not the same thing, are they?

>>It is the email area
>>where we have failed - until we started to use STARTTLS.
>>
>> > I use PGP Mail whenever I need authentication and encryption.
>> > I consider it to be successful for my personal use.
>>
>>I don't consider PGP to be any more successfull, i get far more
>>S/MIME signed messages than PGP and that is ignoring the S/MIME
>>bias from PKIX and S/MIMe list membership. The vast majority
>>of MUAs support S/MIME and have done for years.

So what?  The vast majority of MUAs support PGP as well. And I don't
think you get far more S/MIME signed messages than PGP signed messages
from the ASRG lists.

>>The failure has been getting the end users to participate.
>>it was just too hard.
>>
>> > >If you look at the problem from a risk assement point of view
>> > >it is entirely reasonable to secure email internaly by using
>> > >SSL to secure communication with the email server and then to use
>> > >SSL to secure the hop over the Internet where the email is
>> > >most likely to be intercepted.
>> >
>> > There are two problems with this notion.  The first is that
>> > various intermediate systems have access to the communication
>> > to read and alter.
>>
>>Sure, but that is irrelevant. Almost none of the email on the
>>internet is encrypted in any form. The vast majority of messages
>>that are encrypted use STARTTLS.

RFC 3207 did not intend STARTLS to serve to protect user's email.
That's not what it's for.  Users who need email confidentiality
need confidentiality from interlopers who are most likely to have access
to their messages such as the mail operator.

>> > The second is that there is no guarantee
>> > that any pair of intermediate systems actually secure the
>> > hop between them.  The secure connection established by the
>> > two systems is appropriate for their own security needs rather
>> > than for the end-to-end traffic they convey over that connection.
>>
>>Again, wrong comparison. STARTTLS is a bicycle. It has nowhere
>>near the power and capabilities that a tank offers. But it will
>>get you to your destination far faster than walking.
>>
>> > >Sure they might be apples and oranges. But if you put apples
>> > >and oranges together you have a fruit salad.
>> >
>> > I do think STARTLS might have a role to play in antispam if
>> > there were some scalable way to do the authorization.
>>
>>The problem is advertising the fact you support STARTTLS in
>>the DNS.

See section 3 of RFC 3207.

>>it is not an authorization problem.

There is always an authorization problem.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Wed, 03 Mar 2004 22:50:10 -0800

Phill,

Mark

---

From: "Jon Kyme" <[email-masked]>
Date: Mon, 02 Feb 2004 10:06:26 +0000

> Jon Kyme responds:
> > This is all getting silly.
> > Numbers?
> > Actual exploit?
> 
> I say:
> Does anyone still seriously doubt that spamming miscreants are using
> third
> party computers as their web, mail and DNS hosts? Jon? This is not a new 
> phenomenon anymore.
> 

[many links snipped]

The point was about paying for puzzle solving with porn views.
I'm still unaware of the existence of an exploit or a good discussion of
the economics.

I'm not saying it's impossible, just currently in the realm of theory.

I whole-heartedly agree with you when you say:
>Any anti-spam proposal (particularly those that
>propose
>a cost-burden to the sender) should take this fact into >consideration.

We see many variations of "sender-pays" and "proof-of-work" which make
unwarranted assumptions about how "costs" impact miscreants.

--