Alessandro,
Apparently, moving scripts execution to mail servers would also
transfer vulnerability issues along the same path.
I attempted to resolve this problem as much as possible.
1) Scripts would not be executed by the client, so only the owner of the
scripts could execute them.
2) I suggest that scripts must be executed in a sandbox location that is
different from where they are stored on the server. This idea is so if a
script becomes corrupt or compromised during a session of communication that
corruption would be limited to that single session. A sandbox can also be
regulated in how code is executed to prevent access to code outside the sandbox.
Is it difficult
to state whether a compromised server is better than a compromised
client, but it is certainly better if at least one of them is not
compromised.
I would say that it is better, only because of distribution of
responsibilities. A certain expectation is typically expected of a server
administrator, especially if that server administrator is from a respected
domain. There is no expectation of responsibility or expertise to maintain the
most basic of security controls from the user.
In addition, it may be overly difficult to obtain real
interactivity
without local scripting.
Yes, the idea of event oriented execution would not be possible. As a result
loss of application interactivity would certainly occur locally. The idea is
to replace this luxury with rapid short bursts of data exchange between a
client and the distant mail server. The result is certainly less reliable than
client-side scripting, but is more secure with a significantly higher degree of
data integrity.
I am extremely hesitant to suggest that any event oriented execution should
exist from an email client. Its a drastic hard stop to completely remove the
possibility of security compromise from the client. I believe there is a
middle ground where extremely limited interactions are possible from execution
based upon client events, such as mere manipulation of the DOM. It is very
possible that such limited execution can be easily specified, but I believe
this would be too easily abused. I believe people know how things should work
on the WWW and if provided the opportunity would do everything in their power
to ensure that they work in email without regard for the standards or security
compromises.
I will have to review the language of the specification to ensure I am not
incorrectly communicating the definition of a CA. I agree that the client
should not have to manage any role of a CA or even distributed digital
signatures. I do state that a CA must be on a domain separate from any other
involved agent in the transaction. The idea is that this process exist to
establish that the distant server is not a spoofed address in as much a
transparent manner as possible. I will reevaluate the language I have used to
describe this process.
Thanks,
Austin
----- Original Message -----
From: Alessandro Vesely <vesely(_at_)tana(_dot_)it>
Date: Friday, July 31, 2009 11:42
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
To: "Cheney, Edward A SSG RES USAR USARC"
<austin(_dot_)cheney(_at_)us(_dot_)army(_dot_)mil>
Cc: ietf-smtp(_at_)imc(_dot_)org
Cheney, Edward A SSG RES USAR USARC wrote:
The idea is that security vulnerabilities on the internet occur
most significantly as a result of client-side scripting [...]
Client-side scripting cannot be removed unless an alternative
convention is proposed.
[...] The idea is that interactivity from client-side scripting
can be replaced by transaction interactivity. Since mail servers
are intermediate agents [...]
Apparently, moving scripts execution to mail servers would also
transfer vulnerability issues along the same path. Is it difficult
to state whether a compromised server is better than a compromised
client, but it is certainly better if at least one of them is not
compromised. (Considering that many mail server also function as
http servers, for handling email via web forms, it seems unlikely
that the vulnerability added to the servers would thus be removed
from the clients.)
In addition, it may be overly difficult to obtain real
interactivity
without local scripting. Indeed, the draft defines what minimal
code
a client has to be allowed to execute. Allowing some more seems
likely to come as an optional feature...
Finally, if the model is meant for widespread use, it shouldn't
rely
on users' ability to obtain and maintain CA certificates on their
clients, or similar requirements, whose fulfillment doesn't seem
more likely than S/MIME or PGP deployment. IMHO, ensuring that the
server who has relayed the message is vouched for sending
transactions by a trusted authority may be more viable (see RFC
5518). I would additionally provide for an SMTP extension whereby
that relaying server grants that it knows where the message has
originated from, and takes accountability for its content.