Re: [ippm] draft-ietf-ippm-ioam-data-integrity

[Tommy Pauly <[e-mail]>]

Hi Justin,

Thanks for highlighting this to the group. I think defining only the symmetric key solution in this document still achieves the goal of adding integrity to IOAM data, and should be sufficient.

Since the document establishes a registry for algorithms, can we define things such that this document only adds a symmetric algorithm, but leaves it open for future documents to add asymmetric if necessary (and discuss the difficulties around asymmetric currently, but mention that new documents could define it)?

We’ll also want to get more security area reviews on this, but this sounds like a good starting place to me.

Best,
Tommy

> On May 31, 2023, at 7:32 AM, Justin Iurman <[e-mail]> wrote:
> 
> Hi ippm, chairs,
> 
> Today, we (the authors) discussed an important section of the draft and found an issue with our asymmetric key-based signature algorithm (i.e., ECDSA p256 with SHA256). Indeed, it looks like it is way too complicated to end up with a working solution, not to say maybe even impossible for the use case. This observation is also based on the feedback received from an implementer. Very briefly, the issue comes from the signature chain. A node's signature would be over (a) the previous signature and (b) the (hashed) inserted data by the node. We *cannot* afford to hash the whole thing (which is usually the case for a signature), since we need a way to "go back" (i.e., to check the signature chain in the reverse order, with public keys). Therefore, we need the previous signature to stay outside of the hash. But if we do so, the input size (provided to the signature algorithm) would be too big. As a consequence, we don't believe there is a good solution for this. Note that, on second thought, ECDSA is not used for encryption and is "only" a signature algorithm, which might not be the perfect fit for what we want (i.e., to decrypt/retrieve data). A possibility would be to use something else (e.g., RSA), without the certainty that it would even work (and the signature size would be much bigger in that case).
> 
> TL;DR
> 
> What we propose here is to not over complicate things unnecessarily and have only the symmetric key-based signature algorithm defined in the draft (i.e., remove the problematic asymmetric key-based signature algorithm). After all, asymmetric algorithms are usually used to safely exchange (symmetric/shared) keys, which makes us think that it's probably not worth it. If anyone thinks otherwise, please say so. If you're a security expert and think we're wrong, please speak up. We hope for feedback from the WG.
> 
> Thanks,
> The authors
> 
> _______________________________________________
> ippm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ippm