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

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Mar 2010 20:55:44 -0500

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

---

From: S Moonesamy <[email-masked]>
Date: Wed, 03 Mar 2010 11:14:13 -0800

Hi Stephen,

Thank you for your review.

At 04:08 03-03-10, Alexey Melnikov forwarded:
>From: Stephen Kent <[email-masked]>
>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.

>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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Mar 2010 11:18:00 +0000

Hi Stephen,

> At 11:14 AM -0800 3/3/10, S Moonesamy wrote:

 [...]

>> used to identify SMTP servers which do not support it, that is correct.
>
Right. ESMTP capability negotiation is a basic feature of ESMTP as 
described in RFC 5321, this is not specific to 8BITMIME.

>> There is some text about 8-bit message content transmission in 
>> Section 2.4 of RFC 5321.
>

RFC 5321 is also being revised by the YAM WG, so I would prefer any such 
text to go there.

> feature, right?

Firstly, 8BITMIME is not suitable for transferring unencoded binary 
data, it is only suitable for transfering 8bit text (e.g. textual 
documents encoded in UTF-8). BINARYMIME (a separate SMTP extension) is 
used to transfer unencoded binary data.

Secondly, the only thing that 8BITMIME changes is how certain email 
messages or message attachments are transferred. So if there is a 
malware that can take advantage of 8BITMIME, messages containing such 
malware would take less bandwidth to transfer.

> If so, that then that might also be a suitable comment to make in the 
> SC section.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 08 Mar 2010 11:49:02 -0800

Hi Steve,

The YAM WG discussed about the issues raised during the Sec-dir 
review of draft-ietf-yam-rfc1652bis-03 [1] and concluded that:

   (i) The presence of an option negotiation mechanism is not believed to
       facilitate attacks or raise any security issues not already endemic
       in electronic mail and present in fully conforming implementations
       of RFC 5321.

  (ii) Since MIME semantics are transport neutral the 8bitMIME option
       provides no added capability to disseminate malware than is
       provided by unextended 7bit SMTP.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/yam/current/msg00366.html

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Mar 2010 10:44:38 -0500

>       provided by unextended 7bit SMTP.

Thanks for the reply.

Steve