Subject: Re: [Suit] [Fud] A few questions / observations

From: Brendan Moran <[email-masked]>
Date: Mon, 30 Oct 2017 13:43:04 +0000

Hi Jim,
I’m in the process of attempting an initial draft of a COSE/CBOR manifest. I had underestimated the number of bstr wrapper objects in COSE, and I am not concerned about the complexity of the parser as a result. Further, I’ve looked at the comparative complexity of “get_tag” and “get_len" functions for ASN.1 and CBOR and the difference seems minimal. Along with the comments you’ve made about the use of schemas, my only remaining concern is the maturity of COSE but, as you say, COSE has had the opportunity to learn from CMS’s mistakes.

I think that for the best chance of gaining wide adoption and agreement, we should proceed with COSE or have an extremely good reason not to.  With that in mind, I’m proceeding with a re-draft that will use COSE objects, CBOR and CDDL.

I do not know if this will be done in time for the IETF meeting.

Thanks,
Brendan

On 9 Oct 2017, at 22:58, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]]
Sent: Monday, October 9, 2017 1:40 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Fud] A few questions / observations

Hi Jim,

let me respond to this issue:

On 10/04/2017 10:29 PM, Jim Schaad wrote:
Many of the people that I have talked to are looking at using either
raw public keys or pre-shared keys as the authentication mode for
doing TLS.  This means that the need for any ASN.1 decoding goes away
from TLS and the DER encoder would not be needed on the end product.
I think this might be a YMMV statement.

I guess it depends who you talk to.

I completely agree on that.  It might be a bit higher after the OAuth stuff gets deployed, I don't know

Jim

As you know, I am co-author of the TLS PSK and the TLS raw public key
mechanism and as such I had obviously expected (or was hoping for) a
widespread adoption of those mechanisms since they provide much better
performance on paper. Since we always hear these stories about limitations
of these IoT devices we obviously buy into these stories.

However, our experience at ARM was a bit different. Those companies who
cared about IoT security tend to be rather conservative and once they decide
to go for the full-blown IoT solution (which includes a device management
solution with firmware updates) they want to go for a certificate based
approach. Of course, there is more overhead but often there are other
factors that play a role in the decision making. For example, many of these
companies are interested in reusing their existing infrastructure and
processes. This might also explain why there is suddenly interest in
standardizing the EST over CoAP-based certificate management protocol in
ACE.

Hence, I believe there is a disconnect between the " optimize like hell"
and the "I need to deploy something I am familiar with" approaches.

Ciao
Hannes

_______________________________________________
Fud mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/fud

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.