[Iotops] Re: [iesg] Deb Cooley's Discuss on draft-ietf-iotops-7228bis-08: (with DISCUSS and COMMENT)

[Carsten Bormann <[e-mail]>]

Hi Deb,

thank you for helping me here, I think I now better understand your points.

> On 2026-07-05, at 17:46, Deb Cooley <[e-mail]> wrote:
> 
> I am replying here, since Carsten only replied to Roman's no obj ballot.  There is more I'd like to discuss here.
> […]

Apologies for mixing this up.

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Section 3.3:
>  - Please define what 'keeping secrets shielded' means (none of the RFCs listed
>  in Security Considerations mentions this concept).
>  
> [DC]  'secret shielding' is not actually defined in the first sentence (unless you allow the word you are defining to be in the def).  Do you mean RF shielding?  TEMPEST shielding (https://en.wikipedia.org/wiki/Tempest_(codename)) or some other sort of shielding?  

While preventing side channel attacks (including RF shielding) is part of the shielding here, this section is concerned with hardware support specifically for shielding certain secrets from the large amount of code running on an IoT platform, which is of varying trustworthiness.

> I suggest that you replace 'shielding' in the first sentence with 'protected', and then add that this draft calls this 'secret shielding’.  […]

Good suggestion.
We made a PR:

Diff:
https://author-tools.ietf.org/api/iddiff?url_1=https://lwig-wg.github.io/terminology/draft-ietf-iotops-7228bis.txt&url_2=https://lwig-wg.github.io/terminology/post-09/draft-ietf-iotops-7228bis.txt
"Diff: draft-ietf-iotops-7228bis.txt - draft-ietf-iotops-7228bis.txt"

HTML:
https://lwig-wg.github.io/terminology/post-09/draft-ietf-iotops-7228bis.html
"Terminology for Constrained-Node Networks”

Not sure you will have time before the I-D deadline to look at this.
(We can submit that as a -10 today, even if you don’t have the time.)
 
> - What (precisely) is
>  'secure enclave functionality'?
> [DC]  Interesting, I never thought of HSM, TPM or TEE's as 'categories'...  I might suggest using 'for example' instead of 'but does not distinguish between device categories'.

Yes, thanks.
We also added a pointer to Is8 from the previous section about isolation in general.
 
> - In addition, the levels of 'no', 'some', and
>  'perfect' are under-specified.  In addition, one hardly ever/never refers to
>  security levels as 'perfect', I would argue that it will never be achievable,
>  which begs the question, why specify the level?
> [DC] 'comprehensive' is better, thanks.  
> 
> [DC]  As for the use of the word 'Cadillac' as a word to describe 'high quality' or 'high security'...  I feel like this is a bit of a strange comment for me to make to a non-native English speaker, but it is definitely jargon which might not be understood by all.

Thanks.  “Cadillac” was part of the Computer Engineering vernacular I learned together with the rest of English that I know...
Fixed by substituting ‘fully “deluxe”’.

> It actually might be easier to merely remove the section.
> 
> Section 8:  If Section 3.3 remains in the draft, at least add some information
> here about what vulnerabilities 'keeping secrets shielded' protects against. 
> 
> [DC]  Section 8, last sentence:  I will point out that the phrase 'secret shielding' does not occur in RFC 9397...  I'm not sure how this helps.

In the PR, we fixed the wording so it indicates why we think the reference is useful.

Grüße, Carsten