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

"Alexey Melnikov" <aamelnikov@fastmail.fm> Wed, 25 September 2019 13:25 UTC

Return-Path: <aamelnikov@fastmail.fm>
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 B52C4120815; Wed, 25 Sep 2019 06:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Usihy0n2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WOFCliSt
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 qAoJUYjO2b_c; Wed, 25 Sep 2019 06:25:03 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4FFF120806; Wed, 25 Sep 2019 06:25:02 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2FC2A22454; Wed, 25 Sep 2019 09:25:02 -0400 (EDT)
Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Wed, 25 Sep 2019 09:25:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm1; bh=UJAP6 UQDuorci+7Lu3PR7JnCdceKGEgubyfiecHczyo=; b=Usihy0n22H5d0EYSIue/P v1+se0GjpJFOFoxbNv5IhK4O6ReyuG7nZ3u+MQFfOIUOZB/9heI8ODrsv+/CcntP lVTr//vmEh8sA2ajzayKYkt2CWhLYqJ8VCdnjevWavoSEZIqWJ3nhw1qZao+KvyW xiLnBA6As1NQ2ugwvmMkoN2iYjE5E+Vgg8RWnaAjTNs+dgo8yrR/i1eJAR2XLa8V l5IEK6u37f0oWB6R7LL+DfuPGv2L6Q5RQfHwQfF2QhXc7I/Gdjb0yfe8hOENm7zH Pu4nFMuhoAZ86YFl9IzngtNN+AGY2uzCVkXKPxpElBTq/xnX+LxdHTAXMrzf58hC A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=UJAP6UQDuorci+7Lu3PR7JnCdceKGEgubyfiecHcz yo=; b=WOFCliSttrFICjOVP0+TqZy8EZqHJ1bZola+UDloZYIwYikqV5FQJ84lk jrxxTaac8rcLBz8tlV/0EG8ZLEAdg4yZbtcOCCej5VXa/xh303CTWLFx8HPSukqO /k2hGB83l2mmEjqoV4F95bDvp7ouJeQS3q6AXfkCZzpIPh5VuKG49gHJF/N5Hi7W pCCRDGE0gSH2T7qOTwbo6iDvzact1RRaf4j64V/hWXWpQzaLmS6fYCpmHRb3K1ly JgZYFA3AOBFUqIQHsnXBMWvTZ0+S76LqaILCIg3AAjIDkbRoxRSpN81lDXZoMcWy IzhiMva0lMbwKL+H68Hd8CqFVgDJw==
X-ME-Sender: <xms:rWqLXeuvx4uGDInOMihgvfpEXZm9XlpvAmp1hshKNsZM0iwIT3eB-A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfedvgdeigecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdetlhgv gigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrihhlrd hfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgrshht mhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:rWqLXUF5mkMkY2KdEFj4lLspB5QQ8hN2Mg_VVRLWdbjRwDpQdX6OFQ> <xmx:rWqLXU7WMw7RiqojJY2EhnLbXlF3CApA4dWdATENSL8nVSY0UAPkuQ> <xmx:rWqLXdxdL-0leqS-2npsFXQH1xOCdyCfjWl5w9Jskgos5Mq8RdJdQw> <xmx:rmqLXZzHsaBQShePzHlE-7wvRWGdVE09kC02fEiEwjj8tEnFEQaHgw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4D824C200A4; Wed, 25 Sep 2019 09:25:01 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-305-g4111847-fmstable-20190924v1
Mime-Version: 1.0
Message-Id: <59ca30ff-b521-4ab6-b792-a441b7ff2d20@www.fastmail.com>
In-Reply-To: <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org>
References: <156779251575.21899.11186203310854403491@ietfa.amsl.com> <9C5B6D0A-98DA-4A35-A8A9-ACA4FCDBB91F@tzi.org>
Date: Wed, 25 Sep 2019 14:23:44 +0100
From: "Alexey Melnikov" <aamelnikov@fastmail.fm>
To: "Carsten Bormann" <cabo@tzi.org>, "Stephen Kent" <kent@alum.mit.edu>
Cc: secdir@ietf.org, draft-ietf-cbor-sequence.all@ietf.org, ietf@ietf.org, cbor@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/GNKhwxETZGI3e_I_MdhU7raQRKI>
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:25:05 -0000

Hi Carsten,

On Wed, Sep 25, 2019, at 2:04 PM, Carsten Bormann wrote:
> 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 think use of RFC 2119 keywords in the Security Considerations is fine, as implementors should read the whole document. If a particular requirement is really important, it can be moved to a separate section and referenced in the Security Considerations.

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

Best Regards,
Alexey