IETF Logo Mail Archive

[secdir] sec-dir review of draft-ietf-eai-rfc5336bis-14.txt

Derek Atkins <derek@ihtfp.com> Thu, 20 October 2011 13:58 UTC

Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF5721F8BAB; Thu, 20 Oct 2011 06:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level:
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdWyOOCOIuGh; Thu, 20 Oct 2011 06:58:36 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 356B121F8B9C; Thu, 20 Oct 2011 06:58:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 815552602A6; Thu, 20 Oct 2011 09:58:35 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28573-10; Thu, 20 Oct 2011 09:58:34 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4D82D26002E; Thu, 20 Oct 2011 09:58:34 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id p9KDwS0x031504; Thu, 20 Oct 2011 09:58:28 -0400
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
References: <sjmfwinyesz.fsf@mocana.ihtfp.org>
Date: Thu, 20 Oct 2011 09:58:27 -0400
In-Reply-To: <sjmfwinyesz.fsf@mocana.ihtfp.org> (Derek Atkins's message of "Thu, 20 Oct 2011 09:26:36 -0400")
Message-ID: <sjmty73wyrg.fsf@mocana.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: yaojk@cnnic.cn, eai-chairs@tools.ietf.org, maowei_ietf@cnnic.cn
Subject: [secdir] sec-dir review of draft-ietf-eai-rfc5336bis-14.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 20 Oct 2011 13:58:37 -0000

Sorry, that previous email was a review of draft-ietf-eai-rfc5336bis-14.txt.
I appologize for any confusion.

-derek

Derek Atkins <derek@ihtfp.com> writes:

> Hi,
>
> I have reviewed this document as part of the security directorate's 
> ongoing effort to review all IETF documents being processed by the 
> IESG.  These comments were written primarily for the benefit of the 
> security area directors.  Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
>    This document specifies an SMTP extension for transport and delivery
>    of email messages with internationalized email addresses or header
>    information.
>
> The security considerations sections lists a number of issues to
> consider with this document, and presents the issues well.  It does
> not go into particular depth about what could happen if those issues
> are not addressed.
>
> For example, 3.7.2 mentions "surprising rejections" but doesn't go
> into any depth beyond that nor does it explain what other failures can
> happen.
>
> Operationally it might be hard to make sure that all or none of the MX
> servers support UTF8SMTPbis, especially if the MX servers might MX for
> multiple domains, or be under different operational control.  What are
> the situations where mixed-MX support will work or fail?  Should MX
> servers need the ability to turn on or off support for this protocol
> on a per-domain basis to protect against these types of failures?
>
> Thanks,
>
> -derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

v2.23.0 | Report a Bug | By Email