Subject: [Cose] Parameterization of CCM mode

From: "Jim Schaad" <[email-masked]>
Date: Mon, 11 May 2015 11:52:37 -0700

As part of looking at the sizes of encodings for items, I was looking at the
use of CCM mode and trying to make guesses about what the parameters are
that are going to be used in constrained devices.  Trying to get the info
from https://tools.ietf.org/html/draft-selander-ace-object-security-01 did
not really help as it seemed to not have the correct set encoded into it.

The parameters that I have identified for CCM are the following:

1)  Key size - 128, 192, 256
2)  M - number of octets in the authentication field - 4, 6, 8, 10, 12, 14,
16
3)  L - number of octets in the length field - 2-8 octets

The key size does not affect the size of the output so it is not a big issue
relative to things.  While I would guess that generally only 128-bit keys
are used, it would probably makes sense to define at least 128 and 256 bit
key algorithms

The size of the authentication fields is currently defined as 8 from the
Selander draft.  It would make sense to have at least two sizes defined - 8
and 16, but I am not sure about other sizes.

The hardest one to make decisions on is the message length field.  For
constrained devices this could be a very small value as a value of 2 would
all for encrypting 2^(8*2) bytes and would allow for the key to be used a
lot as one then has a nonce of 15-2=13 bytes (allowing for a key to be used
~ 2^13 times assuming no birthday attacks).  Nonce values as 15-L bytes long
and nonce values must not be re-used.  On the other hand, for a more general
usage it makes sense to have a larger value of L to allow for bigger
messages with less key re-usage.  

The Selander draft appears to make the assumption that different keys are
used in each direction when encrypting messages.  This makes one problem
easier - there is no need to divide up the nonce space so that nonce values
are not re-used when encrypting messages.  It also makes nonce usage easier
because there is no need to try and synchronize the nonce value usage
between the two parties.  On the other hand, it means that there is more
data that needs to be keep on the device as you now need 2 keys and 2 nonce
counters for each pair-wise link which might be a space issue on the device.

In the Selander draft, there was the idea of having both a nonce counter and
salt value which is used to construct the nonce used in the encryption step.
As far as I know there is no security reason to salt the nonce unless there
is an expectation that the keys would ever be re-used.  If new keys are
generated each time that keys are generated then the salt is probably not
necessary to have.   However, use of a salt value can be used to divide up
the nonce space if the same key value is used in both directions.

While we need to do more research on figuring out how many times a key can
be used based on the nonce length, this is probably not dependent on the
values of L that we want to standardize.  The more items we standardize the
more selection different protocols will have, but I don't know how much
parameterization the implementations support or if they are using fixed
parameterization.

Jim

---

From: Göran Selander <[email-masked]>
Date: Tue, 12 May 2015 12:52:16 +0000

Hi Jim

Thanks for the rapid progress.

Since there are several references to
https://tools.ietf.org/html/draft-selander-ace-object-security-01, let me
give some context about what this draft intended to do that is relevant to
COSE for those that have not read it. First of all, it did not intend to
specify a generic compact secure message format as is the objective of
COSE, see Appendix C:

"For constrained environments it is important that the message
   expansion due to security overhead is kept at a minimum.  As an
   attempt to assess what this minimum expansion could be, an optimized
   Secure Message format is defined, tailor-made for this setting.  This
   is intended as a benchmark for generic content formats, to allow an
   informed decision about which Secure Message format to mandate in a
   future version of this draft.”

The main design objective was thus to estimate a minimum message size
(using a bespoke format called CSM) while at the same time be flexible to
take into account the great variation of settings for which this may be
applied by allowing different ciphersuites, lengths of key identifiers and
sequence numbers.

As indicated by the latter, another design objective was to have built-in
support for replay protection suitable for constrained devices independent
of cipher suite. In this respect indexing the use of a particular key with
a sequence numbers seemed a better candidate than nonces and time,
considering storage and inaccuracy of clocks. Since different applications
have different requirements in terms of number of messages we allowed a
variable counter size and to minimize message size a default truncation of
initial sequence number bytes containing zeros. Since different
applications have varying degree of strictness on replay (sliding window
to allow reordering etc.) we left to the application to define the exact
processing rules. Finally, similar considerations was made on lengths of
key identifiers, where different applications may require different sizes
of name spaces.

