Subject: [Last-Call] Secdir last call review of draft-ietf-cbor-7049bis-14

From: Yaron Sheffer via Datatracker <[email-masked]>
Date: Mon, 10 Aug 2020 02:00:55 -0700

Reviewer: Yaron Sheffer
Review result: Has Nits

This is an editorial, fully compatible update of RFC 7049 (the CBOR encoding).

The Security Considerations have been significantly expanded, and they make
sense to me. However, while the prose is all sensible, it doesn't seem like the
best practical guidance for implementers. I would have appreciated a bullet
list of potential implementation pitfalls, as well as a bullet list of decoder
validation capabilities, such as are alluded to by the last sentence of the
section. Upon a quick read, it is not even clear to me which parts of Sec. 5
are required/expected in a validating-mode decoder.

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 10 Aug 2020 12:24:55 -0700

On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker <[email-masked]> wrote:
> 
> Upon a quick read, it is not even clear to me which parts of Sec. 5

A generic decoder can do as little or as much validity checking as it wants to. What is required is that it documents what validity checking it does not do and that it does not prevent the user of the generic decoder from doing the validity checks.

The reason for this is that some validity checking is expensive for a CBOR decoder and is inexpensive for the consumer of the data. Checking the validity of UTF-8 or MIME-encoded messages are examples of this.

LL

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 10 Aug 2020 23:24:44 +0300

LL

I understand that, but realistically, without a list of (potential) validity checks in the RFC, there will be wide variance in what is documented by decoders – if any. In fact I checked a few implementations just now, and most of them do not document what validity checks they perform. Those that document something are hard to compare. If you make a canonical list, people would have a starting point.

Thanks,

                Yaron

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 10 Aug 2020 13:31:25 -0700

> On Aug 10, 2020, at 1:24 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> On Aug 10, 2020, at 2:00 AM, Yaron Sheffer via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>>  

Having made a few crude lists of validity checks myself to try to understand what was what, such a list seems reasonable to me.

LL

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Aug 2020 00:45:24 +0200

> I understand that, but realistically, without a list of (potential) validity checks in the RFC, there will be wide variance in what is documented by decoders – if any. In fact I checked a few imple…

To be fair, you probably checked RFC 7049 implementations, and RFC 7049 didn’t have such a requirement (improving the discussion of validity was one of the major work items in 7049bis, see Appendix G.3).

One point to keep in mind is that, with CBOR, most validity processing happens in the processing of tags, and that is an extension point.  So a list in 7049bis will never be complete.  Even if it only covers base CBOR and the tags registered in 7049/7049bis, a detailed version is likely to be tedious and highly dependent of specific implementation approaches.

Trying to imagine the outcome of this exercise, my visual image right now is a PICS Proforma, so I think I’ll better stop here...

Grüße, Carsten

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 11 Aug 2020 22:14:39 +0300

Grüße, Carsten

Hi Carsten,

You are addressing this issue from the point of view of a spec writer, I suggest you take the POV of the implementer, the user of a decoder. Those people are not CBOR experts, and when faced with free-form and probably terse documentation of a decoder's validity checking would never know what they need to consider to add as application-level checking.

I realize that tags are an extension point, but if we are to avoid decoding-related vulnerabilities, I suggest you list validity checks for the base CBOR and tags in RFC7049+bis.

Thanks,
	Yaron

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Aug 2020 01:24:01 +0200

On 2020-08-11, at 21:14, Yaron Sheffer <[email-masked]> wrote:
> You are addressing this issue from the point of view of a spec writer, I suggest you take the POV of the implementer,

I took the view of the implementer of a generic decoder (which I happen to also be IRL), faced with a PICS Proforma.

Just in case that term doesn’t already send you running for the hills, there are some standards that come with a [not so] little word document that you are supposed to fill in to describe what your implementation of that standard really does.

> the user of a decoder. Those people are not CBOR experts, and when faced with free-form and probably terse documentation of a decoder's validity checking would never know what they need to consider to add as application-level checking.

I certainly can agree with that.  Still, I would like to learn about other places where IETF has done something like that, so we can learn from those efforts.

> I realize that tags are an extension point, but if we are to avoid decoding-related vulnerabilities, I suggest you list validity checks for the base CBOR and tags in RFC7049+bis.

Would that also be a good thing for a separate document, possibly including more tags?

Grüße, Carsten