Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03

[Alessandro Vesely <[e-mail]>]

Hi SM,

>> RFC 4871 is of 2007 and reports an issue with it. Section 5.3 practically says that 8bit SHOULD NOT be used.
>
> Section 5.3 of RFC 4871 sounds more like a deployment consideration instead of a security consideration.

Yes, it is the deployment of a security add-on, though.

> The question from Stephen Kent [1] in response to my comment mentions that "binary attachments that are ideal for delivering malware are supported irrespective of the use of" the 8BITMIME extension. Dave Crocker requested input from the WG on the secdir review [2]. His message gives a broader view of the matter (i.e. whether the change is within scope for the YAM WG).

I don't know what "actual substance" outside of yam's scope Dave has 
been talking about.

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.

> 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.

> I wrote some notes about hostile content ( temporary link http://www.elandsys.com/resources/mail/draft-moonesamy-mail-security-00.txt ). It is not meant to be used as input for YAM WG work.

Interesting effort.

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.