Re: [secdir] Recurring issues found during sec review

Alan DeKok <aland@deployingradius.com> Tue, 23 July 2019 15:51 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 E308E120193 for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 08:51:15 -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 ZlMrHNgpbuWk for <secdir@ietfa.amsl.com>; Tue, 23 Jul 2019 08:51:13 -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 138681202D1 for <secdir@ietf.org>; Tue, 23 Jul 2019 08:51:13 -0700 (PDT)
Received: from [192.168.20.169] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id E291B7A2; Tue, 23 Jul 2019 15:51:10 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com>
Date: Tue, 23 Jul 2019 11:51:08 -0400
Cc: Paul Wouters <paul@nohats.ca>, secdir <secdir@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D8CC5F28-F176-4C51-B2D3-FF2505ABFB64@deployingradius.com>
References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <BAB87450-CF8C-4AB2-89C6-1578C4E8C273@deployingradius.com> <alpine.LRH.2.21.1907231009140.16355@bofh.nohats.ca> <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com>
To: "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/AwEZDM0vYDnZSPnTeaxTbUESrIg>
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:51:16 -0000

On Jul 23, 2019, at 11:15 AM, Salz, Rich <rsalz@akamai.com> wrote:
> 
> 
>> That is, every MUST should have an obvious action for when it is
>> violated.
> 
>      That's a good phrasing.
> 
> I strongly disagree.  It turns every MUST into something that only the recipient must act on.

  If one party MUST send X, then there's not really any benefit to saying "or else...".  That party sends X, or it's not compliant.  If that party ignores the MUST, then there isn't any point in having an extra clause that says "or else MUST do ...".  They'll just ignore that, too.

  The issue is with the other party.  If the other side MUST send X, then what does the recipient do when it doesn't receive X?  That should be stated clearly.

>  The burden of the protocol should be on both sides to act correctly, and one side should not be constrained to behave a particular way if the counter-party misbehaves.

  If it's about security, then absolutely one party should be constrained to do something *safe* if the other party misbehaves.

  Another example is sending packetized data over TCP.  i.e. sequences of "header, length, data".  What happens if the recipient can't decode a particular message?  I've seen long arguments where people say "the recipient should try to continue".

  OK... HOW?  If the header / length is malformed, then we have absolutely no clue how to decode the next set of octets we receive.  The only safe thing to do is to close the connection, and start over.  Hence phrases like "the recipient MUST close the connection if the message is malformed"

  I think the "else MUST" phrases really only apply to recipients.  They're not in control of the data that they receive.  And they must do *something* with that data.

  Perhaps the phrasing could be "if the sender MUST do X, then the recipient MUST be able to deal with situations where that doesn't happen".

> Another reason against this is that it tends to result in naïve behavior such as oracles or "name not found" being distinguished from "wrong password"

  I'm not clear how that applies.

  Alan DeKok.