Subject: [core] Review draft-ietf-core-object-security-05

From: Jim Schaad <[email-masked]>
Date: Tue, 10 Oct 2017 23:06:58 -0700

This update had a few things that came in out of left field and maybe a
couple of them should have stayed there.

0.  Document structure - define a short name to be used as the header of
each page.

1.  Introduction:  I am not sure what is meant by a "non-empty message".
This cannot refer to the payload being empty, so I am unclear what is meant
here.

2.  Section 2 - I dislike the fact that you are moving the byte of flags
from the body to the option.  I want the flags next to the data that I am
either assembling or dis-assembling and not in a totally different location.
If you think that the option is going to have more than one value, then it
should either have its own flags or a defined structure. Please move it back
unless you have a REALLY good case and are willing to prove it.

3.  Section 3.1 - I do not understand why you are making the Send ID an
integer rather than a byte string.  There are a couple of issues with this.
First it is thought of as a byte string everywhere that it is currently
passed around - in COSE and in ACE.  Secondly, it decreases the number of
ids that are possible as h'01' and h'0001' are distinct while 1 and 1 are
not. 

4. Section 3.1- I am not sure that the word 'interchange' in the last
paragraph is what you want to use.  This does not read as proper English
when I read it.  "Endpoints can operator in either or both roles as client
and server and use the same security context for those roles."

5. Section 3.2.1 - In the structure info - you have id as a bstr, but it was
defined as an integer previously.  You need to harmonize this.
Additionally, it should be "alg : int / tstr," to match the definition of an
algorithm identifier in COSE.   Also section 5.3

6. Section 3.3 - s/1, For AES/1, for AES/

7.  Section 3.3 - you have a requirement in the last sentence about the
length of sender IDs.  How should this be enforced given that IDs are
integers, does this imply a restriction on the range of integers to be used?

8.  Section 4.3 - I am not sure that this section should start "Most CoAP
header fields..."  Looking at the table, it appears to be about 50-50 and
the assumption is new fields will probably be internal.  I think 'some' may
be better.

9.  Section 5 - I would like to have the Partial IV have a length of 1 in
the event that the partial iv is zero.   Ditto kid

10.  Section 5 - The rule of the SHALL NOT for Partial IV worries me for
group messaging.  It may cause problems you don't want.  There are no real
problems, except for optimization, to using the reflected Partial IV value.
Please rethink this.  Ditto kid

11.  Section 5.1 - Does this mean that the Partial IV is limited to 2^(5*8)
different values?  If you exceed this is a new context required or do you
wrap or something else?

12. Section 5.1 - what is the purpose of putting the ID of the PIV generator
in the nonce value?  Please put in text that will justify this.   Given that
the keys are different, is there any need for this?

13. Section 5.1 - Please use a different symbol in the figure than +, this
could be read as addition rather than xor.

14.  Section 5.3 - You need a rule for options for dealing with a repeated
option.

15.  Section 6.1 - s/request's ID/requestor's ID/

16. Section 7.4 step 8 - It would appear that if there is an inner option
which is present on the outer message but not present on the inner message,
then it would not be removed.  Is that what is desired?

17.  Section 8.3 - is there a specific error to return here, or is just the
"can't find a kid" error?  Please document.

---

From: Göran Selander <[email-masked]>
Date: Thu, 12 Oct 2017 11:35:55 +0000

Hi Jim,

Many thanks for the review.

As mentioned in the announcement this version compiles all the proposed
final changes, and, admittedly, the rationale for all proposals has not
been discussed in detail so it is good that we can do that on the mailing
list now. 

Answers inline and a couple of questions back. Some of the comments are
already addressed in https://github.com/core-wg/oscoap

>0.  Document structure - define a short name to be used as the header of

Done.

>This cannot refer to the payload being empty, so I am unclear what is

"Empty Message” is actually defined in RFC7252. I capitalised “Empty” for
clarity.

>unless you have a REALLY good case and are willing to prove it.

Yes, this was one thing that wasn’t discussed. Here is the reason:

The encryption of Code lead to the simplification that the compressed COSE
object is now always transported in the CoAP payload of the OSCORE
message. Hence the Object-Security option would have merely become an
indicator of whether this was an OSCORE message or not. But CoAP options
has a built-in length value, and part of the compressed COSE Object also
contains length values of the context parameters, so we could save another
byte by removing one length indicator from the compressed COSE - that of
the kid - and placing the kid in the option. Instead of just moving the
kid, we moved the kid and everything before the kid - i.e. also the flag
byte - into the option, so the compressed COSE became a concatenation of
option and payload.

If people thinks this unduly complicates processing we revert back.
Another alternative is to keep the kid in the option and have everything
except the kid in the payload. That way the flag byte comes first in the
payload, but you still need to look in the option to get the kid.

What is the preference?

a. Change back to compressed COSE in payload
b. Have just the kid in the option
c. Keep it as currently specified with the compressed COSE object equal to
the concatenation of option and payload

>ids that are possible as h'01' and h'0001' are distinct while 1 and 1 are

In order to easily verify uniqueness of (key, nonce) pairs in the current
setup with a common IV and the reuse of nonce in responses (also in the
group communication setting) the Sender ID is now included in the nonce
generation. With this construction, all nonces coming from a particular
sender has a certain prefix, which will not coincide with a nonce
generated by another sender.

The two byte strings you mention are distinct, but would also need to be
mapped to distinct byte strings of fixed length in order to do the XOR
with the common IV. With Sender ID being an integer the uniqueness
property is easier to establish. Still the SID is converted into a CBOR
byte string when used. I added text on that.

>and server and use the same security context for those roles."

Done

>algorithm identifier in COSE.   Also section 5.3

Done

>6. Section 3.3 - s/1, For AES/1, for AES/

Done

>integers, does this imply a restriction on the range of integers to be

Yes, the intent is that random Sender IDs MUST be generated in a large
range of integers. I made an update to clarify that.

>the assumption is new fields will probably be internal.  I think 'some'

Actually, the header fields are not the options but the 4 bytes header
including things like Type, Code, Message ID etc. So I believe that the
statement is true. I added text on that.

>the event that the partial iv is zero.   Ditto kid

The intent here is to save these bytes, is there an issue?

>Please rethink this.  Ditto kid

For group communication, the current construction never requires a Partial
IV in the response. (That draft needs to be updated.) But kid is needed in
the response. 

In previous versions of the two drafts, we have had normative text in the
OSCOAP draft which was contradicted in the case of group OSCOAP, but maybe
it is better to relax the OSCOAP specification?

I made the following change on Github:

- keep “Partial IV SHALL NOT be present in responses”
- replace kid "SHALL NOT be present in responses” to “MAY be omitted in
responses"

>different values? 

Yes.

>If you exceed this is a new context required or do you
>wrap or something else?

New context. The security considerations state the maximum sequence
number, I added text about new context.

>the keys are different, is there any need for this?

As discussed above, this makes it easy to verify the (key, nonce)
uniqueness.

>could be read as addition rather than xor.

Done

>14.  Section 5.3 - You need a rule for options for dealing with a repeated

Why is repeated Class I options an issue?

>15.  Section 6.1 - s/request's ID/requestor's ID/

Done 

>then it would not be removed.  Is that what is desired?

It would already be removed in step 2:

“2. Discard the message Code and all non-special Class E options from the
message."

>"can't find a kid" error?  Please document.

I added a reference to the processing steps of verifying the request which
should capture all cases.

Göran

---

From: Jim Schaad <[email-masked]>
Date: Thu, 12 Oct 2017 11:07:50 -0700

See inline - I have trimmed some items.

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Thursday, October 12, 2017 4:36 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-core-object-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: Review draft-ietf-core-object-security-05
> 
> Hi Jim,
> 
> final changes, and, admittedly, the rationale for all proposals has not been
> discussed in detail so it is good that we can do that on the mailing list now.
> 
> 

> >This cannot refer to the payload being empty, so I am unclear what is
> >meant here.
> 

Consider a reference given that it is important people get this part right.

