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

Dave CROCKER <dhc@dcrocker.net> Mon, 08 March 2010 16:43 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 2E4D23A69C8 for <yam@core3.amsl.com>; Mon, 8 Mar 2010 08:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 9VzMICwyagSk for <yam@core3.amsl.com>; Mon, 8 Mar 2010 08:43:26 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 1FD9C3A69D5 for <yam@ietf.org>; Mon, 8 Mar 2010 08:43:26 -0800 (PST)
Received: from [192.168.1.11] (ppp-67-124-90-197.dsl.pltn13.pacbell.net [67.124.90.197]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o28GhOc6022764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <yam@ietf.org>; Mon, 8 Mar 2010 08:43:30 -0800
Message-ID: <4B95292C.8040404@dcrocker.net>
Date: Mon, 08 Mar 2010 08:43:24 -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.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: yam@ietf.org
References: <4B8E515A.6060608@isode.com> <6.2.5.6.2.20100303103218.0ba092a0@resistor.net> <p06240804c7b4bcb4b668@[169.223.34.205]> <4B8F96E8.7020805@isode.com> <6.2.5.6.2.20100307215826.09a83830@resistor.net>
In-Reply-To: <6.2.5.6.2.20100307215826.09a83830@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10531/Mon Mar 8 08:13:06 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]); Mon, 08 Mar 2010 08:43:30 -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: Mon, 08 Mar 2010 16:43:27 -0000

On 3/8/2010 12:33 AM, S Moonesamy wrote:
> As there is no strong resolve, I suggest sending the following response
> to Sec-dir:
>
> The YAM WG discussed about the issues raised during the Sec-dir review of
> draft-ietf-yam-rfc1652bis-03 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 RFC5321.
>
> (ii) Since MIME semantics are transport neutral the 8bitMIME option
> provides no added capability to disseminate malware than is provided
> by unextended 7bit SMTP.


This is a clear and supportable stance.  And as Ned notes, a short Security 
section that is valid should be defended.

I'm entirely comfortable with my name on this document, with that position.

That said...

I'll note that confusion about the exposure this option does /not/ create seems 
to be pretty easy to suffer.  Defending against /that/ problem is probably worth 
a small amount of extra text.

The change I suggested:

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

Got some support.

And I have developed and even greater concern for the thinking that this type of 
binary mechanism causes a malware window.  I think we now have affirmative proof 
that the confusion is common.

So, I'll suggest that we use Ned's text:

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


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net