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

[Stephen Kent <[e-mail]>]

At 11:14 AM -0800 3/3/10, S Moonesamy wrote:
>...
>This part of the effort is to move 8BITMIME to Full Standard.  This 
>document does not change the 8BITMIME specification as defined in 
>RFC 1652.  There was a pre-evaluation and a Sec-dir review prior to 
>this document ( 
>http://www.ietf.org/mail-archive/web/secdir/current/msg01064.html ). 
>It would have been helpful if the YAM WG got a review of RFC 1652 at 
>that time but that did not happen probably due to miscommunication 
>about the process.  Please note that there hasn't been any reports 
>of security issues with this 16 year old specification.

OK

>>The security considerations section consists of only one sentence: 
>>"This RFC does not discuss security issues and is not believed to 
>>raise any security issues not already endemic in electronic mail 
>>and present in fully conforming implementations of [RFC5321]." RFC 
>>5321 (the updated SMTP spec) has an extensive security 
>>considerations section, so this is a reasonable reference. I could 
>>imagine security issues that might be associated with this document 
>>vs. 5321, since the security section of the latter document does 
>>not address any security concerns related to transfer of 8-bit 
>>data. For example, the handshake used to determine whether an SMTP 
>>sever support receipt/relay of 8-bit data might be used to target 
>>servers based on the lack of such support. One might even cite the 
>>use of this transport capability as facilitating malware 
>>transmission in e-mail attachments
>
>I don't understand your concern in regards to the 8-bit data 
>transfer.  If you mean that support for this SMTP extension could be 
>used to identify SMTP servers which do not support it, that is 
>correct.  There is some text about 8-bit message content 
>transmission in Section 2.4 of RFC 5321.

First, this is a minor issue, so we ought not devote to much time to 
it. I mentioned it because the tone of the security considerations 
sentence is somewhat dismissive, suggesting that the authors did not 
want to bother with this section :-). Nonetheless, it would be 
preferable  to explicitly note this side-effect of security 
considerations section, since it is not called out in the 5321 
security considerations and the text in 2.4 does not have a secruity 
focus.

>This transport capability does not facilitate malware transmission 
>as email attachments can still be sent even if the SMTP client or 
>server does not support the 8BITMIME extension.  It is only a matter 
>of using MIME for the 5322 message.

Presumably you mean to say that binary attachments that are ideal for 
delivering malware are supported irrespective of the use of this 
feature, right?  If so, that then that might also be a suitable 
comment to make in the SC section.

Steve