Re: [Cbor] [Ext] Roman Danyliw's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)

Paul Hoffman <paul.hoffman@icann.org> Wed, 23 September 2020 19:30 UTC

Return-Path: <paul.hoffman@icann.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC5D3A13D8; Wed, 23 Sep 2020 12:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 n1JQcL5c9nF9; Wed, 23 Sep 2020 12:30:20 -0700 (PDT)
Received: from ppa5.dc.icann.org (ppa5.dc.icann.org [192.0.46.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6B83A13D6; Wed, 23 Sep 2020 12:30:20 -0700 (PDT)
Received: from MBX112-E2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.7]) by ppa5.dc.icann.org (8.16.0.42/8.16.0.42) with ESMTPS id 08NJUHL8011659 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Sep 2020 19:30:18 GMT
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-2.pexch112.icann.org (10.226.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.659.4; Wed, 23 Sep 2020 12:30:17 -0700
Received: from MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) by MBX112-W2-CO-1.pexch112.icann.org ([10.226.41.128]) with mapi id 15.02.0659.006; Wed, 23 Sep 2020 12:30:17 -0700
From: Paul Hoffman <paul.hoffman@icann.org>
To: Roman Danyliw <rdd@cert.org>
CC: The IESG <iesg@ietf.org>, "cbor@ietf.org" <cbor@ietf.org>
Thread-Topic: [Ext] Roman Danyliw's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)
Thread-Index: AQHWhirKr/CTcoQaikeVSmL9WFwddal3KPAA
Date: Wed, 23 Sep 2020 19:30:16 +0000
Message-ID: <4814348E-9469-46D6-B77A-4F193A14BD73@icann.org>
References: <159960212460.14731.6166470610948655056@ietfa.amsl.com>
In-Reply-To: <159960212460.14731.6166470610948655056@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: Processed
Content-Type: multipart/signed; boundary="Apple-Mail=_8747AA2F-3B0B-4655-A600-1E77BEFDFF22"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-23_10:2020-09-23, 2020-09-23 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/HTy9FYtmalhPp-1OmiFiFn8kfyk>
Subject: Re: [Cbor] [Ext] Roman Danyliw's No Objection on draft-ietf-cbor-7049bis-14: (with COMMENT)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2020 19:30:22 -0000

Thanks for your comments. Our notes are below.

--Paul Hoffman

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Ben Kaduk’s DISCUSS position.

We have dealt with that in a different thread.

> ** Section 1.0. Is it possible to enumerate the fixed errata?

It is possible, but does not seem important. They were issues in some examples.

> ** Section 3.4.5.3.  For Tag 35, how does one know if the syntax is a PCRE or
> ECMA regular expression?

Fixed earlier in response to Ben.

> ** Section 3.4.5.3.  PCRE is the only informative reference of all of the tags
> defined in this section (even ECMA is normative).  Please make it normative.

Fixed earlier in response to Ben.

> ** Section 4.1.  As an implementer of an application, what is the take away
> from this section?  I’m not following on the definition of “preferred”.

This section is signifying is that each application needs to specify which
serialization is being used for values with multiple serializations (such as
integer and bigint for the number "forty two"). It is not talking about a
universal preference, but one that each implementer needs to specify for their
particular application.


> ** Section 10.  Per “The input check itself may consume resources.  This is
> usually linear in the size of the input, which means that an attacker has to
> spend resources that are commensurate to the resources spent by the defender on
> input validation.”  I’m not sure this is true for all types of resources.  For
> example, with compute resources, as an attacker I can craft an input that will
> take longer for the target to process then for me to produce.

Good catch. We added text covering that.