> >
> >2.  Section 2 - I dislike the fact that you are moving the byte of
> >flags from the body to the option.  I want the flags next to the data
> >that I am either assembling or dis-assembling and not in a totally
> >different location.
> >If you think that the option is going to have more than one value, then
> >it should either have its own flags or a defined structure. Please move
> >it back unless you have a REALLY good case and are willing to prove it.
> 
> the kid - and placing the kid in the option. Instead of just moving the kid, we
> moved the kid and everything before the kid - i.e. also the flag byte - into the
> option, so the compressed COSE became a concatenation of option and
> payload.
> 
> a. Change back to compressed COSE in payload b. Have just the kid in the
> option c. Keep it as currently specified with the compressed COSE object
> equal to the concatenation of option and payload

C does not really make any sense to me. 
B is fine - and you could remove the bit flag for kid from the bit array.

It might be "useful" to move all of the key identification code to the option, but that would mean that you would no longer save the byte.  However keys could then be located before decoding the rest of the message.  This means that you would have both kid and context in the option.  The problem is trying to figure out how to get the kid to have an implicit length and the context being optional.  I don’t see a way to do this w/o adding a byte however.

> >passed around - in COSE and in ACE.  Secondly, it decreases the number
> >of ids that are possible as h'01' and h'0001' are distinct while 1 and
> >1 are not.
> 
> In order to easily verify uniqueness of (key, nonce) pairs in the current setup
> with a common IV and the reuse of nonce in responses (also in the group
> communication setting) the Sender ID is now included in the nonce
> generation. With this construction, all nonces coming from a particular sender
> has a certain prefix, which will not coincide with a nonce generated by
> another sender.

Uniqueness could easily be tested after left padding with zeros if that is really something that needs to be done.

> mapped to distinct byte strings of fixed length in order to do the XOR with
> the common IV. With Sender ID being an integer the uniqueness property is
> easier to establish. Still the SID is converted into a CBOR byte string when
> used. I added text on that.

For this document that is not a strict requirement that I can see.  Given that the keys are going to be distinct, the fact that the same IVs are being used is not a problem.  The only issue would be if both the sender and the recipient had the same identifier after padding has been added.  In that case one could not easily distinguish between reflection and non-reflection cases based on the IV by itself.  However that should not be a problem as we don't distinguish those cases using the IV today.  The kid is used and those would be distinct.

If this is a real restriction, it could be added as an additional restriction for the group document and ignored here.

> Yes, the intent is that random Sender IDs MUST be generated in a large range
> of integers. I made an update to clarify that.
> 
> >
> >8.  Section 4.3 - I am not sure that this section should start "Most
> >CoAP header fields..."  Looking at the table, it appears to be about
> >50-50 and the assumption is new fields will probably be internal.  I think
> 'some'
> >may
> >be better.
> 

Yeah, you are right - I was thinking options.

> The intent here is to save these bytes, is there an issue?

Saving one byte in this case does not seem to be that useful. For the IV it would only apply to a single message. Having a value for consistency is probably more helpful.

> 
> 
> >
> >10.  Section 5 - The rule of the SHALL NOT for Partial IV worries me
> >for group messaging.  It may cause problems you don't want.  There are
> >no real problems, except for optimization, to using the reflected
> >Partial IV value.
> IV in the response. (That draft needs to be updated.) But kid is needed in the
> response.

Is that true if there were an observe in the group communication?

> OSCOAP draft which was contradicted in the case of group OSCOAP, but
> maybe it is better to relax the OSCOAP specification?
> 
> >If you exceed this is a new context required or do you wrap or
> >something else?
> 

Just so we are clear, this may be a smaller number that is imposed by the algorithm.

> As discussed above, this makes it easy to verify the (key, nonce) uniqueness.
> 
> 
> 
> >
> >14.  Section 5.3 - You need a rule for options for dealing with a
> >repeated option.
> 
> 

Order of the options is not uniquely defined at present.  One will always order the option number in increasing order due to the delta encoding, however if you have foo=delta;foo=bar and they are re-ordered by an intermediary then validation would fail.

> >16. Section 7.4 step 8 - It would appear that if there is an inner
> >option which is present on the outer message but not present on the
> >inner message, then it would not be removed.  Is that what is desired?
> 
> 

It would be easier to understand if these rules are combined.

Jim

---

From: Göran Selander <[email-masked]>
Date: Fri, 13 Oct 2017 14:18:59 +0000

Hi Jim,

On 2017-10-12 20:07, "Jim Schaad" <[email-masked]> wrote:

>>been

Both the previous and the following sentence reference RFC 7252, but I've
added a reference in this sentence also.

>>kid, we
>It might be "useful" to move all of the key identification code to the
>option, but that would mean that you would no longer save the byte.
>However keys could then be located before decoding the rest of the
>message.  This means that you would have both kid and context in the
>option.  The problem is trying to figure out how to get the kid to have
>an implicit length and the context being optional.  I don’t see a way to
>do this w/o adding a byte however.

I opened an issue about changing to option B:

https://github.com/core-wg/oscoap/issues/179

>>sender
>Uniqueness could easily be tested after left padding with zeros if that
>is really something that needs to be done.

I don’t understand how uniqueness can be tested after left padding with
zeroes - would not that on the contrary remove the difference between them?

>>with
>For this document that is not a strict requirement that I can see.  Given
>that the keys are going to be distinct, the fact that the same IVs are
>being used is not a problem.  The only issue would be if both the sender
>and the recipient had the same identifier after padding has been added.
>In that case one could not easily distinguish between reflection and
>non-reflection cases based on the IV by itself.  However that should not
>be a problem as we don't distinguish those cases using the IV today.  The
>kid is used and those would be distinct.
>
>If this is a real restriction, it could be added as an additional
>restriction for the group document and ignored here.
>

Let’s go over the different cases. Each endpoint has a unique key for
sending. The key is used

1. to protect a request (in the role of client)
2. to protect an ordinary response (in the role of the server)
3. to protect a notification (in the role of the server, in the case of
Observe)

In case 1 and 3, the endpoint is in control of the Partial IV used in the
nonce. But in case 2 it is not, since the same nonce is used as in the
request it is responding to. So even in the case of neither group
communication nor observe, we need to ensure that the nonce used in the
request is distinct from the nonce used in a response. In -04 the first
bit of the nonce was used to partition the IV-space. In -05 the sender ID
is included in the nonce generation such that nonces generated by
different senders become different by construction, and then it
automatically applies to groups.

One way to generate a group is to start with two endpoints and then add
more endpoints as you go. In that case there is an advantage if the same
handling of security context applies to point-to-point as groups.

>>range
>Saving one byte in this case does not seem to be that useful.
>For the IV it would only apply to a single message. Having a value for
>consistency is probably more helpful.

I would agree for the Partial IV since this is a single message in a
potentially long exchange of messages. However, for the kid, where the
client would typically use kid=0 this would be every message sent. With
issue #179, kid would anyway be treated differently, so it should not
matter if these two parameters are handled differently. Would you be OK
with only applying this to the Partial IV?

https://github.com/core-wg/oscoap/issues/180

>Is that true if there were an observe in the group communication?

According to RFC7390 CoAP Observe does not support a group communication
mode, so we didn’t have that as part of the design goals.

>Just so we are clear, this may be a smaller number that is imposed by the

Right. Security consideration reads:

"The maximum sender sequence number is dependent on the AEAD algorithm.
The maximum sender sequence number SHALL be 2^40 - 1, or any algorithm
specific lower limit, after which a new security context must be
generated. The compression mechanism assumes that the Partial IV is 40
bits or less."

Do you miss anything there?

>Order of the options is not uniquely defined at present.  One will always
>order the option number in increasing order due to the delta encoding,
>however if you have foo=delta;foo=bar and they are re-ordered by an
>intermediary then validation would fail.

You are right, that is indeed specifically for class I options, I opened
an issue:

https://github.com/core-wg/oscoap/issues/181

Since there are no options of this kind yet, I am tempted to leave this as
a requirement for those introducing the new repeatable Class I option to
also define an ordering of the option values.

>It would be easier to understand if these rules are combined.

We could move step 2 to a new step 7. That, however, would potentially
make it more difficult to distinguish between pre-existing outer options
and decrypted options (in step 2 there exists only outer options since the
decryption operation has not yet been performed). Alternatively we could
introduce some text explaining or referencing between these different
operations. What is preferred?

Göran

---

From: Jim Schaad <[email-masked]>
Date: Fri, 13 Oct 2017 10:39:24 -0700

> Sent: Friday, October 13, 2017 7:19 AM
> >> As mentioned in the announcement this version compiles all the
> >>proposed  final changes, and, admittedly, the rationale for all
> >>proposals has not been  discussed in detail so it is good that we can
> >>do that on the mailing list now.
> >>
> >>
> >> Answers inline and a couple of questions back. Some of the comments
> >> are already addressed in https://github.com/core-wg/oscoap
> >>
> >>
> >> >This update had a few things that came in out of left field and
> >> >maybe a couple of them should have stayed there.
> >> >
> >
> >
> >> >3.  Section 3.1 - I do not understand why you are making the Send ID
> >> >an integer rather than a byte string.  There are a couple of issues
> >> >with this.
> >> >First it is thought of as a byte string everywhere that it is
> >> >currently passed around - in COSE and in ACE.  Secondly, it
> >> >decreases the number of ids that are possible as h'01' and h'0001'
> >> >are distinct while 1 and
> >> >1 are not.
> >>
> >> In order to easily verify uniqueness of (key, nonce) pairs in the
> >>current setup  with a common IV and the reuse of nonce in responses
> >>(also in the group  communication setting) the Sender ID is now
> >>included in the nonce  generation. With this construction, all nonces
> >>coming from a particular sender  has a certain prefix, which will not
> >>coincide with a nonce generated by  another sender.
> >

I was giving an example of how you could test for uniqueness using a byte array rather than an integer.  I thought that was what you were looking at here.

> 
> >
> >>
> >> The two byte strings you mention are distinct, but would also need to
> >>be  mapped to distinct byte strings of fixed length in order to do the
> >>XOR with  the common IV. With Sender ID being an integer the
> >>uniqueness property is  easier to establish. Still the SID is
> >>converted into a CBOR byte string when  used. I added text on that.
> >
> >For this document that is not a strict requirement that I can see.
> >Given that the keys are going to be distinct, the fact that the same
> >IVs are being used is not a problem.  The only issue would be if both
> >the sender and the recipient had the same identifier after padding has
> been added.
> >non-reflection cases based on the IV by itself.  However that should
> >not be a problem as we don't distinguish those cases using the IV
> >today.  The kid is used and those would be distinct.
> >
> 1. to protect a request (in the role of client) 2. to protect an ordinary
> response (in the role of the server) 3. to protect a notification (in the role of
> the server, in the case of
> Observe)
> 
> In case 1 and 3, the endpoint is in control of the Partial IV used in the nonce.
> But in case 2 it is not, since the same nonce is used as in the request it is
> responding to. So even in the case of neither group communication nor
> observe, we need to ensure that the nonce used in the request is distinct
> from the nonce used in a response. In -04 the first bit of the nonce was used
> to partition the IV-space. In -05 the sender ID is included in the nonce
> generation such that nonces generated by different senders become
> different by construction, and then it automatically applies to groups.
> 

But in that case you understand in advance that you are going to create a group and can apply any restrictions from the start.  Another way to create a group is to merge two groups together and re-key, that would not necessarily work because you might have assigned the same id in both cases.  If the two groups used different length ids then it would be possible. 

There are lots of ways to create groups that are going to have problems with how IDs are assigned unless there is an intent that a group is going to be created from the start.  

A different way to do the same thing in terms of building things would be

XX YYYY ZZ

Where XX is the length of kid
YYY is the kid padded (either right or left) with a constant and ZZ is the partial IV.

One could play games and assign a padding value on a per recipient basis which could be used for all sorts of separation of spaces.    I lost one byte at the front from the length of ID, but I got a lot more kid values from just using an integer value for shorter kids.

> >> >9.  Section 5 - I would like to have the Partial IV have a length of
> >> >1
> >>in
> I would agree for the Partial IV since this is a single message in a potentially
> long exchange of messages. However, for the kid, where the client would
> typically use kid=0 this would be every message sent. With issue #179, kid
> would anyway be treated differently, so it should not matter if these two
> parameters are handled differently. Would you be OK with only applying this
> to the Partial IV?
> 

If you omit the flag for existence, then you would need to have the byte for existence in the option.  Having the flag not with the value is not something that I would prefer.

> >> >for group messaging.  It may cause problems you don't want.  There
> >> >are no real problems, except for optimization, to using the
> >> >reflected Partial IV value.
> >> For group communication, the current construction never requires a
> >>Partial  IV in the response. (That draft needs to be updated.) But kid
> >>is needed in the  response.
> >
> According to RFC7390 CoAP Observe does not support a group
> communication mode, so we didn’t have that as part of the design goals.

I would design with this in mind given the different ways that this might come about.  I think that an observe type think in group communications might end up coming into existence.  I would do a defensive design myself.

> >> In previous versions of the two drafts, we have had normative text in
> >>the  OSCOAP draft which was contradicted in the case of group OSCOAP,
> >>but  maybe it is better to relax the OSCOAP specification?
> >>
> >> - replace kid "SHALL NOT be present in responses” to “MAY be omitted
> >> in responses"
> >>
> >>
> >>
> specific lower limit, after which a new security context must be generated.
> The compression mechanism assumes that the Partial IV is 40 bits or less."

It is not the compression mechanism that is assuming this, it is the method for building nonces that is assuming this.

> >Order of the options is not uniquely defined at present.  One will
> >always order the option number in increasing order due to the delta
> >encoding, however if you have foo=delta;foo=bar and they are re-ordered
> >by an intermediary then validation would fail.
> 
> You are right, that is indeed specifically for class I options, I opened an issue:
> 
> Since there are no options of this kind yet, I am tempted to leave this as a
> requirement for those introducing the new repeatable Class I option to also
> define an ordering of the option values.

Right, and each one could define a different mechanism.  This is not what I want to here.

Jim

> >> “2. Discard the message Code and all non-special Class E options from
> >>the  message."
> >
> make it more difficult to distinguish between pre-existing outer options and
> decrypted options (in step 2 there exists only outer options since the

---

From: Francesca Palombini <[email-masked]>
Date: Mon, 16 Oct 2017 11:25:27 +0000

Hi all,

We are planning to discuss Jim's comments (and the latest OSCOAP updates) in a hangout call today (16:00 CEST).
Sorry for the short notice. Welcome to join if you are interested.

Time: https://www.worldtimebuddy.com/?qm=1&lid=100,2673730,8&h=2673730&date=2017-10-16&sln=16-17 
Hangout link: https://hangouts.google.com/call/2zt4eyw22rdu3ned4ya72arifme 

Francesca

> From: Jim Schaad [mailto:[email-masked]]
> Sent: den 13 oktober 2017 19:39
> To: Göran Selander <[email-masked]>; draft-ietf-core-object-
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Review draft-ietf-core-object-security-05
> 
> 
> 
> > >>proposals has not been  discussed in detail so it is good that we
> > >>can do that on the mailing list now.
> > >>
> > >>
> > >> >3.  Section 3.1 - I do not understand why you are making the Send
> > >> >ID an integer rather than a byte string.  There are a couple of
> > >> >issues with this.
> > >>included in the nonce  generation. With this construction, all
> > >>nonces coming from a particular sender  has a certain prefix, which
> > >>will not coincide with a nonce generated by  another sender.
> > >
> > >Uniqueness could easily be tested after left padding with zeros if
> > >that is really something that needs to be done.
> >
> > I don’t understand how uniqueness can be tested after left padding
> > with zeroes - would not that on the contrary remove the difference
> > between them?
> 
> I was giving an example of how you could test for uniqueness using a byte
> array rather than an integer.  I thought that was what you were looking at
> here.
> 
> >
> > >
> > >>
> > >> The two byte strings you mention are distinct, but would also need
> > >>to be  mapped to distinct byte strings of fixed length in order to
> > >>do the XOR with  the common IV. With Sender ID being an integer the
> > 1. to protect a request (in the role of client) 2. to protect an
> > ordinary response (in the role of the server) 3. to protect a
> > notification (in the role of the server, in the case of
> > Observe)
> >
> nonce.
> > But in case 2 it is not, since the same nonce is used as in the
> > communication nor observe, we need to ensure that the nonce used in
> > the request is distinct from the nonce used in a response. In -04 the
> > first bit of the nonce was used to partition the IV-space. In -05 the
> > sender ID is included in the nonce generation such that nonces
> > generated by different senders become different by construction, and then
> it automatically applies to groups.
> >
> > One way to generate a group is to start with two endpoints and then
> > add more endpoints as you go. In that case there is an advantage if
> > the same handling of security context applies to point-to-point as groups.
> 
> But in that case you understand in advance that you are going to create a
> group and can apply any restrictions from the start.  Another way to create a
> group is to merge two groups together and re-key, that would not necessarily
> work because you might have assigned the same id in both cases.  If the two
> groups used different length ids then it would be possible.
> 
> There are lots of ways to create groups that are going to have problems with
> how IDs are assigned unless there is an intent that a group is going to be
> created from the start.
> 
> One could play games and assign a padding value on a per recipient basis
> which could be used for all sorts of separation of spaces.    I lost one byte at
> the front from the length of ID, but I got a lot more kid values from just using
> an integer value for shorter kids.
> 
> 
> > >For the IV it would only apply to a single message. Having a value
> > >for consistency is probably more helpful.
> >
> > client would typically use kid=0 this would be every message sent.
> > With issue #179, kid would anyway be treated differently, so it should
> > not matter if these two parameters are handled differently. Would you
> > be OK with only applying this to the Partial IV?
> >
> If you omit the flag for existence, then you would need to have the byte for
> existence in the option.  Having the flag not with the value is not something
> that I would prefer.
> 
> > >> >10.  Section 5 - The rule of the SHALL NOT for Partial IV worries
> > >> >me for group messaging.  It may cause problems you don't want.
> > >> >There are no real problems, except for optimization, to using the
> > >>Partial  IV in the response. (That draft needs to be updated.) But
> > >>kid is needed in the  response.
> > >
> I would design with this in mind given the different ways that this might come
> about.  I think that an observe type think in group communications might end
> up coming into existence.  I would do a defensive design myself.
> 
> > >> In previous versions of the two drafts, we have had normative text
> > >>in the  OSCOAP draft which was contradicted in the case of group
> > >>OSCOAP, but  maybe it is better to relax the OSCOAP specification?
> > >>
> > >> - replace kid "SHALL NOT be present in responses” to “MAY be
> > >> omitted in responses"
> > >>
> > >>
> > >>
> > >> >11.  Section 5.1 - Does this mean that the Partial IV is limited
> > >> >to
> > >> >2^(5*8)
> > >> >different values?
> > >>
> > >> Yes.
> > >>
> It is not the compression mechanism that is assuming this, it is the method
> for building nonces that is assuming this.
> 
> >
> >
> > >encoding, however if you have foo=delta;foo=bar and they are
> > >re-ordered by an intermediary then validation would fail.
> >
> > Since there are no options of this kind yet, I am tempted to leave
> > this as a requirement for those introducing the new repeatable Class I
> > option to also define an ordering of the option values.
> 
> > >> >option which is present on the outer message but not present on
> > >> >the inner message, then it would not be removed.  Is that what is
> desired?
> > >>
> > >>
> > >> “2. Discard the message Code and all non-special Class E options
> > >>from the  message."
> > >
> > make it more difficult to distinguish between pre-existing outer
> > options and decrypted options (in step 2 there exists only outer
> > options since the decryption operation has not yet been performed).
> > Alternatively we could introduce some text explaining or referencing
> > between these different operations. What is preferred?
> >
> >
> > Göran
>