Yep, just put that explanation in the security considerations and I'm happy! -Tim > -----Original Message----- > From: Thomas Fossati <thomas.fossati@xxxxxxxxxx> > Sent: Saturday, September 28, 2024 5:53 PM > To: Tim Hollebeek <tim.hollebeek@xxxxxxxxxxxx> > Cc: secdir@xxxxxxxx; draft-ietf-rats-eat-media-type.all@xxxxxxxx; last- > call@xxxxxxxx; rats@xxxxxxxx > Subject: Re: Secdir last call review of draft-ietf-rats-eat-media-type-10 > > 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
<<attachment: smime.p7s>>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
