Subject: RE: [Asrg] seeking comments on new RMX article

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 7 May 2003 00:35:20 -0400

J C,

I read your message carefully, I guess you are correct using your 
interpretations of the terms 'attack vector', and 'broken' you current message 
has given me clarity in that regard.  I do not use those terms in the same way 
for me an 'attack vector' is an exploited vulnerability in a system and 
'broken' means a protocol or process does not function as described given valid 
or invalid inputs.  I thought you were using the terms in that regard, my bad.

On Tuesday, May 06, 2003 9:44 PM, J C Lawrence [SMTP:[email-masked]] wrote:
> On Tue, 6 May 2003 20:50:50 -0400
> Eric D Williams <[email-masked]> wrote:
> > On Tuesday, May 06, 2003 7:50 PM, J C Lawrence [SMTP:[email-masked]]
> > wrote:
> >> On Tue, 6 May 2003 12:10:21 -0700 (PDT) Michael Rubel
> >> <[email-masked]> wrote:
>
> >> Nope, there's nothing in there specific to RMX, RMX just prompted
> >> some mental noodling which ended up with me doing some arm waving at
> >> future attack vectors.  RMX is broken for simpler reasons, which have
> >> been well covered without my help.
>
> > Please explain.  I do not think that your example has shown a flaw in
> > RMX.
>
> <sigh> Please read what I wrote.  Your question states that you haven't.
>
> > As I stated in my message on this point the attack scenario you
> > describe is a security concern primarily and a spam issue secondarily.
>
> Quite.

We concur, but notice I did not use the term 'attack vector' that's where my 
confusion started.

> > In fact if a system is compromised spamming would be a minimal concern
> > as compared to eliminating the vulnerability.
>
> Empirically, average homeowner desktop users do not have that view, not
> even slightly.

I don't agree, there is a difference of opinion here (I deal with quite a few 
home users who do not hold that view).  Spamming in this regard is a symptom of 
the compromise resulting from an exploited vulnerability.

> > Please give an example of how RMX is fundamentally broken. I have
> > heard that opinion several times today, could you provide an example
> > (especially since it is so trivial - I have not been able to come up
> > with one)?
>
> Not my business, not my interest.  This message represents almost an
> order of magnitude greater investment in RMX than I have interest in it.
> The list archives cover the ground quite effectively.  If you don't read
> them that way, that's up to you.  We differ.  Life will go on.

I do not derive the same level of resolution regarding the arguments presented 
in the archives nor during this thread.  You are correct we differ.

> >>> As you note, RMX would not help against this kind of attack, and
> >>> frankly neither would any other proposal I'm aware of.  If I can
> >>> trick your machine into thinking I'm you, then I can do bad things
> >>> in your name and thus make you look bad.
>
> >> Quite.  As I noted at the time, this is a core problem with edge
> >> authentication schema, and isn't necessarily resolvable.
>
> > I am not sure of what you are saying are you referring to systems
> > commonly known as user desktops?  I did not recognize the attack
> > vector in your example or a description of what part of RMX introduced
> > a flaw/vulnerability into the compromised system.
>
> Aiiieee!  Please try reading a message as written.  I have made no
> specific comment about user desktops except as an example application of
> the attack vector.  User desktops, as a specific case are uninteresting.
> There's nothing unique there.  Just how many times do I have to write
> that RMX is not particularly involved in that attack vector?

If you are referring to DNS et. al. as edge authentication schema I understand, 
I could not carry forward your argument because of the inconsistent view of the 
terms.  I thought you were referring to the attack scenario.  Otherwise, I 
thought you were referring to desktop per se system, that use trivial 
authentication schemes and thus can usually be easily compromised.

I did not recall you making a statement about the RMX not being involved in the 
attack scenario, I completely follow your premise for the result of a 
successful compromise of a system - I think I stated that in the first message 
in response to the scenario.  This is not complicated, I follow you I'm just 
looking for clarity in assessing your arguments.

