Document rationale for DSSE vs COSE etc.

[secure-systems-lab]

Document rationale for DSSE vs COSE etc.

[SantiagoTorres]

Hi @nealmcb!

My 2 cents (I've since left the SSL so take this with a grain of salt). I think that document was insightful, but for reasons beyond the raw content in it. I honestly don't think it really articulates a rationale for using COSE other than it being an IETF endorsed "standard". In fact, I can't still answer this, but now that their charter does describe the NEED to use COSE/RATS for no reason other than the authors of that RFC being co-authors of that other one, then I believe there's your answer. When I asked repeatedly that they'd be willing to use other cryptographic standards instead of COSE (e.g., PKCS9 or PGP) they had no answer other than "we want to use COSE". To me, it feels like the requirement was to have one standard, rather than provide certain fundamental security/performance properties.

As for my side --- I don't speak for the SSL! --- most of the pushback to using COSE (at least from my side) fell within not adding unnecessary complexity, as well as COSE's pedigree of massive CVE's from its ancestor JOSE. They say they fixed those issues, by issuing yet another RFC where they document the common mistakes people do when implementing JOSE. I'm not exactly satisfied with this. I believe in security by default, and I know knobs can also serve as footguns, thus the minimal specification around DSSE (Speaking of which, you may be interested in PASETO as well).

I think it'd be valuable to bring some clarity into the issue as you point out, and perhaps working on fleshing out that document is it. I unfortunately don't have the cycles for something like this, but I'd be happy to chime in whenever possible. I'd be happy to participate to the extent possible!

P.S. Oh, and to clarify. Sigstore didn't add support for COSE because of any enlightening conversation with the SCITT folks (as they seem to hint in that issue), but rather because it already supported a bunch of other standards (such as GPG and PKCS9 mentioned above) so why not.

[ivarprudnikov]

A related observation. It seems that Sigstore bundle was invented purely because DSSE has limits on the metadata you can embed in the signature.

https://github.com/sigstore/protobuf-specs/blob/b6d25769ec1d565ba45fd121310daf4ab963da9b/protos/sigstore_bundle.proto#L63

I have no proof of the claim, but after working with cose it would be a similar thing I'd miss.

[adityasaky]

The Sigstore bundle format is also needed for non-DSSE cases to ship the additional verification information. On the DSSE side, we're actively working to support the additional information on a case-by-case basis. See: #59, #61, and sigstore/protobuf-specs#145. I can't speak for how COSE handles this though.

[JustinCappos]

I'm closer to someone who speaks for the SSL, but would really say that we broadly discuss all decisions. From my reading of the document and comments, you conclude that DSSE provides a much simpler envelope format than COSE. DSSE has a smaller and simpler code base (which is good for security), but lacks some COSE features which as I understand it, we either aren't using or are implemented at a different level. At the risk of parroting Santiago, I agree that what is missing is the rationale for why we would adopt COSE. What problem does it solve for our users? How would integrating change our security risk? Is it better, worse, different?

…

On Mon, Sep 4, 2023 at 5:42 PM Santiago Torres ***@***.***> wrote: Hi @nealmcb <https://github.com/nealmcb>! My 2 cents (I've since left the SSL so take this with a grain of salt). I think that document was insightful, but for reasons beyond the raw content in it. I honestly don't think it really articulates a rationale *for* using COSE other than it being an IETF endorsed "standard". In fact, I can't still answer this, but now that their charter does describe the NEED to use COSE/RATS for no reason other than the authors of that RFC being co-authors of that other one, then I believe there's your answer. When I asked repeatedly that they'd be willing to use other cryptographic standards instead of COSE (e.g., PKCS9 or PGP) they had no answer other than "we want to use COSE". To me, it feels like the requirement was to have one standard, rather than provide certain fundamental security/performance properties. As for my side --- I don't speak for the SSL! --- most of the pushback to using COSE (at least from my side) fell within not adding unnecessary complexity, as well as COSE's pedigree of massive CVE's from its ancestor JOSE. They say they fixed those issues, by issuing yet another RFC where they document the common mistakes people do when implementing JOSE. I'm not exactly satisfied with this. I believe in security by default, and I know knobs can also serve as footguns, thus the minimal specification around DSSE (Speaking of which, you may be interested in PASETO as well). I think it'd be valuable to bring some clarity into the issue as you point out, and perhaps working on fleshing out that document is it. I unfortunately don't have the cycles for something like this, but I'd be happy to chime in whenever possible. I'd be happy to participate to the extent possible! P.S. Oh, and to clarify. Sigstore didn't add support for COSE because of any enlightening conversation with the SCITT folks (as they seem to hint in that issue), but rather because it already supported a bunch of other standards (such as GPG and PKCS9 mentioned above) so why not. — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODYVO7HW3UXAB6JISTTXYZDNBANCNFSM6AAAAAA4K3GZXY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>