adding non-normative guidance on when not to use EAT/UCCS media types

[gmandyam]

To address https://github.com/ietf-rats-wg/draft-eat-mt/issues/17

[laurencelundblade]

I'm not really in favor of this PR.

It seems like a general problem with all media types, not specific to attestation.

Also, it seems like the key thing here is that if an RP needs an attestation, they require it and don't render their service if they don't get it. If someone has a middle box blocking services, they probably should find another ISP or work at a different company or lobby to have the middle box fixed rather than requiring the service playing around with media types.

[gmandyam]

It seems like a general problem with all media types, not specific to attestation.

It is a general problem for new media types in that there is a time period usually between when the media type is approved/introduced and when all non-hostile filtering middleboxes adjust their rules to allow the types to to through (or not if that is the adjusted policy). But the attestation media types specifically identify the payload as being security critical - which could make them a target for MITM.

Also, it seems like the key thing here is that if an RP needs an attestation, they require it and don't render their service if they don't get it. If someone has a middle box blocking services, they probably should find another ISP or work at a different company or lobby to have the middle box fixed rather than requiring the service playing around with media types.

That works if the attester/RP is aware of the intercepting middlebox and/or has some ability to influence it (or as you mentioned, switch ISP's or employers). For some that may not be so easy - see https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_attack.

[thomas-fossati]

It is a general problem for new media types in that there is a time period usually between when the media type is approved/introduced and when all non-hostile filtering middleboxes adjust their rules to allow the types to go through

The problem is that this text will stay forever in the published RFC, but the situation it is trying to remedy is only temporary.

[gmandyam]

The problem is that this text will stay forever in the published RFC, but the situation it is trying to remedy is only temporary.

I can drop the text on content filtering middleboxes ("For instance, content filtering middleboxes may block or drop unknown media types, and if this is occuring this may not be detected by the endpoints of an attestation protocol."). The remaining text on MITM is still applicable in my opinion.

[laurencelundblade]

I kind of still think the same thing -- this is a general problem, not an EAT or RATS problem; it should be addressed in a general media type BCP or such.

I'd also would like to see a little more broad support and commentary on this.

[thomas-fossati]

I kind of still think the same thing -- this is a general problem, not an EAT or RATS problem; it should be addressed in a general media type BCP or such.

There is a vast literature on middlebox interference both in the RFC corpus (e.g., RFC 3234, 9065, 8558) and the IETF at large (draft-thomson-tmi, draft-hildebrand-middlebox-erosion to mention just a couple of draft efforts, let alone the many and insanely long threads on multiple IETF mailing lists over the years).

This is all well-known and documented.

Specifically, the risk is not new and is not introduced by these media types.

I'd also would like to see a little more broad support and commentary on this.

I have tried to elicit comments from other RATSers on multiple occasions and in different venues. If no one chimed in, it's probably because they don't reckon this to be a problem that needs to be solved here.

[gmandyam]

No consensus, so closing PR.