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

From: Stephen Kent via Datatracker <[email-masked]>
Date: Fri, 06 Sep 2019 10:55:15 -0700

Reviewer: Stephen Kent
Review result: Ready

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.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 Sep 2019 15:04:50 +0200

Hi Stephen,

thank you for this review.

On Sep 6, 2019, at 19:55, Stephen Kent via Datatracker <[email-masked]> wrote:
> 
> The second paragraph of the Security Considerations section reminds the

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

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 25 Sep 2019 14:23:44 +0100

Hi Carsten,

On Wed, Sep 25, 2019, at 2:04 PM, Carsten Bormann wrote:
> 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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 25 Sep 2019 10:12:09 -0400

Carsten,
>> 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.

Steve

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 25 Sep 2019 17:56:21 +0200

On Sep 25, 2019, at 16:12, Stephen Kent <stkent=[email-masked]> wrote:
> 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
> 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