--On Saturday, March 06, 2010 12:35 +0100 Alessandro Vesely
<[email protected]> wrote:
>...
> I don't know what "actual substance" outside of yam's scope
> Dave has been talking about.
YAM is deliberately chartered to advance documents, not to make
any substantive changes in specifications or do other major
work. A reevaluation or reconsideration of general security
issues with email would certainly involve major work that is not
on YAM's current critical path. If such a reevaluation were
required as a condition for documents advancing, then, IMO, we
need to abandon our current tasks, close the WG, and determine
whether there is energy for such an evaluation.
> Mail is often overlooked during generic talks about Internet
> security, where they primarily consider the web and the DNS.
> My feeling is that the WG should attempt to correct such
> general stance, but not at the cost of "leading to madness",
> in John's words.
Well, I would have said "becomes a separate thread", rather than
"overlooked". Certainly a lot of energy and consideration are
given anti-spam issues, detection and stopping of email-spread
malware, phishing, etc.
To be clear, I think it would be a great idea if someone wanted
to mount an effort to do a comprehensive review of security
issues with email and the relationship (including strengths and
weaknesses) of various approaches to dealing with those issues.
On the list of things that document would turn up, "the ability
to send body parts containing other than control-character-free
plain text implies that ability to transmit malware and one had
better be careful about the handling of such body parts" is
nearly trivially obvious, even though it belongs on the list.
Presumably such a document would also discuss the issues of
header-signing mechanisms that are not robust under common
transformations (and why they are, or are not, useful anyway),
the strengths and weaknesses of authentication and privacy
protection between SMTP servers (hop to hop) in a relay
environment, the risks introduced by incompetent SMTP servers
introduced as part of firewalls, the possible risks associated
with MUAs that automatically open any body part they can and
that rely on portions of file names (rather than content-type
information) to do so, and so on.
It is, for better or worse, a target-rich environment.
I doubt that there is energy in the IETF to develop such a
document and get sufficient consensus behind it to, e.g.,
process it as a BCP. I'd be happy to be wrong about that. Even
if I am not, there is always the possibility of someone
preparing such a document as an opinion piece and handing it off
to the RFC Editor as an independent submission.
But the absence of such a document and analysis should not, IMO,
block work in YAM or block the WG entirely.
>> My position is that an issue was brought up during the Secdir
>> review and I need an answer for the Responsible Area Director
>> and YAM WG Chairs.
>
> For the specific 8BITMIME case, I also agree with what Ned has
> said. It would sound grandiloquent to say that 8bit is
> dangerous because it is one of the many ways to break DKIM. I
> don't think it is a real concern.
While I agree with the conclusion here (and have said so), I am
less interested in whether it is a real concern than I am about
whether the problem is YAM's to solve.
The response to any review comment (even one of the area-based
ones) can be "thank you for your input, but it is not in this
WG's scope; if the community believes the work is important, we
would encourage charting another group to address it".
>...
> Hostile content is not the only risk. Disclosing sensible
> information is another pitfall. For example, consider
> attaching the "wrong" file and/or sending to the "wrong"
> recipient. Similar leakage can also occur with abuse reporting
> buttons --that will hopefully break loose from web based
> MUAs-- as users may inadvertently "throw" messages containing
> sensible data, into potentially unfriendly FBLs.
Indeed. As I suggested above, it is a target-rich environment.
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
