RE: [Asrg] seeking comments on new RMX article

["Eric D. Williams" <[e-mail]>]

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:[e-mail]] wrote:
> On Tue, 6 May 2003 20:50:50 -0400
> Eric D Williams <[e-mail]> wrote:
> > On Tuesday, May 06, 2003 7:50 PM, J C Lawrence [SMTP:[e-mail]]
> > wrote:
> >> On Tue, 6 May 2003 12:10:21 -0700 (PDT) Michael Rubel
> >> <[e-mail]> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg