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

[S Moonesamy <[e-mail]>]

Hi Stephen,

Thank you for your review.

At 04:08 03-03-10, Alexey Melnikov forwarded:
>From: Stephen Kent <[e-mail]>
>Subject: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03

[snip]

>This is a very, very brief document that is targeted to obsolete RFC 
>1652. It addresses transport of 8-bit (vs. ASCII) data via SMTP, 
>consistent with carriage of MIME 8BIT content encoding. This 
>document is part of the YAM effort, updating the series of Internet 
>email standards.

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.

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

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.

Could you please clarify the security issues you have in mind so that 
I can bring them to the attention of the authors of this document?

Regards,
S. Moonesamy