[Suit] Re: AD Comments on draft-ietf-suit-mti

[Michael Jones <[e-mail]>]

This review is from the perspective of having the MTI algorithms fully-specified, per https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/.  Note that the draft would currently make algorithms about to be deprecated MTI.  This needs to be corrected.

Brendan, you wrote:

[BM] I'm not so sure about this. I'm concerned about delays that will be introduced and the ever growing cluster size of SUIT.
draft-ietf-jose-fully-specified-algorithms is in IESG Evaluation state, and thus ahead of draft-ietf-suit-mti in the process.  It's therefore unlikely that using the algorithms registered by it will introduce a delay.

To align the drafts, I would request these changes relative to https://www.ietf.org/archive/id/draft-ietf-suit-mti-13.html:

Everywhere:  Change all instances of
"ES256" to "ESP256"
"es256" to "esp256"
"-7" to "-9"
"EDDSA" to "Ed25519"
"eddsa" to "ed25519"
"-8" to "-50"

In particular...

Sections 3.2 and 3.4:  Change
Authentication ES256 -7
to
Authentication ESP256 -9

Sections 3.3 and 3.5:  Change
Authentication EDDSA -8
to
Authentication Ed25519 -50

Section 6:  Change
suit-sha256-es256-ecdh-a128ctr MANDATORY -16 -7 -29 -65534 [-16, -7, -29, -65534] Section 3.2
to
suit-sha256-esp256-ecdh-a128ctr MANDATORY -16 -9 -29 -65534 [-16, -7, -29, -65534] Section 3.2

Section 6:  Change
suit-sha256-eddsa-ecdh-a128ctr MANDATORY -16 -8 -29 -65534 [-16, -8, -29, -65534] Section 3.3
to
suit-sha256-ed25519-ecdh-a128ctr MANDATORY -16 -50 -29 -65534 [-16, -8, -29, -65534] Section 3.3

Section 6:  Change
suit-sha256-es256-ecdh-a128gcm MANDATORY -16 -7 -29 1 [-16, -7, -29, 1] Section 3.4
to
suit-sha256-esp256-ecdh-a128gcm MANDATORY -16 -9 -29 1 [-16, -7, -29, 1] Section 3.4

Section 6:  Change
suit-sha256-eddsa-ecdh-chacha-poly MANDATORY -16 -8 -29 24 [-16, -8, -29, 24] Section 3.5
to
suit-sha256-ed25519-ecdh-chacha-poly MANDATORY -16 -50 -29 24 [-16, -8, -29, 24] Section 3.5

Appendix A:  Change
suit-sha256-es256-ecdh-a128ctr     = [-16, -7, -29, -65534]
to
suit-sha256-esp256-ecdh-a128ctr     = [-16, -9, -29, -65534]

Appendix A:  Change
suit-sha256-eddsa-ecdh-a128ctr     = [-16, -8, -29, -65534]
to
suit-sha256-ed25519-ecdh-a128ctr     = [-16, -50, -29, -65534]

Appendix A:  Change
suit-sha256-es256-ecdh-a128gcm     = [-16, -7, -29, 1]
to
suit-sha256-esp256-ecdh-a128gcm     = [-16, -9, -29, 1]

Appendix A:  Change
suit-sha256-eddsa-ecdh-chacha-poly = [-16, -8, -29, 24]
to
suit-sha256-ed25519-ecdh-chacha-poly = [-16, -50, -29, 24]

And of course, add a normative reference to draft-ietf-jose-fully-specified-algorithms.

I hope you find this review useful.

                                                                Best wishes,
                                                                -- Mike

From: Brendan Moran <[e-mail]>
Sent: Tuesday, March 4, 2025 12:24 AM
To: Deb Cooley <[e-mail]>; [e-mail]
Cc: [e-mail]; [e-mail]; Russ Housley <[e-mail]>; Michael Jones <[e-mail]>; Orie Steele <[e-mail]>
Subject: Re: [Suit] AD Comments on draft-ietf-suit-mti

Dear Deb,

