Subject: [COSE] implementations of RFC8152

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jul 2020 16:30:02 -0400

Hi,

Is the WG aware of any formal (cryptographic) reviews of RFC7515 and RFC8152?

Was there an implementation report when 8152 was published?
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?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Mon, 20 Jul 2020 14:03:28 -0700

> -----Original Message-----
> From: COSE <[email-masked]> On Behalf Of Michael Richardson
> Sent: Monday, July 20, 2020 1:30 PM
> To: [email-masked]; Mike Jones <[email-masked]>
> Subject: [COSE] implementations of RFC8152
> 
> 
> Hi,
> 

[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.

> Was there an implementation report when 8152 was published?

[JLS] Yes there was.

> 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.

Jim

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jul 2020 13:27:42 -0400

> for RFC 8152 which was not along the lines of - it must have the same issues

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.

    > [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 :-)

    > 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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Jim Schaad <[email-masked]>
Date: Tue, 21 Jul 2020 11:07:37 -0700

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

> From: Michael Richardson <[email-masked]>
> Sent: Tuesday, July 21, 2020 10:28 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; 'Mike Jones' <[email-masked]>
> Subject: Re: [COSE] implementations of RFC8152
> 
> 
>     >> Is the WG aware of any formal (cryptographic) reviews of RFC7515
and
>     >> RFC8152?
>     > suspect that the answer is no.  There have been some community
reviews
> of
>     > for RFC 8152 which was not along the lines of - it must have the
same
> issues
time.
> I'm asking about formal verifications, either at the protocol interaction
level,
> such as was done for IKE recently:
shepherd
> write up...  Yup.
>     >> While I'm aware of many of the IETF efforts that leverage COSE, is
there
>     > > any

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jul 2020 13:44:02 -0400

Jim, thank you for the summary and for clarifying for me the difference
between formal verification of a protocol and of a message encapsulation
object.

It is a good point.