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