> >>> I submit that RMX gives a significant improvement, and it's just
> >>> simple/easy enough that people might start using it!
>
> >> Deployment expenses with RMX are a significant problem, as are the
> >> ROI curves related to percentage deployments and fundamental email
> >> use costs.  You can arm-wave technical solutions at them, but they
> >> merely increase the deployment, support, and maintenance costs for a
> >> negative ROI on the part of the deployer.  You are attempting to
> >> recreate top-down authority structures when the natural (and proper?)
> >> tendency of the field in normal legitimate use is for
> >> self-authenticating/identifying nodes, not external nomination
> >> systems.
>
> > From where does this analysis stem.
>
> Me.

How does that help in giving the group a cogent view of what metrics should be 
used to evaluate other proposals.  I asked because if there is a viable 
methodology for determining these various methods they should be referenced in 
the requirements, additionally we could develop some threshold for viability. 
 BTW, I am not attempting to "recreate" anything and I am not, during my 
analysis, limiting the solution set, at this point, to any particular approach.

> > Please cite examples of how you determined the deployment costs and
> > ROI on RMX.  I am interested in reproducing your results for
> > validation.
>
> Sorry, no.  Simply, it is neither worth my time or yours.  Arguments,
> evaluations, and empirical evidence has been presented in the last weeks
> which you have variously ignored, decreed as irrelevant, or labeled as
> an acceptable cost.  I've no interest in repeating that history when it
> is so readily available in the archives.  Not my job, not my investment,
> not my interest.

I do not engage in that type of analysis.  I do not 'decree' anything nor do 
have I even stated I advocate a particular proposal (though I am willing to 
work to evolve some toward viability).  Of course there are other proposals 
that have been presented and if you review my posts you may note I have only, 
so far, asked or attempted to answer questions presented where I can.  I am 
engaging in analysis mostly, some writing (Requirements Draft) and some 
critiquing, to date.

> >> Now, can we move on to digging out a proposal which has a chance of
> >> being useful instead of beating dead horses?
>
> > I think it's still twitching.
>
> Aye, sometimes the nerves take a bit longer to die.

Indeed.

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

---

From: J C Lawrence <[email-masked]>
Date: Tue, 06 May 2003 23:06:53 -0700

On Wed, 7 May 2003 00:35:20 -0400 
Eric D Williams <[email-masked]> wrote:
>> On Tue, 6 May 2003 20:50:50 -0400 Eric D Williams <[email-masked]>
>> wrote: 

>> Empirically, average homeowner desktop users do not have that view,
>> not even slightly.

> I don't agree, there is a difference of opinion here (I deal with
> quite a few home users who do not hold that view).  

Certainly there are many who consider it significant, but "many" doesn't
mean much in percentages, or in the size of the population who don't
manifest concern in any direct sense.  The very high rate of such
compromises, the long tenure of many compromised boxes (in the networks
I've monitored it averaged at just over 8 months), and the relatively
lackadaisical attention paid to compromise prevention, detection, or
correction all empirically suggest that the view if held, is not held
strongly, and is certainly not held strongly enough to warrant either
particular attention or care.

> Spamming in this regard is a symptom of the compromise resulting from
> an exploited vulnerability.

Agreed, tho I'm not sure that adds anything.

>>> vector in your example or a description of what part of RMX
>>> introduced a flaw/vulnerability into the compromised system.

>> Aiiieee!  ...

> If you are referring to DNS et. al. as edge authentication schema I
> understand, I could not carry forward your argument because of the
> inconsistent view of the terms.  I thought you were referring to the
> attack scenario.  Otherwise, I thought you were referring to desktop
> per se system, that use trivial authentication schemes and thus can
> usually be easily compromised.

Authentication in the standard sense is a question of what you have (eg
SecureID key fob), what you know (eg password), and who you are (ala
biometrics).  Applying that level of authentication to email at the
transaction level is inapplicable.  Its simply too large a barrier to
standard usage.  As a result authentication data is cached, or locality
information like IP address or stored shared secret is used to supplant
more rigorous authentication.  Its that convenience factor that breaks.

  I described that data as stored and processed on the edge, which is
  admittedly an extension of the "edge" term from networking in an
  abusive manner.  My bad; I should have been more clear.

More simply, its the principle that if the node representing the
authentication data is compromised, then authentication is compromised.
The standard human parallel, if in a horror movie sense, would be
attempting robust authentication in a space where demonic/spiritual
possession was common.  Not an easy problem.  

> I did not recall you making a statement about the RMX not being
> involved in the attack scenario, I completely follow your premise for
> the result of a successful compromise of a system - I think I stated
> that in the first message in response to the scenario.  This is not
> complicated, I follow you I'm just looking for clarity in assessing
> your arguments.

According to reports (I haven't verified) we currently have zombied
boxes being used for spam distribution.  This cannot be very surprising.
Adding external controls like RMX and other forms of authentication
simply increases the value proposition to (criminal) spammers to upgrade
their zombie-based tools to extract seemingly-valid data from the
compromised host's configuration (which, rather helpfully in Window's
case, is readily available in standard locations behind common APIs) for
use in the generated email.

RMX is not directly involved in this, it would merely be a tool, which
like any other authentication mechanism if deployed, would encourage
spammers down this course.  I'm not stating that RMX shouldn't be
deployed because of this threat, or even the converse.  The simple
progression of history and the asymptotic curve toward greater forgery
accuracy will force that progression.

> How does that help in giving the group a cogent view of what metrics
> should be used to evaluate other proposals.  

It doesn't.  Such metrics have been discussed, are largely listed in the
taxonomy, and are frequent points of assertion in threads here (a simple
case is my frequent jumping up and down that the UUCP/disconnected case
shouldn't be broken).  Read the list -- most of those metrics are stated
and endlessly restated in the form of assertion lobbying (frankly its
getting worse than Congress).

> I asked because if there is a viable methodology for determining these
> various methods they should be referenced in the requirements,
> additionally we could develop some threshold for viability. 

That would be wonderful.  However, I'm not sure that a clear and
comprehensive view of metrics and costs is possible, but I'm willing to
be convinced.

We're dealing with an international scene, which implies a rather
bizarre set of environmental concerns ranging from baroque privacy and
wiretap laws, business model invalidation, curious assessments of
deployment costs, customer perception, QoS and other service contracts,
disconnected (ala UUCP) and mobile operations (such as the recently
discussed laptops) and so on down the pipe.  Its a particularly hairy
field.  It may very well be that we can come up with __NO__ universally
deployed solution, and even can't come up with a solution which will
ever (10 years) achieve more than 50% penetration.  Frankly, I'd rate
any proposal which stands a respectable chance of 30% deployment in 5
years as a standing ovation run-away success, but I may be overly
cynical.

> BTW, I am not attempting to "recreate" anything ...

RMX is a nominative authority structure -- something I consider a large
step backwards.

> ... and I am not, during my analysis, limiting the solution set, at
> this point, to any particular approach.

Thanks.

>> evaluations, and empirical evidence has been presented in the last
>> weeks which you have variously ignored, decreed as irrelevant, or
>> labeled as an acceptable cost.  I've no interest in repeating that
>> history when it is so readily available in the archives.  Not my job,
>> not my investment, not my interest.

> I do not engage in that type of analysis.  I do not 'decree' anything
> nor do have I even stated I advocate a particular proposal (though I
> am willing to work to evolve some toward viability).  

My apologies if I've been sloppy there.  Its quite possible that I've
conflated statements by you and others in the RMX thread.  <quick
review> Damn.  It looks like I have been sloppy there.  My very bad.
Please accept my apologies.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg