Last Call Review of draft-ietf-rats-eat-media-type-10
review-ietf-rats-eat-media-type-10-secdir-lc-hollebeek-2024-09-27-00

Request Review of draft-ietf-rats-eat-media-type
Requested revision No specific revision (document currently at 12)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2024-10-10
Requested 2024-09-26
Requested by Deb Cooley
Authors Laurence Lundblade , Henk Birkholz , Thomas Fossati
I-D last updated 2025-05-27 (Latest revision 2024-11-03)
Completed reviews Genart IETF Last Call review of -10 by Christer Holmberg (diff)
Secdir IETF Last Call review of -10 by Tim Hollebeek (diff)
Artart IETF Last Call review of -11 by Yoshiro Yoneya (diff)
Iotdir IETF Last Call review of -10 by Jouni Korhonen (diff)
Assignment Reviewer Tim Hollebeek
State Completed
Request IETF Last Call review on draft-ietf-rats-eat-media-type by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/N0AKouwEp6xmSpfM2e_OvmqIDTc
Reviewed revision 10 (document currently at 12)
Result Has issues
Completed 2024-09-27
review-ietf-rats-eat-media-type-10-secdir-lc-hollebeek-2024-09-27-00
This is really "has issue" rather than "has issues".

The draft is pretty simple and straightforward, and provides MIME types that
correspond to the URI or OID that's in the payload, so that the payload doesn't
have to be inspected to determine what EAT type it is. This is all fine.

However, I think the security considerations section needs a discussion of what
happens when the MIME type on the request DOES NOT correspond correctly to the
URI or OID that's in the payload. Failure to correctly handle that case could
lead to cross-protocol attacks against other token types, and so on, so I think
some discussion or advice is necessary, even if it is to simply point out why
this isn't a concern, or which portion of the document handles this that I
missed.

-Tim