Thank you for taking the time to review this draft. I have made changes where appropriate and added my comments inline, tagged with [BM].

Best Regards,
Brendan

From: Deb Cooley <[e-mail]<mailto:[e-mail]>>
Date: Sunday, 23 February 2025 at 12:13
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>, Russ Housley <[e-mail]<mailto:[e-mail]>>, Michael Jones <[e-mail]<mailto:[e-mail]>>, Orie Steele <[e-mail]<mailto:[e-mail]>>
Subject: [Suit] AD Comments on draft-ietf-suit-mti
I don't see a ton of reviews from a brief spin through the suit mail list.  I'd like to also see some evidence of coordination with the cose wg (in particular see my comment on Section 3).

Here are my comments on the mti draft.  I expect that these comments will be addressed and a new version of the draft issued:

Abstract:  Here is a slightly revised paragraph from the shepherd writeup.  I think it is easier to understand than the current abstract, 'This document specifies cryptographic algorithm profiles to be used with the SUIT manifest (see draft-ietf-suit-manifest).  These are the mandatory-to-implement algorithms to ensure interoperability.'  On the current abstract: I don't know what 'parsers and authors' is supposed to mean. There is no mention of 'mandatory to implement'.  And while I know what 'constrained node software update use case' is, it isn't clear or concise.  I'm happy to consider other edits, but I would like this to be easy to understand.
[BM] Done

Introduction, para 1:  Don't bury the lead.  Move the first two sentences somewhere else in the introduction.  And perhaps reuse the abstract sentences as the first two sentences.
[BM] Done


Introduction, para 4:  Consider changing, 'with powerful/complex manifest authors and constrained recipients' to 'where manifest authors have unlimited resources and manifest recipients have constrained resources'.
[BM] Done

Introduction, last para:  I don't like the use of SUIT here, either expand it, say what you mean by it,  or remove it.
[BM] Done

Section 3 (and Section 6):  There is currently a draft in IETF Last Call, 'draft-ietf-jose-fully-specified-algorithms' which will change the cose registrations for EDDSA.  We should ensure that the suit mti draft will fall into line with that draft as they make their way through the publication process.  Since the ECDSA/ECDH parameters are P-256, I'm guessing that you would specify EDDSA w/ X25519.  It is possible that the suit mti draft will need to reference the jose/cose draft.
[BM] I'm not so sure about this. I'm concerned about delays that will be introduced and the ever growing cluster size of SUIT.

Section 3.6:  What is the rationale for ctr mode over gcm here?
[BM] There's quite a history here, but it boils down to just this: while it is technically feasible to process AES-GCM blocks out-of-order, there's no standardised GCM mode where it would be appropriate to receive blocks out-of-order and decrypt on the fly. This is a requirement of constrained devices. AES-CTR is the only standardized cipher used in its expected configuration that can do this.

Section 4:  What about 'manifest recipients response communication' instead of 'reverse-direction communication'?  [does this apply to manifest authors?]
[BM] Done


Section 5, para 1:  Remove 'For the avoidance of doubt'.  Are there examples where encryption is not required?
[BM] Encryption is rarely required in IoT use cases. It is only needed when IP Protection is in play. Arguments can be made about impacts of encryption on adversarial code analysis, but this is a matter of some debate (see security through obscurity).

Section 5, 2nd bullet:  Why do you need the second sentence?  Does it actually apply to streaming decryption?
[BM] To be clear, the intent here is on-the-fly decryption on a block-by-block basis. I could clarify that. I was under the impression that streaming was appropriate nomenclature for that use case.

Section 5, 4th bullet:  How about, 'Chosen plaintext attacks are harder since the plaintext is authenticated prior to encryption.'  [I'm not sure you can say that they are impossible.]
[BM] I have clarified this section and removed the absolute language.

Section 5, last paragraph:  Replace 'is the most appropriate' with 'is an acceptable'.
[BM] Done

Nits:
Intro, para 1:  expand MTI
Intro, second to last para:  expand AEAD
Intro, second to last para:  ecryption/encryption
[BM] Done
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.