[Cbor] Re: Minor comments on draft-lenders-dns-cbor-10

[Alan DeKok <[e-mail]>]

On Nov 26, 2024, at 8:00 AM, Martine Sophie Lenders <[e-mail]> wrote:
> thanks for the hint. If we keep that piece of pseudocode, we try to keep this in mind. However, currently we are discussing to tweak the definition of name compression a bit, so that we can just use Packed CBOR semantics and references, see [1].

  Thanks.  While the packed CBOR semantics are substantially more complex than the method outlined in draft-lenders-dns-cbor, there is substantial benefit to using a common packing format.

> [1] https://github.com/anr-bmbf-pivot/draft-lenders-dns-cbor/pull/7

  After reviewing that document, my comments about draft-lenders-dns-cbor are also applicable to https://datatracker.ietf.org/doc/html/draft-ietf-cbor-packed

  Specifically, Section 2.5 discusses loops:

...
In general, loop detection can be handled in a similar way in which loops of symbolic links are handled in a file system: A system-wide limit (often set to a value permitting some 20 to 40 indirections for symbolic links) is applied to any reference chase. NOTE: The present specification does nothing to help with the packing of CBOR sequences [RFC8742]; maybe such a specification should be added.
...

  I don't think there is a need for ad hoc loop detection.  The only necessary requirement is that all references point backwards.  With that constraint, loops are entirely eliminated.  Section 2.1 of draft-ietf-cbor-packed could be updated to discuss this.

  If the tables are constructed dynamically as the CBOR is parsed, then the only requirement is that any new reference points to an existing table entry.  If a reference points outside of the table, then the reference is invalid.

  Once a reference has been validated, it can be added to the table as a new entry.  In this way loops are made impossible by construction, without any additional counters or loop detection at decode time.

  We then have a constraint on the contents of the table:

  e.g. for table entry "i", any references 'j" contained within that entry MUST satisfy the property that "j < i".

  This constraint is satisfied by construction by validating entries before inserting them into the table:

    Any packed cbor reference which is being decoded MUST refer to an entry which is already in the table.  New entries MUST NOT be inserted into the table until they pass this validation step.

    On encoding, the table is constructed in the same manner.  Entries are inserted into the table as they are encoded.

   The only way for the packed cbor to contain forward references is if the content is created maliciously.

   This construction also avoids the problem of exponential explosion in decoding.  It is not possible even manually to create packed cbor data of N entries which result in 2^N decoded strings.


  draft-ietf-cbor-packed also doesn't say what to do when the cbor references are invalid.  Is the entire cbor decoding discarded?

  Alan DeKok.