Further comments inline

>3)  L - number of octets in the length field - 2-8 octets

Length of message is not included in the CSM as we assumed that would be
given by UDP. This may be a too restrictive assumption for COSE.
I believe for UDP you would require 16 octets in the normal case, someone
else could correct me on this.

>are used, it would probably makes sense to define at least 128 and 256 bit

Agree, that should be enough.

>and 16, but I am not sure about other sizes.

Agree, good choice.

>messages with less key re-usage.

I don’t understand the relationship between size of message and size of
nonce.

>counters for each pair-wise link which might be a space issue on the

Unique keys in each direction is in general good practice. In the case of
sending one message to multiple receivers, each receiver needs a key and a
nonce per sender. We used that as a general principle for all messages
being passed. For nonce we proposed to reuse the sequence number + a salt
(see below), so it is only the salt that is additionally stored. Moreover,
if keys are changed for each message there is anyway need to store a
random value from which new keys are derived (we used a different
approach, see below).

>the nonce space if the same key value is used in both directions.

As mentioned above, we already assumed there will be a unique sequence
number associated to this key identifier and message. The combination of
salt and sequence number becomes an unique nonce for each message which
can be used with this key until the counter wraps, when key and key
identifier needs to be updated. Since there is a processing cost to change
key for each message, we thought this construction of using the key for a
number of unique nonces could be favorable without compromising security.

Göran

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

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 12 May 2015 12:22:29 -0700

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Tuesday, May 12, 2015 5:52 AM
> To: Jim Schaad; [email-masked]
> Subject: Re: [Cose] Parameterization of CCM mode
> 
> 
> Hi Jim
> 
> https://tools.ietf.org/html/draft-selander-ace-object-security-01, let me give
> some context about what this draft intended to do that is relevant to COSE for
> those that have not read it. First of all, it did not intend to specify a generic
> compact secure message format as is the objective of COSE, see Appendix C:
> 
> The main design objective was thus to estimate a minimum message size (using
> a bespoke format called CSM) while at the same time be flexible to take into
> account the great variation of settings for which this may be applied by
> allowing different ciphersuites, lengths of key identifiers and sequence
> numbers.
> 
> As indicated by the latter, another design objective was to have built-in support
> for replay protection suitable for constrained devices independent of cipher
> suite. In this respect indexing the use of a particular key with a sequence
> numbers seemed a better candidate than nonces and time, considering storage
> and inaccuracy of clocks. Since different applications have different
> requirements in terms of number of messages we allowed a variable counter
> size and to minimize message size a default truncation of initial sequence
> number bytes containing zeros. Since different applications have varying
> degree of strictness on replay (sliding window to allow reordering etc.) we left
> to the application to define the exact processing rules. Finally, similar
> considerations was made on lengths of key identifiers, where different
> applications may require different sizes of name spaces.

I used this draft as the only one that I found with some concrete details about encryption.  I did not use it because it was either a good or bad design, just the only one that I found and thus the only starting point I had.  

> >As part of looking at the sizes of encodings for items, I was looking
> >at the use of CCM mode and trying to make guesses about what the
> >parameters are that are going to be used in constrained devices.
> >Trying to get the info from
> >https://tools.ietf.org/html/draft-selander-ace-object-security-01 did
> I believe for UDP you would require 16 octets in the normal case, someone else
> could correct me on this.

I would start by suggesting that you re-read the CCM draft.  L is a parameter of the CCM algorithm, not a value in the wrapper.  The length of the plain text is included in the computation of the authentication value.  This is not anything about COSE or CSM, it is about CCM.

> 
> >
> >The key size does not affect the size of the output so it is not a big
> >issue relative to things.  While I would guess that generally only
> >128-bit keys are used, it would probably makes sense to define at least
> >128 and 256 bit key algorithms
> 
> >The size of the authentication fields is currently defined as 8 from
> >the Selander draft.  It would make sense to have at least two sizes
> >defined -
> >8
> >constrained devices this could be a very small value as a value of 2
> >would all for encrypting 2^(8*2) bytes and would allow for the key to
> >be used a lot as one then has a nonce of 15-2=13 bytes (allowing for a
> >key to be used ~ 2^13 times assuming no birthday attacks).  Nonce
> >values as 15-L bytes long and nonce values must not be re-used.  On the
> >other hand, for a more general usage it makes sense to have a larger
> >value of L to allow for bigger messages with less key re-usage.
> 
> I don’t understand the relationship between size of message and size of nonce.

