Re: [Suit] New Version Notification for draft-moran-suit-mti-00.txt

[Laurence Lundblade <[e-mail]>]

Another comment here after the SUIT meeting discussion yesterday and a side conversation with Russ. I’m interested in this because I want to understand better the IETF approach to algorithm interop (for selfish reasons related to EAT).

Basically, I’m pretty unsure that it is good to have MTI in a broad standard like SUIT (or COSE, PKIX, CWT, or EAT). It seems it would be bad for constrained devices that only can implement one algorithm.

If you say every device must implement one of these three

3.1. Symmetric MTI profile: suit-sha256-hmac-a128-ccm
3.2. Current Asymmetric MTI Profile: suit-sha256-es256-hpke-a128gcm
3.3. Future Asymmetric MTI Profile: suit-sha256-hsslms-hpke-a128gcm

it means that someone that wants to do Chinese crypto or EdDSA or Falcon-512 has to implement two algorithms. For example, they'd have to implement es256 along side EdDSA. 


It seems like the best you can do in a broad building-block IETF standard is define some good solid profiles that implementors can choose if they want. Then maybe go one step further with a negotiation mechanism (like TLS) or a profile mechanism (like EAT).

FIDO does have MTI, but the FIDO Alliance is structured differently. They have a strong interop and compliance certification program which is required to use the FIDO logo. FIDO members pay to belong, wield influence and gain benefits like joint marketing and access to compliance testing. Also and important — FIDO is more of an end-product protocol rather than a building-block protocol.

SUIT seems like it is a broad building-block protocol like COSE or CWT rather than an end-product protocol like FIDO. That probably means it doesn’t make sense to define an MTI, just some good profiles/cipher-suites.

Note also that there is no compliance program in the IETF, so even if SUIT had MIT, there wouldn’t be any enforcement making it a bit of an overreach.

LL

. 


> On Jul 27, 2022, at 6:00 PM, Brendan Moran <[e-mail]> wrote:
> 
> I’ve now uploaded a new version of the draft that should be a better structure.
> 
> Best Regards,
> Brendan
> 
>> On 21 Jul 2022, at 13:07, Brendan Moran <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Lawrence,
>> 
>> Sorry I’ve been silent: I’ve been laid up with Covid for over a week.
>> 
>> 
>> You’re right. It turns out I published the wrong version of my draft. Oops.
>> 
>> The right version is here: https://github.com/bremoran/suit-mti/blob/main/draft-moran-suit-mti-algorithms.md <https://github.com/bremoran/suit-mti/blob/main/draft-moran-suit-mti-algorithms.md>
>> 
>> Unfortunately, I can’t submit it until next week due to the draft publication blackout.
>> 
>> Essentially, I see this as a one-of-three choice. You, as an implementor, can choose to implement one of three MTI profiles:
>> * A classical asymmetric profile
>> * A PQC asymmetric profile
>> * A symmetric profile
>> 
>> You are welcome to implement other profiles as needed.
>> 
>> I think that the 1-of-3 choice is going to be necessary because, otherwise, there’s no way we’re going to have many compliant implementations.
>> 
>> Best Regards,
>> Brendan
>> 
>>> On 14 Jul 2022, at 19:35, Laurence Lundblade <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> Hi,
>>> 
>>> Not being a SUIT implementor, I’m kind of peanut gallery here so maybe my comments don’t have a lot of weight.
>>> 
>>> My first reaction is that is lot of algorithms to be mandatory. For example, I’m not even close to supporting all those in t_cose. I didn’t check, but I doubt commonly deployed versions of OpenSSL and Mbedtls support all the algorithms.
>>> 
>>> Then for a given implementation/deployment you might want to support only one single algorithm on a constrained device to have minimum object code. A tactic might be to require the receiver to support many algorithms and the sender just one.
>>> 
>>> Is this trying to guarantee interoperability? It seems not since it doesn’t mention it. 
>>> 
>>> I’m not sure about IETF tactics for guaranteeing interoperability. Seems they are kind of loose to me. Maybe that’s OK.
>>> 
>>> By contrast, FIDO is very specific about algorithms to implement so there is guaranteed interop. This is also because FIDO has a compliance program that tests implementations.
>>> 
>>> In the recent EAT draft, I defined a constrained device profile that does guarantee algorithm interoperability by requiring the receiver to support ES256, ES384 and ES 512 and the sender to use one of these. There will never be an algorithm mismatch.
>>> 
>>> LL
>>> 
>>> 
>>> 
>>>> On Jul 11, 2022, at 12:57 PM, Brendan Moran <[e-mail] <mailto:[e-mail]>> wrote:
>>>> 
>>>> Dear SUIT,
>>>> 
>>>> I have submitted a draft profile document. It is very much a strawman. Please feel free to bash it/propose edits!
>>>> 
>>>> I will upload it too GitHub to make it easier to bash.
>>>> 
>>>> Best Regards,
>>>> Brendan
>>>> 
>>>>> On 11 Jul 2022, at 20:54, [e-mail] <mailto:[e-mail]> wrote:
>>>>> 
>>>>> 
>>>>> A new version of I-D, draft-moran-suit-mti-00.txt
>>>>> has been successfully submitted by Brendan Moran and posted to the
>>>>> IETF repository.
>>>>> 
>>>>> Name: draft-moran-suit-mti
>>>>> Revision: 00
>>>>> Title: Mandatory-to-Implement Algorithms for Creators and Consumers of Software Update for the Internet of Things manifests
>>>>> Document date: 2022-07-11
>>>>> Group: Individual Submission
>>>>> Pages: 7
>>>>> URL: https://www.ietf.org/archive/id/draft-moran-suit-mti-00.txt <https://www.ietf.org/archive/id/draft-moran-suit-mti-00.txt>
>>>>> Status: https://datatracker.ietf.org/doc/draft-moran-suit-mti/ <https://datatracker.ietf.org/doc/draft-moran-suit-mti/>
>>>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-moran-suit-mti <https://datatracker.ietf.org/doc/html/draft-moran-suit-mti>
>>>>> 
>>>>> 
>>>>> Abstract:
>>>>> This document specifies algorithm profiles for SUIT manifest parsers
>>>>> and authors to ensure better interoperability.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> The IETF Secretariat
>>>>> 
>>>>> 
>>>> 
>>>> 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.
>>>> 
>>>> _______________________________________________
>>>> Suit mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>
>>> 
>>> _______________________________________________
>>> Suit mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/suit <https://www.ietf.org/mailman/listinfo/suit>
>> 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.
>> _______________________________________________
>> Suit mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/suit
> 
> 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.