Re: [dsfjdssdfsd] what not to do...

travis+ml-dsfjdssdfsd@subspacefield.org Wed, 02 April 2014 16:19 UTC

Return-Path: <travis+ml-dsfjdssdfsd@subspacefield.org>
X-Original-To: dsfjdssdfsd@ietfa.amsl.com
Delivered-To: dsfjdssdfsd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD611A01E2 for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 2 Apr 2014 09:19:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, T_RP_MATCHES_RCVD=-0.01] 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 1zs_sbA1qXHV for <dsfjdssdfsd@ietfa.amsl.com>; Wed, 2 Apr 2014 09:19:32 -0700 (PDT)
Received: from nexus.subspacefield.org (nexus.subspacefield.org [64.156.192.208]) by ietfa.amsl.com (Postfix) with ESMTP id 481E31A02BE for <dsfjdssdfsd@ietf.org>; Wed, 2 Apr 2014 09:19:32 -0700 (PDT)
Received: by nexus.subspacefield.org (Postfix, from userid 1001) id 4CE223F756; Wed, 2 Apr 2014 09:19:28 -0700 (PDT)
Date: Wed, 2 Apr 2014 09:19:28 -0700
From: travis+ml-dsfjdssdfsd@subspacefield.org
To: Alexandre Anzala-Yamajako <anzalaya@gmail.com>
Message-ID: <20140402161928.GC276@subspacefield.org>
Mail-Followup-To: Alexandre Anzala-Yamajako <anzalaya@gmail.com>, Watson Ladd <watsonbladd@gmail.com>, Donald Eastlake <d3e3e3@gmail.com>, "dsfjdssdfsd@ietf.org" <dsfjdssdfsd@ietf.org>, Sandy Harris <sandyinchina@gmail.com>
References: <533AF317.5070901@cs.tcd.ie> <CACXcFm=ts6JWuW+pQtaqZ720QDxnEa22UZW2NiBYMgCCV7MPuw@mail.gmail.com> <CAF4+nEF8N5C7zmGh5TBnp29zP1Fi2PMzoU4x4EEH8hY82PnS0w@mail.gmail.com> <CACsn0c=x3K3NDHve3sKvaFuk_08Xp+wepPN=nkj00bLKNyOK0A@mail.gmail.com> <CAHE9jN0AZ6f_PpEn5CsZGHi8q_xmv6+1G7PjS4vsrjdOCXUOUg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR"
Content-Disposition: inline
In-Reply-To: <CAHE9jN0AZ6f_PpEn5CsZGHi8q_xmv6+1G7PjS4vsrjdOCXUOUg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dsfjdssdfsd/a_lVpq1AuTayUsv5dm0jCzZTA1A
Cc: Donald Eastlake <d3e3e3@gmail.com>, Watson Ladd <watsonbladd@gmail.com>, Sandy Harris <sandyinchina@gmail.com>, "dsfjdssdfsd@ietf.org" <dsfjdssdfsd@ietf.org>
Subject: Re: [dsfjdssdfsd] what not to do...
X-BeenThere: dsfjdssdfsd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <dsfjdssdfsd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dsfjdssdfsd/>
List-Post: <mailto:dsfjdssdfsd@ietf.org>
List-Help: <mailto:dsfjdssdfsd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dsfjdssdfsd>, <mailto:dsfjdssdfsd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Apr 2014 16:19:37 -0000

On Wed, Apr 02, 2014 at 05:48:57PM +0200, Alexandre Anzala-Yamajako wrote:
> In a world where everybody would only do what they qualified for and know
> when to call for help I would agree with you but I think you underestimate
> how many well meaning people would consider that sampling the system clock
> is "unpredicatble enough".
> Listing all the ways you could mess things up is obviously a lost cause but
> naming a few bad ideas serves as a good cautionary tale IMO

I always thought that many proscriptive and prohibitive lists lack
rationale, and so a few words as to why you should not do X and Y are
worthy of inclusion.  The risk with this is that the developer thinks,
"ah, but these do not apply in my case!".  Therefore, you should
include a few examples that are so obscure that the developer would
not have thought of them (so as to humble them intellectually), and
indicate that your lists are not exhaustive, to avoid making them feel
so smart that they can ignore your warnings. IMHO.

When it comes to security, ignorance and hubris combined seem to be
the top risk, and so it helps to demonstrate to the dev that things
are not as simple as they seem right off the bat.  That is best done
by way of seemingly reasonable examples of previous attempts and how
they failed.  Lead them down a "safe" path and spring the trap on them
once, and you have a much better chance of being listened to.
-- 
http://www.subspacefield.org/~travis/
Remediating... LIKE A BOSS