Hi Tim, Thanks for reviewing the draft, and for the feedback, much appreciated! On Fri, 27 Sept 2024 at 22:38, Tim Hollebeek via Datatracker <noreply@xxxxxxxx> wrote: > 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. At present, the draft lacks that kind of considerations because there is no extra attack surface that is introduced by these types. Changing "application/eat+cwt; eat_profile=1.2.3" into "application/eat+cwt; eat_profile=3.2.1" is not different from changing "application/foo" into "application/bar". Media types are just hints to the processing application. The latter is in charge of checking that the received payload is as expected. Typically, EAT messages are signed, so they are not malleable. When using UCCS, the required guarantees are moved to the outer secure channel, and those are already excruciatingly detailed in that draft. So, pointing at the parent documents seemed to us like a sensible approach. I have surveyed a few related RFCs to see if/how the argument is treated (RFC9110, RFC9112, BCP56, RFC7252) but I couldn't find anything relevant, except in section 8.3 of RFC9110, which has, related to the risks of confusion arising from using “MIME sniffing” techniques, the following: “[…] drawing incorrect conclusions about the data, which might expose the user to additional security risks (e.g., privilege escalation)”. Should we add something similar? One thing that your comment about potential cross-protocol risks made me think of is the fact that in EAT, "A profile can apply to evidence or to attestation results or both." (last para of Section 6). But again this is (cross-protocol) attack surface that is intrinsic in EAT profiles rather than being enabled by the EAT media types. cheers, thanks t -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
