Re: [secdir] Recurring issues found during sec review

Paul Wouters <paul@nohats.ca> Tue, 23 July 2019 14:14 UTC

Return-Path: <paul@nohats.ca>
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 C90B4120375 for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 07:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 KSlzcbcMqTtV for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 07:14:17 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE30120374 for <secdir@ietf.org>; Tue, 23 Jul 2019 07:14:16 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45tL7p6fxpzDjy; Tue, 23 Jul 2019 16:14:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1563891254; bh=+TBZQzV6SGVgciFTsaibiVZWVR0TqK3ToIfrjqOyuxI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pl0OJziIlNd8Ko+/0R5ElggMweWuKIAH6n4fO/p7raSspFJGIk0E6sDTzTy+l4MLD 45OtbQU9cXEg06ZIhbdsuNWAhik9ZfKvL7GxWgFmQjRlUO9sqebFpkq43xRoPQZU1F Ek6qLphb9qha0Gl2uD0Tc+LupaCPD85HT5F6o2/M=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id lH2xbmGd7Dde; Tue, 23 Jul 2019 16:14:13 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 23 Jul 2019 16:14:12 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B47AC3159D2; Tue, 23 Jul 2019 10:14:11 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B47AC3159D2
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AAB7B406FE60; Tue, 23 Jul 2019 10:14:11 -0400 (EDT)
Date: Tue, 23 Jul 2019 10:14:11 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: Alan DeKok <aland@deployingradius.com>
cc: Roman Danyliw <rdd@cert.org>, secdir <secdir@ietf.org>
In-Reply-To: <BAB87450-CF8C-4AB2-89C6-1578C4E8C273@deployingradius.com>
Message-ID: <alpine.LRH.2.21.1907231009140.16355@bofh.nohats.ca>
References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <BAB87450-CF8C-4AB2-89C6-1578C4E8C273@deployingradius.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/uYdFTf2tC-rcIn9q-0KScDIUy8E>
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:14:26 -0000

On Tue, 23 Jul 2019, Alan DeKok wrote:

>  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.

Right. In our terms that would be more in the sense of, the client MUST
send X. If the server receives a request without X, it MUST do z.

That is, every MUST should have an obvious action for when it is
violated.

And we have the weaker version with SHOULD. For every SHOULD in the
document, the authors should have at least one example of where the
SHOULD case exception is valid. If they cannot come up with that
exception, the SHOULD should be a MUST.

In a way, this process is running a fuzzer against your proposed
specification.

Paul