Re: [secdir] [Cbor] Secdir telechat review of draft-ietf-cbor-sequence-01

Carsten Bormann <cabo@tzi.org> Wed, 25 September 2019 15:56 UTC

Return-Path: <cabo@tzi.org>
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 D274E120803; Wed, 25 Sep 2019 08:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 oZ9tg1Ip2Ucu; Wed, 25 Sep 2019 08:56:23 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8351207FF; Wed, 25 Sep 2019 08:56:23 -0700 (PDT)
Received: from [192.168.217.110] (p548DCE50.dip0.t-ipconnect.de [84.141.206.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 46djN56ngTzyWj; Wed, 25 Sep 2019 17:56:21 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <42c37ccd-1660-1efd-5fa5-80f174a80d4d@verizon.net>
Date: Wed, 25 Sep 2019 17:56:21 +0200
Cc: Stephen Kent <kent@alum.mit.edu>, draft-ietf-cbor-sequence.all@ietf.org, cbor@ietf.org, ietf@ietf.org, secdir@ietf.org
X-Mao-Original-Outgoing-Id: 591119776.336159-3ff95f9da7cf5a485cfabb0000f39978
Content-Transfer-Encoding: quoted-printable
Message-Id: <C71D720E-FD4B-495A-85C4-965113A4FCDA@tzi.org>
References: <156779251575.21899.11186203310854403491@ietfa.amsl.com> <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org> <42c37ccd-1660-1efd-5fa5-80f174a80d4d@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/KkgTLKWJZj6fOKJ3UXWxhGEY5dw>
Subject: Re: [secdir] [Cbor] Secdir telechat review of draft-ietf-cbor-sequence-01
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: Wed, 25 Sep 2019 15:56:37 -0000

On Sep 25, 2019, at 16:12, Stephen Kent <stkent=40verizon.net@dmarc.ietf.org> wrote:
> 
> Carsten,
>> Hi Stephen,
>> 
>> thank you for this review.
>> 
>> On Sep 6, 2019, at 19:55, Stephen Kent via Datatracker <noreply@ietf.org> wrote:
>>> The second paragraph of the Security Considerations section reminds the
>>> reader that decoders (parsers) ought to be designed with the understanding that
>>> inputs are untrusted ??? good advice. I???d be happier if the final sentence
>>> changed ???must??? to ???MUST??? to reinforce this admonition.
>> Here I have a question: It seemed to me that we generally try to avoid putting BCP14 keywords into security considerations sections ??? after all, the interoperability requirements should be handled in the actual protocol definition, not in the security considerations after the fact.
> I am not aware of the convention you mention re BCP 14 keywords in the Security Considerations section. I'm pretty confident that I have seen the use of such keywords in other SC section sin the past
>> This MUST would be an implementation requirement.  Is this something we want to do in a security considerations section?  RFC 3552 appears to be silent about this.
> 
> I don’t think 3552 makes a statement on this topic either way.

Thank you, so I have submitted -02 with a MUST in the final sentence.

Grüße, Carsten