IETF Logo Mail Archive

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

Dave CROCKER <dhc@dcrocker.net> Sat, 06 March 2010 23:01 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: yam@core3.amsl.com
Delivered-To: yam@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0944628C1D0 for <yam@core3.amsl.com>; Sat, 6 Mar 2010 15:01:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.98
X-Spam-Level:
X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619]
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 OW7-xPuHgG+D for <yam@core3.amsl.com>; Sat, 6 Mar 2010 15:01:27 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id DACAA28C133 for <yam@ietf.org>; Sat, 6 Mar 2010 15:01:27 -0800 (PST)
Received: from [10.71.5.125] (static-202-133-104-182.mykris.net [202.133.104.182] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o26N1MMk014004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <yam@ietf.org>; Sat, 6 Mar 2010 15:01:30 -0800
Message-ID: <4B92DEBC.9030209@dcrocker.net>
Date: Sun, 07 Mar 2010 07:01:16 +0800
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: yam@ietf.org
References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> <4B90ED1C.8040905@tana.it> <6.2.5.6.2.20100305051249.09f24f38@resistor.net> <4B923E1E.4070201@tana.it> <6.2.5.6.2.20100306054559.08fe2908@resistor.net>
In-Reply-To: <6.2.5.6.2.20100306054559.08fe2908@resistor.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10525/Fri Mar 5 20:32:43 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 06 Mar 2010 15:01:31 -0800 (PST)
Subject: Re: [yam] [secdir] secdir review of draft-ietf-yam-rfc1652bis-03
X-BeenThere: yam@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: Yet Another Mail working group discussion list <yam.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/yam>
List-Post: <mailto:yam@ietf.org>
List-Help: <mailto:yam-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yam>, <mailto:yam-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Mar 2010 23:01:29 -0000

On 3/6/2010 11:05 PM, S Moonesamy wrote:
> The Last Call for draft-ietf-yam-rfc1652bis-03 ended yesterday. There wasn't
> any comments. This I-D will be evaluated by the IESG on March 11. I am
> waiting for a recommendation from Dave regarding the Secdir review.



Folks,

Feeling no strong resolve, myself, here's my current though:

The relevant part of Steve Kent's review:

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


A Security section should cover security issues that are specific to that
specification; it should not contain general-purpose tutorial material nor
should it contain material that is needed for other specification.  It other 
words, it should cover security issues that are new.

I suppose there is a reasonable case to be made for some coverage of materials 
that /should/ have been covered in another document, but weren't, and are 
relevant to the current specification.  But even that concession makes the 
question of what to include a slippery slope, IMO.

In any event...

The 8bitmime option does not create the potential for using SMTP option
negotations as an attack vector, such as permitting discovery of which servers 
support an option.  I therefore think it better /not/ to cite that in 1652bis. 
Given that this style of attack is not mentioned elsewhere, I suppose a small 
enhancement to the current text would be reasonable, such as:

    is not believed to
    raise any security issues not already endemic in electronic mail and
    present in fully conforming implementations of [RFC5321] {{ , including
    attacks facilitated by the presence of an option negotiation mechanism.}}


Even though 8bitmime is not a pure 'binary' mechanism, it does move things into 
a binary realm.  I therefore think that it /is/ reasonable to cite the potential 
for facilitating attacks based on use of binary data.  Hence, I propose also 
adding the text:

    Exploitation by malware is facilitated by supporting binary data in the
    transfer.  The 8BITMIME option does not provide a pure binary transport, but
    since it does transfer a nearly-binary object, there is some possibility
    that is could facilitate exploitations of this type.


Anyone object, suggest different text, or additional text?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

v2.23.0 | Report a Bug | By Email