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

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 04 March 2010 11:18 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774363A8972; Thu, 4 Mar 2010 03:18:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.69
X-Spam-Level:
X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hd5e4JOOpsUT; Thu, 4 Mar 2010 03:18:23 -0800 (PST)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 42BE03A7A97; Thu, 4 Mar 2010 03:18:21 -0800 (PST)
Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id <S4-W9wAu7sVr@rufus.isode.com>; Thu, 4 Mar 2010 11:18:22 +0000
X-SMTP-Protocol-Errors: NORDNS
Message-ID: <4B8F96E8.7020805@isode.com>
Date: Thu, 04 Mar 2010 11:18:00 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Stephen Kent <kent@bbn.com>
References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> <p06240804c7b4bcb4b668@[169.223.34.205]>
In-Reply-To: <p06240804c7b4bcb4b668@[169.223.34.205]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: secdir@ietf.org, S Moonesamy <sm+ietf@elandsys.com>, yam@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Mar 2010 11:18:28 -0000

Hi Stephen,

Stephen Kent wrote:

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

 [...]

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

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

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

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.