Re: [secdir] Recurring issues found during sec review

Alan DeKok <aland@deployingradius.com> Tue, 23 July 2019 15:05 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 93F2012039E for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 08:05:40 -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 ruQHNDJptZwK for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 08:05:39 -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 02CAF1202F3 for <secdir@ietf.org>; Tue, 23 Jul 2019 08:05:28 -0700 (PDT)
Received: from [192.168.20.169] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 5B8D41A64; Tue, 23 Jul 2019 15:05:25 +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: <alpine.LRH.2.21.1907231009140.16355@bofh.nohats.ca>
Date: Tue, 23 Jul 2019 11:05:23 -0400
Cc: Roman Danyliw <rdd@cert.org>, secdir <secdir@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com>
References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <BAB87450-CF8C-4AB2-89C6-1578C4E8C273@deployingradius.com> <alpine.LRH.2.21.1907231009140.16355@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/zaUwip-6dDaDlL1ZgXbKi8JMFlw>
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 15:05:47 -0000

On Jul 23, 2019, at 10:14 AM, Paul Wouters <paul@nohats.ca> wrote:
> 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.

  That's a good phrasing.

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

  I agree.

  Alan DeKok.