[Gen-art] Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07

Ben Campbell <ben@nostrum.com> Wed, 19 September 2012 02:24 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0443711E80D1; Tue, 18 Sep 2012 19:24:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.596
X-Spam-Level:
X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k7LzZwpfji4; Tue, 18 Sep 2012 19:24:51 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C281611E808D; Tue, 18 Sep 2012 19:24:49 -0700 (PDT)
Received: from [10.0.1.3] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id q8J2OmXm021355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Sep 2012 21:24:48 -0500 (CDT) (envelope-from ben@nostrum.com)
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 18 Sep 2012 21:24:48 -0500
Message-Id: <74115521-D2B3-419B-9571-660D16F06BB1@nostrum.com>
To: draft-ietf-eai-simpledowngrade.all@tools.ietf.org
Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\))
X-Mailer: Apple Mail (2.1486)
Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism)
Cc: "gen-art@ietf.org Review Team" <gen-art@ietf.org>, "ietf@ietf.org List" <ietf@ietf.org>
Subject: [Gen-art] Gen-ART LC Review of draft-ietf-eai-simpledowngrade-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Sep 2012 02:24:52 -0000

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-ietf-eai-simpledowngrade-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary: This draft is mostly on the right track, but has open issues

Major issues:

-- I'm concerned about the security considerations related to having a mail drop modify a potentially signed message. The draft mentions that this is an issue. I think more discussion is warranted. In particular. What client behavior is expected when a signature is invalidated due to downgrading? I suspect the answer is "warn the user, who will most likely just click through without understanding the issue." I'm concerned about adding yet another reason to train end users to ignore security warnings. OTOH, should the mail drop strip out signatures? That has it's own issues. I'm not saying that I know the answer--merely that it's not clear to me that it has been sufficiently explored.

Minor Issues:

-- It's not clear to me why this is standards track rather than informational. As far as I can tell, it's mainly used by the IMAP UTF8 capability draft. But that draft seems to list this as an example of something you can do, and lists it as an informational reference.

-- section 3, 2nd paragraph:

Are there any limits on how much the size can differ from the actual delivered message? Can it be larger? Smaller? It's worth commenting on whether this could cause errors in the client. (e.g. Improper memory allocation)

-- "Open Issues" section: "Should Kazunori Fujiwara’s downgrade document also mention DOWNGRADED?"

Good question. It seems like they should be consistent on things like this. (This is really more a comment on that draft than this one.)


Nits and Editorial Comments:

-- This draft appears to dispense with 2119 language. It be nice if all the drafts in the group handled this consistently.

-- Abstract should mention that this updates 3501

-- section 1:

Can you more explicitly define "conventional"? I assume this means clients not supporting the relevant UTF8 capabilities? This terminology is inconsistent between this and draft-ietf-eai-popimap-downgrade.