Skip to main content

Telechat Review of draft-ietf-cbor-sequence-01
review-ietf-cbor-sequence-01-secdir-telechat-kent-2019-09-06-00

Request Review of draft-ietf-cbor-sequence
Requested revision No specific revision (document currently at 02)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2019-09-17
Requested 2019-09-03
Authors Carsten Bormann
Draft last updated 2019-09-06
Completed reviews Secdir Telechat review of -01 by Stephen Kent (diff)
Genart Telechat review of -01 by Pete Resnick (diff)
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-cbor-sequence-01-secdir-telechat-kent-2019-09-06
Posted at https://mailarchive.ietf.org/arch/msg/secdir/X6YZuWAypEITxYkmy590yW_vDRM
Reviewed revision 01 (document currently at 02)
Result Ready
Completed 2019-09-06
review-ietf-cbor-sequence-01-secdir-telechat-kent-2019-09-06-00
SECDIR review of draft-ietf-cbor-sequence-01

The summary of the review is Ready, with one suggested edit.

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

The Abstract says that this short document describes the Concise Binary Object
Representation(CBOR) Sequence format and associated media type
"application/cbor seq". The document indicates that the motivation for this
extension of the base CBOR specification (RFC 7049) is to specify a format for
CBOR sequences, which allow incremental production and consumption of such
sequences while imposing minimal demands on a CBOR parser.

The Security Considerations section consists of just two, brief paragraphs. The
first says that the considerations of the base CBRO specification (RFC 7049)
apply, which seems reasonable. The Security Considerations section of that
document is well written. It discusses several types of potential
vulnerabilities associated with complex parsers, and notes that CBOR tries to
reduce the range of some type of attacks by striving to reduce parser
complexity.

This document notes that COSE (RFC 8152) can be employed if security services,
e.g., data integrity, are required. This too seems reasonable, since COSE
explicitly specifies mechanisms for offering such services for CBOR-formatted
data. 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.