Again, I think you need to read the CCM draft.   It has to do with how the counter field is built internally for CCM.

> 
> >
> >The Selander draft appears to make the assumption that different keys
> >are used in each direction when encrypting messages.  This makes one
> >problem easier - there is no need to divide up the nonce space so that
> >nonce values are not re-used when encrypting messages.  It also makes
> >nonce usage easier because there is no need to try and synchronize the
> >nonce value usage between the two parties.  On the other hand, it means
> >that there is more data that needs to be keep on the device as you now
> >need 2 keys and 2 nonce counters for each pair-wise link which might be
> >a space issue on the device.
> 
> 
> Unique keys in each direction is in general good practice. In the case of sending
> one message to multiple receivers, each receiver needs a key and a nonce per
> sender. We used that as a general principle for all messages being passed. For
> nonce we proposed to reuse the sequence number + a salt (see below), so it is
> only the salt that is additionally stored. Moreover, if keys are changed for each
> message there is anyway need to store a random value from which new keys
> are derived (we used a different approach, see below).
> 
> >
> >In the Selander draft, there was the idea of having both a nonce
> >counter and salt value which is used to construct the nonce used in the
> >encryption step.
> >As far as I know there is no security reason to salt the nonce unless
> >there is an expectation that the keys would ever be re-used.  If new
> >keys are generated each time that keys are generated then the salt is
> >probably not
> number associated to this key identifier and message. The combination of salt
> and sequence number becomes an unique nonce for each message which can
> be used with this key until the counter wraps, when key and key identifier needs
> to be updated. Since there is a processing cost to change key for each message,
> we thought this construction of using the key for a number of unique nonces
> could be favorable without compromising security.

Again - I think you need to read and understand the CCM draft.  I don't believe that the salt is required for anything, just the nonce works.  There is an independent counter for each message.  When you say counter above I am assuming that you are talking about a nonce counter.    Having a salt value potentially decreases the number of times that the same key can be used as it reduces the range of the sequence number.

jim

> 
> 
> 
> Göran
> 
> 
> >
> >While we need to do more research on figuring out how many times a key
> >can be used based on the nonce length, this is probably not dependent
> >on the values of L that we want to standardize.  The more items we
> >standardize the more selection different protocols will have, but I
> >don't know how much parameterization the implementations support or if
> >they are using fixed parameterization.
> >
> >Jim
> >
> >

---

From: Göran Selander <[email-masked]>
Date: Wed, 13 May 2015 08:22:57 +0000

On 2015-05-12 21:22, "Jim Schaad" <[email-masked]> wrote:

>I would start by suggesting that you re-read the CCM draft.  L is a
>parameter of the CCM algorithm, not a value in the wrapper.  The length
>of the plain text is included in the computation of the authentication
>value.  This is not anything about COSE or CSM, it is about CCM.
>
>> 
>> >
>Again, I think you need to read the CCM draft.   It has to do with how
>the counter field is built internally for CCM.
>
>> 
>> >
>Again - I think you need to read and understand the CCM draft.  I don't
>believe that the salt is required for anything, just the nonce works.
>There is an independent counter for each message.  When you say counter
>above I am assuming that you are talking about a nonce counter.    Having
>a salt value potentially decreases the number of times that the same key
>can be used as it reduces the range of the sequence number.

OK, point taken, sorry for being ignorant. It has been an ambition to base
the proposal on the same primitives as is recommended by CoAP, where I
believe L=3 (i.e. 12 bytes nonce) is default, following RFC6655. However
in Appendix C and in the security considerations of our draft we assume
that the entire AES IV of 16 bytes, partitioned into 8 bytes salt
(established out of band) and 8 bytes sequence number (included in the
message), is available as nonce for CCM - which is plain wrong. Changing
that from to 4 bytes salt would correct that error and harmonize with
RFC6655. I would assume L=3 is a strong candidate for COSE. RFC4309
mandates L=4 to accommodate jumbograms, but I don’t know if that is in
scope of COSE.

Göran