Skip to main content

IETF Last Call Review of draft-ietf-rats-msg-wrap-18
review-ietf-rats-msg-wrap-18-secdir-lc-schwartz-2025-10-06-00

Request Review of draft-ietf-rats-msg-wrap
Requested revision No specific revision (document currently at 23)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-10-13
Requested 2025-09-29
Authors Henk Birkholz , Ned Smith , Thomas Fossati , Hannes Tschofenig , Dionna Glaze
I-D last updated 2026-04-29 (Latest revision 2025-12-11)
Completed reviews Iotdir Early review of -04 by Mohit Sethi (diff)
Secdir IETF Last Call review of -18 by Benjamin M. Schwartz (diff)
Genart IETF Last Call review of -19 by Peter E. Yee (diff)
Assignment Reviewer Benjamin M. Schwartz
State Completed
Request IETF Last Call review on draft-ietf-rats-msg-wrap by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/QMqJHFL21FmVqSV-Wt2AgA2pprk
Reviewed revision 18 (document currently at 23)
Result Has nits
Completed 2025-10-06
review-ietf-rats-msg-wrap-18-secdir-lc-schwartz-2025-10-06-00
Clear document describing some serialization formats.

Notes:

Section 3.1:

* The "ind" field is defined as a 32-bit bitfield of types.  This constraint on
the range of expressible message types seems hard to justify.  In the common
case, a short list of small integers would be almost as compact (in CBOR), and
in the extreme case (32 message types), the proportional savings of using a
bitfield is presumably minimal compared to the messages themselves.  This seems
like a case of trying to save 1 byte, at the cost of considerably reduced
flexibility for extensions (especially experimental or private extensions). 
And in some cases, the bitfield representation is actually _less_ compact. *
Also, the description says "Only four values are registered", but the
definition of `cm-type` shows 5 values.

Section 3.4:

* It seems like this text is recommending sending JSON or CBOR in a shared
container, with the recipient disambiguating them based on the first byte.
  - It's not clear what the motivating use case is for this algorithm.
  - This is a risky design.  Parsers developed in JSON-only or CBOR-only
  ecosystems may sensibly omit the unused format, leading to misbehaviors when
  they are used with other format. - The proposed disambiguation is different
  from the one proposed in the CBOR specification (see
  https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4.6-4,
  https://www.rfc-editor.org/rfc/rfc9277.html#section-2.2) - Unless there is a
  compelling reason, it would seem safer to treat JSON and CBOR consistently as
  distinct media types, distinguished by an indicator in the upper layer (as is
  done in Section 4.4 for X.509).

Section 10.5
* The IANA registry is given as "expert review", but the instructions to the
expert effectively make the policy equivalent to Standards Action (or perhaps
even stricter!).  IMHO it should be changed to Standards Action.  (A
non-bitfield representation would allow a much more relaxed registration
policy.)