Re: [Trans] Precertificate format

Melinda Shore <melinda.shore@gmail.com> Wed, 10 September 2014 16:25 UTC

Return-Path: <melinda.shore@gmail.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1CA1A88E2 for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 09:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MrvW9VXXWDpF for <trans@ietfa.amsl.com>; Wed, 10 Sep 2014 09:25:54 -0700 (PDT)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A14FE1A8966 for <trans@ietf.org>; Wed, 10 Sep 2014 09:25:46 -0700 (PDT)
Received: by mail-pa0-f44.google.com with SMTP id kx10so7985028pab.17 for <trans@ietf.org>; Wed, 10 Sep 2014 09:25:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=O88iWOrTGbR+Vc9L1yZ9VZyqMS3Asxe1gC4l7Nf4aTo=; b=EmHPxNRmk029NS6yGEahSIVYce1KGf7LqqsOnvjc0LQxsqMPjRz561ptT51LQsiLEo N0r7SnG33su3tOExjcGAtyfPwUrnSoQ07Vz6Ax7SMPEuJhmb5jvhAuX9Gb8KDdXHnnf0 J9UcJbk644/TCJAN60GmcaBCinKL2cjXKuB0623AwacuM1LgQMOJJyKg6MxY6/TPIMZL ZwA3EWuv+KlzA3Rl2QK2v5mgg90pCz9uwQtBIT7WgaQsIVIyWJA5cTqlDb6n8wtBhlPf 0ACN35CQqiSHEfHVCBhykW53ovh6rs+tT8INVHNe1SpAQs7lcJOHapyp4OSZTrTUxvNr TcHw==
X-Received: by 10.70.60.197 with SMTP id j5mr6030990pdr.145.1410366346057; Wed, 10 Sep 2014 09:25:46 -0700 (PDT)
Received: from spandex.local (69-161-3-58-rb2.sol.dsl.dynamic.acsalaska.net. [69.161.3.58]) by mx.google.com with ESMTPSA id bv5sm14937617pbc.20.2014.09.10.09.25.44 for <trans@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 09:25:45 -0700 (PDT)
Message-ID: <54107B87.3060900@gmail.com>
Date: Wed, 10 Sep 2014 08:25:43 -0800
From: Melinda Shore <melinda.shore@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: trans@ietf.org
References: <540DFA75.2040000@gmail.com> <540E0E90.1070208@bbn.com> <4B184DAD-3C7A-4032-8BA6-634736BB2689@paypal.com> <540F3B42.3000708@bbn.com> <CABrd9SS4NgJo8mX72fB_9q4u8jQ5NQYsyk5hxPZvXxyfERvvcg@mail.gmail.com> <54107771.501@bbn.com>
In-Reply-To: <54107771.501@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/KKJz31ZuRha4dxQ7hanoKoLyzKc
Subject: Re: [Trans] Precertificate format
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Sep 2014 16:25:57 -0000

On 9/10/14 8:08 AM, Stephen Kent wrote:
> As I noted earlier, there is no threat model for the CT mechanism.
> 
> And there is no mapping of CT to the threat model.
> 
> We usually do not standardize security mechanisms when these two
> critical elements are missing.

Steve, I think this is a bit of an overstatement of the role of
thread models in the process.  The IETF has recently fallen into
a few process habits that aren't supported by any formal changes.
Some are good, some are awful.  The development of threat models
and discussion of a given mechanism within the framework of a threat
is a good process habit and one we'd encourage, but is not necessarily
required.

As an aside, I'd be grateful if tone could be ratched back a notch.
It's not just that we're working cooperatively to produce a document
and a combative tone makes it more difficult to reach agreement,
but that there's been concerned expressed within the IESG that
harshness and/or combativeness can drive away new participants and
people who'd otherwise be willing to do work.  You're raising good
points and they need to be addressed, but it would be better if they
were expressed in a way unlikely to put their recipients into a
defensive posture.

Thanks,

Melinda