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 <[email protected]> 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" <[email protected]> Cc: [email protected] > 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. >
