Re: I-D Action: draft-thomson-postel-was-wrong-01.txt

Joe Touch <touch@isi.edu> Fri, 23 June 2017 17:36 UTC

Return-Path: <touch@isi.edu>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A83B129AA4 for <ietf@ietfa.amsl.com>; Fri, 23 Jun 2017 10:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 FZ53mdgE0xgz for <ietf@ietfa.amsl.com>; Fri, 23 Jun 2017 10:36:13 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3587129601 for <ietf@ietf.org>; Fri, 23 Jun 2017 10:36:13 -0700 (PDT)
Received: from [128.9.184.92] ([128.9.184.92]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v5NHZbje013532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 23 Jun 2017 10:35:38 -0700 (PDT)
Subject: Re: I-D Action: draft-thomson-postel-was-wrong-01.txt
To: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>, Petr Špaček <petr.spacek@nic.cz>, "ietf@ietf.org" <ietf@ietf.org>
References: <149727416998.10345.14056211125888203672@ietfa.amsl.com> <20170613033859.GA71771@shrubbery.net> <0658C4E3DBD74293BF3A2CBB@PSB> <20170613142820.GA21291@shrubbery.net> <a9a32f87-825f-090a-44d4-7fb129771f02@huitema.net> <7c762c83-2c94-f46f-e8bc-a18e7887d714@isi.edu> <db4218d7-59b4-7dd8-2cf6-ed9673960cac@nic.cz> <4d1f6a3f-dab9-41a3-7302-bd87a519bbb9@isi.edu> <f69679ba-f69c-b063-943f-6994489c526d@nic.cz> <2b8c3aca-d6f8-e778-3da3-80d2b4e1598b@isi.edu> <8e8d4db9-93fd-5092-68de-6d8de44151c3@nic.cz> <c9202a09-af8b-faf6-b583-694378022dae@isi.edu> <B31EEDDDB8ED7E4A93FDF12A4EECD30DE636B715@GLKXM0003v.GREENLNK.net>
From: Joe Touch <touch@isi.edu>
Message-ID: <d0c4ecc7-1fe9-fc0b-bbe5-8cffb956b6ed@isi.edu>
Date: Fri, 23 Jun 2017 10:35:36 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <B31EEDDDB8ED7E4A93FDF12A4EECD30DE636B715@GLKXM0003v.GREENLNK.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/GCxJSgkauwWLXm0NgGqOf4qGtgw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Jun 2017 17:36:15 -0000


On 6/23/2017 2:25 AM, Dearlove, Christopher (UK) wrote:
> Joe Touch wrote:
>> Liberal means that if it's possibly valid, you should accept it as such.
> That necessitates the protocol designer explicitly flagging some things as invalid. 
That's quite typical. Many protocols clearly indicate explicit invalid
cases.

> Obvious example is a should be signed message lacking a signature. If taking the most liberal view (as above) the protocol needs to say something like "if the signature is missing or invalid, then the message must be rejected". I don't think that's anything new, I've seen it done.
>
> I can see at least the following cases where making intent clear is, in my opinion at least, a good idea:
> - Security and other sensitive cases of failure. Need to say explicitly reject.
When not specified, "silently ignore" is another option.

> - Mechanisms designed for extensions. While the Postel principle makes it unnecessary to say so, it really doesn't hurt saying that a message shouldn't be rejected just for this reason.
Agreed.
> - Where what you receive is a container of multiple things (messages in a packet, TLVs in a message). Making the assumed dependence/independence clear doesn't hurt (if rejecting/ignoring one, does this impact on the others?).
>
> That's not something that spirals out of control in size, a couple of sentences would cover most cases.
Right - the Postel Principle isn't a license to be lazy in either a
protocol spec or implementation.

Joe