Re: [secdir] Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard

Sam Hartman <hartmans-ietf@mit.edu> Tue, 13 October 2009 21:02 UTC

Return-Path: <hartmans@mit.edu>
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 CD4133A6849; Tue, 13 Oct 2009 14:02:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.012
X-Spam-Level:
X-Spam-Status: No, score=-1.012 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 n+KlrN76H1ZZ; Tue, 13 Oct 2009 14:02:19 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 16BFA3A681A; Tue, 13 Oct 2009 14:02:18 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 752CA201CB; Tue, 13 Oct 2009 17:02:16 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A3192413F; Tue, 13 Oct 2009 17:02:13 -0400 (EDT)
To: John C Klensin <john-ietf@jck.com>
References: <20091013195732.09F5C28C10F@core3.amsl.com> <5CA1EFAE05D975C1D2802079@PST.JCK.COM>
From: Sam Hartman <hartmans-ietf@mit.edu>
Date: Tue, 13 Oct 2009 17:02:13 -0400
In-Reply-To: <5CA1EFAE05D975C1D2802079@PST.JCK.COM> (John C. Klensin's message of "Tue\, 13 Oct 2009 16\:24\:06 -0400")
Message-ID: <tslzl7vj9d6.fsf@mit.edu>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Last Call: draft-gennai-smime-cnipa-pec (Certified Electronic Mail) to Proposed Standard
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: Tue, 13 Oct 2009 21:02:19 -0000

I'd like to echo John's concern.  If this was not simply a case of
clicking the wrong button, then I think a longer last call
announcement explaining why the IESG believes standards track is
appropriate and why the IESG believes this document meets our criteria
for proposed standard would be in order.

Here are my initial reasons why I don't think the presumption that the
document is ready for standards track review holds in this case [1].

* The abstract claims this document describes what is done in Italy, not what should be done
* The use of mail headers, particularly from and reply-to seems likely to require review and discussion in the e-mail community
* I'm not sure this mechanism is consistent with BCP 61 or the Internet threat model.   In particular, section 5 describes several key threats but does not describe mandatory-to-implement mechanisms to meet these threats.  We'd never accept this from an IETF working group outside the security area, we shouldn't accept this from a security area document.
* The security considerations section 8 is very weak.  I think that a lot of what should belong there is actually in section 5, but even so this does not feel like an IETF document.

[1] We've had a lot of discussions about what level of consensus is
required to publish standards track documents that are individual
submissions.  However I at least believe that there's a presumption
that documents forwarded to last call by the IESG are at least ready
to be reviewed as standards track, so I feel the need to give specific
reasons why that presumption does not hold in a given case.