IETF Logo Mail Archive

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

Carsten Bormann <cabo@tzi.org> Wed, 25 September 2019 13:04 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 A748312008A; Wed, 25 Sep 2019 06:04:54 -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=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 huV_UFRs5GZm; Wed, 25 Sep 2019 06:04:53 -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 C82BF1207FC; Wed, 25 Sep 2019 06:04:52 -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 46ddZC13Qgz10hj; Wed, 25 Sep 2019 15:04:51 +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: <156779251575.21899.11186203310854403491@ietfa.amsl.com>
Date: Wed, 25 Sep 2019 15:04:50 +0200
Cc: secdir@ietf.org, draft-ietf-cbor-sequence.all@ietf.org, ietf@ietf.org, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 591109489.016893-440eb0abb300bd43529d2eacdb563555
Content-Transfer-Encoding: quoted-printable
Message-Id: <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org>
References: <156779251575.21899.11186203310854403491@ietfa.amsl.com>
To: Stephen Kent <kent@alum.mit.edu>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/e78FLVNMaUl9LvEWc49WlppRi2w>
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 13:04:55 -0000

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.

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’m also asking this because we are in the process of revising RFC 7049, which would then raise the same question in its security considerations section.)

Grüße, Carsten

v2.23.0 | Report a Bug | By Email