[Teep] Use of AES-CTR in TEEP?

[Dave Thaler <[e-mail]>]

In the TEEP WG, I believe we had consensus to reuse profiles from draft-ietf-suit-mti
in the TEEP protocol (not just for SUIT manifests).

draft-ietf-suit-mti recently replaced the use of GCM with AES-CTR, and Ken filed
https://github.com/ietf-teep/teep-protocol/issues/356
accordingly, proposing replacing GCM with AES-CTR in TEEP, which we discussed at
the interim last month.  The minutes say at
https://datatracker.ietf.org/meeting/interim-2023-suit-01/materials/minutes-interim-2023-suit-01-202309111500-00:

> Noting: #356, there are no objections to replacing each of them.
> Brendan: for the use case of SUIT (TEEP+RATS), using AES-CTR makes
> sense, but in general, this is not the right mode.
> * https://mailarchive.ietf.org/arch/msg/cose/9smwFXNpbd6Fci8-mIeaT2xPP-E/
> * https://mailarchive.ietf.org/arch/msg/cose/0Dj5yp4mptZUBiw7FWb5PcXGJAg/
> RH: APIs are not supposed to return any plaintext if the integrity check
> fails, so the ability to break the image into chunks is an important
> aspect, so that's why it does not fit into AES-GCM.

However, in a discussion with Hannes this week, he said
> We should not use AES-CTR mode in TEEP. The registration of AES-CTR / AES-CBC in COSE was done
> to support low-end IoT devices that use flash memory. It is not an algorithm that should be used in
> other places where not needed. I don't see a use case for it in TEEP

I look to others to provide guidance here... should we
a) make TEEP and SUIT diverge so that a TEEP implementation has to implement two different things
b) use AES-CTR in TEEP
c) add GCM back to suit-mti
d) something else because Dave is confused :)

Dave