Re: [Teep] Use of AES-CTR in TEEP?

Hi Dave, 

Let me clarify how my suggestion looks like. 

Section 3 of https://datatracker.ietf.org/doc/draft-ietf-suit-mti/ currently defines 5 profiles. 

I would like to have a new profile added that defines suit-sha256-es256-ecdh-a128gcm for use with TEEP.
This should be the default profile for use in TEEP.

This adds new requirements to constrained IoT devices. Constrained IoT devices should use one of the other 5 profiles already defined.

Ciao
Hannes

-----Original Message-----
From: TEEP <teep-bounces@ietf.org> On Behalf Of Dave Thaler
Sent: Montag, 9. Oktober 2023 17:14
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>; teep@ietf.org; suit@ietf.org
Subject: Re: [Teep] Use of AES-CTR in TEEP?

So you argue that we need multiple crypto algorithms mandatory in constrained devices?
I can't comment on specific algorithms, but I'm curious to know why the extra code space
is required.   Do others in the WG agree?

> -----Original Message-----
> From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> Sent: Monday, October 9, 2023 7:36 AM
> To: Dave Thaler <dthaler@microsoft.com>; TEEP@ietf.org; suit@ietf.org
> Subject: Re: [Teep] Use of AES-CTR in TEEP?
> 
> We should create two algorithm profiles, one for firmware updates of 
> IoT devices and another one for use with TA/config data update in TEEs.
> 
> 
> I believe these use cases are different enough to justify having two 
> algorithm profiles.
> 
> 
> Ciao
> 
> Hannes
> 
> 
> 
> Am 06.10.2023 um 18:29 schrieb Dave Thaler:
> > 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > th
> > ub.com%2Fietf-teep%2Fteep-
> protocol%2Fissues%2F356&data=05%7C01%7Cdthal
> >
> er%40microsoft.com%7C626557262f6c4d7e0b6808dbc8d50831%7C72f988bf86f
> 141
> >
> af91ab2d7cd011db47%7C1%7C0%7C638324589530894110%7CUnknown%7CT
> WFpbGZsb3
> >
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> %7
> >
> C3000%7C%7C%7C&sdata=lNxKlv26DY%2B8Drt%2BaXtkvEoKNiqiuK0m8xBGBM
> TS5SE%3
> > D&reserved=0 accordingly, proposing replacing GCM with AES-CTR in 
> > TEEP, which we discussed at the interim last month.  The minutes say 
> > at
> >
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> track
> er.ietf.org%2Fmeeting%2Finterim-2023-suit-01%2Fmaterials%2Fminutes-int
> erim-
> 2023-suit-01-202309111500-
> 00&data=05%7C01%7Cdthaler%40microsoft.com%7C626557262f6c4d7e0b6808
> dbc8d50831%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638324589
> 530894110%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=P%2Fd
> 85ycZ2pYo7r3Qfjtr7%2BOI0DOwunpe4SdNAoz4dCw%3D&reserved=0:
> >
> >> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm
> >> ai
> >> larchive.ietf.org%2Farch%2Fmsg%2Fcose%2F9smwFXNpbd6Fci8-mIeaT2xPP-
> E%2
> >>
> F&data=05%7C01%7Cdthaler%40microsoft.com%7C626557262f6c4d7e0b6808d
> bc8
> >>
> d50831%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383245895308
> 9411
> >>
> 0%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI
> >>
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=X50myuNdHSHwyV
> W3GzsUtXI
> >> AR3UEf4xYTD2T2V77yHw%3D&reserved=0
> >> *
> >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm
> >> ai
> >>
> larchive.ietf.org%2Farch%2Fmsg%2Fcose%2F0Dj5yp4mptZUBiw7FWb5PcXGJAg%
> 2
> >>
> F&data=05%7C01%7Cdthaler%40microsoft.com%7C626557262f6c4d7e0b6808d
> bc8
> >>
> d50831%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6383245895308
> 9411
> >>
> 0%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTiI
> >>
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=a5dVms2qZNcaowd
> xP0ulivW
> >> vPIeXS4xkABMxMuZ8fcw%3D&reserved=0
> >> 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
> >
> > _______________________________________________
> > TEEP mailing list
> > TEEP@ietf.org
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> >
> ietf.org%2Fmailman%2Flistinfo%2Fteep&data=05%7C01%7Cdthaler%40microsof
> >
> t.com%7C626557262f6c4d7e0b6808dbc8d50831%7C72f988bf86f141af91ab2d7c
> d01
> >
> 1db47%7C1%7C0%7C638324589530894110%7CUnknown%7CTWFpbGZsb3d8ey
> JWIjoiMC4
> >
> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%
> 7C%7
> >
> C&sdata=9h4QnUJfVSEgeAzR6PLcx%2BEG%2BzSirCfWpLU3WXBfJPs%3D&reserv
> ed=0

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://www.ietf.org/mailman/listinfo/teep