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:
BoxA is compromised.
The zombie code sucks in a spamming engine (SE).
The SE determines the mail configuration of BoxA in terms of
appropriate SMTP envelope etc from the registry.
BoxA spams away using the stolen credentials from its registry.
Thank you--you've raised a reasonable, cogent objection.
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. As
I stated in my message on this point the attack scenario you describe is a
security concern primarily and a spam issue secondarily. In fact if a system
is compromised spamming would be a minimal concern as compared to eliminating
the 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)?
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.
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. Please cite examples of how you determined
the deployment costs and ROI on RMX. I am interested in reproducing your
results for validation.
<shrug>
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.
-e
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg