Re: [secdir] Recurring issues found during sec review

Alan DeKok <aland@deployingradius.com> Tue, 23 July 2019 14:08 UTC

Return-Path: <aland@deployingradius.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 1DADF12028A for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 07:08:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dO0KVWRUOC-j for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 07:08:17 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFD812030C for <secdir@ietf.org>; Tue, 23 Jul 2019 07:07:59 -0700 (PDT)
Received: from [192.168.20.169] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 89DAC2E12; Tue, 23 Jul 2019 14:07:57 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand>
Date: Tue, 23 Jul 2019 10:07:55 -0400
Cc: secdir <secdir@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BAB87450-CF8C-4AB2-89C6-1578C4E8C273@deployingradius.com>
References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/GJDRVL7gqW_CO40vf8gOTsuXz-s>
Subject: Re: [secdir] Recurring issues found during sec review
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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, 23 Jul 2019 14:08:20 -0000

On Jul 23, 2019, at 9:46 AM, Roman Danyliw <rdd@cert.org> wrote:
> 
> Hi!
> 
> As an IESG initiatives, each of the areas is pulling together a list of "recurring issues" found by their areas during area review (e.g., secdir, iotdir, genart, opsdir, tsvart) and IESG review.  The intent is to provide informal, but not comprehensive, guidance to draft authors and their WG chairs with the intent to find issues earlier.  Ben and I made the following initial list:
> 
> https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues

  One issue I don't see covered is "what happens when things go wrong?"  This isn't quite "Broken Constraints", but it's close.

  The temptation is to describe how things *should* work.  But that isn't good enough.  In the real world, we need to describe how to handle the failure conditions, too.

  When specifications says "When a server receives X, it does Y", what happens when the server *doesn't* receive X?

  What does it do?  How are errors handled?

  Saying "When X do Y" is very much an "if" condition, even though it is not phrased as such.  The solution is to about handle the "else" case to every "if", as with the following example:

	IF a server receives X
	THEN
		do Y
	ELSE
		do something else

  IIRC, the above behaviour is required in medical software.  "No IF without an ELSE".  I believe it should be required for protocol specifications, too.

  As an implementor, I can't count the number of times I've run into this issue.  Reading the specification is nice, but it doesn't give me enough information to create a robust implementation.  That experience has influenced the standards I write, so they pretty much all have an "else" for every "if".  And it's a repeated comment I have for documents I review.

  Alan DeKok.