Subject: Re: [COSE] Key identifier of type bstr / int

From: Laurence Lundblade <[email-masked]>
Date: Mon, 9 Aug 2021 11:10:51 -0700

A small comment on code size as the author of a commercial-quality COSE implementation designed to have small code size.

There is a bit of a trade-off between code size and bytes on the wire. Reducing the bytes on the wire by one byte in this case will lead to an increase in code size by a lot more than one byte, assuming both int and bstr are supported. If both are not supported, then there is #ifdef complexity and configuration work with general purpose COSE implementations.

Most of the code cost for me in implementing COSE is in the header parameter decoding.

This desire to save 1 CBOR byte here and there at the cost of code / complexity shows up elsewhere. Here’s one from CoSWID
one-or-more<T> = T / [ 2* T ]

This could just be an array.

I don’t know the use cases, but I’m a little skeptical these sorts of things are worth a byte or two on the wire.

LL

> On Jul 30, 2021, at 5:28 AM, Göran Selander <goran.selander=[email-masked]> wrote:
> 
> Hi,
> 
> In LAKE yesterday we had a discussion on compact key identifiers. The main candidate to use, 'kid', is specified as a CBOR bstr, which is typically at least 2 bytes (exception: empty bstr which is 1 byte). We therefore want to allow keys to be identified with CBOR ints which has 48 1-byte values to allow for a larger number of optimally small identifiers.
> 
> One solution would be to define a new COSE key common parameter and COSE header parameter, say 'kid2', of type bstr / int. Another solution would be to extend 'kid' to be bstr / int.
> 
> In the former case a 'kid2' can be used to reference keys identified with either 'kid2' or 'kid', but 'kid' would not be able to reference keys identified with 'kid2' having an int value. Not clear to me if that is a problem. 
> 
> While the LAKE WG did not express any preference, one opinion I learnt after the meeting was a preference of extending 'kid' to bstr / int.
> 
> What do folks in COSE think?
> 
> I'm familiar with the process of registering new COSE parameters, what is the requirement for changing the value type of an existing registration? Standards action with expert review?
> 
> Thanks
> Göran
> 
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Göran Selander <[email-masked]>
Date: Tue, 10 Aug 2021 10:13:36 +0000

Thanks Laurence, these trade-offs are important to consider. The final message optimization is one of the open issues (#103) on the LAKE github and your comment is good input to that discussion. The background for this is the requirement for the LAKE protocol to perform well in constrained radio settings with small frame sizes where performance may be significantly degraded by exceeding certain limits. For these settings, every byte counts and some bytes just cannot be avoided, like a message authentication code or an ephemeral public key.

Assume that we do want to allow key identifiers to be CBOR ints in certain settings,  what is the best (least intrusive) way to allow this while still maintain compatibility with 'kid's supporting the type bstr? Another alternative to what has been listed below is to define 'kid2' to only be of type int - is that a better option?

Other thoughts?

Göran

From: Laurence Lundblade <[email-masked]>
Date: Monday, 9 August 2021 at 20:11
To: Göran Selander <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [COSE] Key identifier of type bstr / int

LL

On Jul 30, 2021, at 5:28 AM, Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>> wrote:

Hi,

Thanks
Göran

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 12 Aug 2021 17:00:18 -0700

> I'm familiar with the process of registering new COSE parameters, what is the requirement for changing the value type of an existing registration? Standards action with expert review?

I think so.  There's a decent case that just standards action would
suffice, but I like ensuring that the experts also weigh in.

>From the follow-up:

> Another alternative to what has been listed below is to define 'kid2' to
> only be of type int - is that a better option?

That would avoid some of the decoder complexity that Laurence raised, but
leaves the issue of needing logic to handle a message that sets both 'kid'
and 'kid2'.  For a long-term steady-state best outcome I don't see a huge
difference between an expanded 'kid' and deprecating 'kid' entirely in
favor of a 'kid2' that does both.  I'm less sure how to compare that option
against the one-parameter-per-type option (kid==bstr, kid2==int) that is
easier to decode but has the possibility to provide both parameters.

-Ben

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 12 Aug 2021 18:01:41 -0700

Understood about the use case. Thx for the background.

> On Aug 10, 2021, at 3:13 AM, Göran Selander <goran.selander=[email-masked]> wrote:
> 

I didn’t write actual code to check, but they about the same to me.

‘kid' as int/bstr seems less confusing to me than ‘kid2’. It tells you it does exactly the same thing whether it is an int or a bstr.

So my pick is ‘kid’, but ‘kid2’ is OK too.

LL

---

From: Göran Selander <[email-masked]>
Date: Fri, 13 Aug 2021 05:17:59 +0000

Thanks Laurence, thanks Ben!

Summarising the feedback so far, there seems to be a mild preference for extending 'kid' as int/bstr documented in a standards track RFC and with expert review. (More comments are welcome.)

Next question: Is there a preference for making this a stand-alone draft or can we include the extension in draft-ietf-lake-edhoc? Do we consider this an update of RFC-to-be 9052 (draft-ietf-cose-rfc8152bis-struct)?

Thanks
Göran

From: COSE <[email-masked]> on behalf of Laurence Lundblade <[email-masked]>
Date: Friday, 13 August 2021 at 03:02
To: Göran Selander <goran.selander=[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [COSE] Key identifier of type bstr / int

On Aug 10, 2021, at 3:13 AM, Göran Selander <goran.selander=[email-masked]<mailto:goran.selander=[email-masked]>> wrote:

LL