Michael, So here is the problem. For both IPSEC and Lake you are talking about protocols. However COSE is not a protocol but a message encapsulation object. This means that the question of what you are asking about for a protocol becomes more problematic. If we wanted to do the modeling we would need to do it in the context of a protocol.
If you are asking - does the protocol exceed the number of blocks of data that can be encrypted? This is not something that COSE can look at. Most of any analysis is going to sit on top of an analysis of the cryptographic algorithm that is being looked at along with how the protocol is designed in. One can do an analysis along the lines of - are all of the pieces of information that are supposed to be covered by a cryptographic operation covered, but even there just looking at COSE will not be able to answer the question. If one says that the content encryption algorithms MUST be covered by the authenticated data for the AEAD. One needs to look at the protocol that COSE is placed in to see if that is true. It could be part of the authenticated attributes or it could be part of the externally supplied authenticated data. The first is what I would expect for a simple use of a COSE encryption object, but the latter is what is used for OSCORE. In both cases the correct thing is being done but that cannot be determined solely from an analysis of COSE. I have seen reviews such as https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that- everyone-should-avoid which talk to JOSE about some issues that are there and can be avoided - Don't use signature algorithm None - Do checking of algorithms with keys correctly. I saw one review from them that painted COSE with the same brush but when I read their review it looked like they just copied the JWT review over without looking at things from the start. Most if not all of the issues that they highlighted were fixed before I even read this review of JOSE because I found them to be difficult. On the other hand, if you send the signing key as part of the signed message and the recipient does not bother to check that it matches the purported originator of the message. I have no idea how anyone can ever fix that as they might just as easily got the signing key from some other untrusted source and used it. I cannot say that their bespoke crypto will have fewer issues, however WalnutDSA was thought by the company proposing it to be a great algorithm until it underwent some cryptographic review. (And a number of bounds in the algorithm were then changed.) As I remember Frog, which was one of the AEAD algorithms submitted to NIST as part of that computation was presented to a conference and broken before the rump session had finished. If you can get more detail on what you think you are really looking for I might be able to help. Jim > -----Original Message----- > From: Michael Richardson <[email protected]> > Sent: Tuesday, July 21, 2020 10:28 AM > To: Jim Schaad <[email protected]> > Cc: [email protected]; 'Mike Jones' <[email protected]> > Subject: Re: [COSE] implementations of RFC8152 > > > Jim Schaad <[email protected]> wrote: > >> -----Original Message----- > >> From: COSE <[email protected]> On Behalf Of Michael Richardson > >> Sent: Monday, July 20, 2020 1:30 PM > >> To: [email protected]; Mike Jones <[email protected]> > >> Subject: [COSE] implementations of RFC8152 > >> > >> > >> Hi, > >> > >> Is the WG aware of any formal (cryptographic) reviews of RFC7515 and > >> RFC8152? > > > [JLS] I am not too sure of what you mean by a cryptographic review, but I > > suspect that the answer is no. There have been some community reviews > of > > RFC 7515 which point to issues that need to be kept in mind, such as the > > existence of the None signature algorithm. I don't remember seeing > anything > > for RFC 8152 which was not along the lines of - it must have the same > issues > > as RFC 7515. > > Sorry, I used impresise language because I was tired and frustrated at the time. > > I'm asking about formal verifications, either at the protocol interaction level, > such as was done for IKE recently: > https://mailarchive.ietf.org/arch/msg/ipsec/LNEPxxRwNAeWbp2Cjzqb-uS7- > No/ > > and has been planned for EDHOC: > > https://mailarchive.ietf.org/arch/msg/lake/WGmpD4F9Yb6qCfgwYkF0oKcEqYw > > which I know has been done for TLS. > > >> Was there an implementation report when 8152 was published? > > > [JLS] Yes there was. > > I looked back through the IDs before RFC, since we usually remove that before > publication, but I didn't see it in the ID. I guess it might be in the shepherd > write up... Yup. > I wish we would get on with having this on the rfc-editor.org pages :-) > > >> While I'm aware of many of the IETF efforts that leverage COSE, is there > > > any > >> data on how it has been used outside of the IETF? > > > [JLS] There are a couple of different projects at the W3C. Web > > Authentication is one and Secure Data Storage is another. > > There is an ISO > > driving license standard that I have see reference (ISO/IEC JTC 001/SC 17 > > "Cards and security devices for personal identification" Mobile Driver's > > License (mDL)). A couple of people have talked to me about potentially > > using COSE rather than CMS but needing certificates to do so. I can't > > remember who off the top of my head. > > Thank you. > Is it worth enabling a wiki in https://github.com/cose-wg somewhere to record > these things? > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
