Discussion:
[core] Review draft-ietf-core-object-security-05
Jim Schaad
2017-10-11 06:06:58 UTC
Permalink
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.
Göran Selander
2017-10-12 11:35:55 UTC
Permalink
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
Post by Jim Schaad
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.
Done.
Post by Jim Schaad
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.
"Empty Message” is actually defined in RFC7252. I capitalised “Empty” for
clarity.
Post by Jim Schaad
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.
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
Post by Jim Schaad
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.

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.
Post by Jim Schaad
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."
Done
Post by Jim Schaad
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
Done
Post by Jim Schaad
6. Section 3.3 - s/1, For AES/1, for AES/
Done
Post by Jim Schaad
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?
Yes, the intent is that random Sender IDs MUST be generated in a large
range of integers. I made an update to clarify that.
Post by Jim Schaad
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.
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.
Post by Jim Schaad
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
The intent here is to save these bytes, is there an issue?
Post by Jim Schaad
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
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"
Post by Jim Schaad
11. Section 5.1 - Does this mean that the Partial IV is limited to 2^(5*8)
different values?
Yes.
Post by Jim Schaad
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.
Post by Jim Schaad
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?
As discussed above, this makes it easy to verify the (key, nonce)
uniqueness.
Post by Jim Schaad
13. Section 5.1 - Please use a different symbol in the figure than +, this
could be read as addition rather than xor.
Done
Post by Jim Schaad
14. Section 5.3 - You need a rule for options for dealing with a repeated
option.
Why is repeated Class I options an issue?
Post by Jim Schaad
15. Section 6.1 - s/request's ID/requestor's ID/
Done
Post by Jim Schaad
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 already be removed in step 2:

“2. Discard the message Code and all non-special Class E options from the
message."
Post by Jim Schaad
17. Section 8.3 - is there a specific error to return here, or is just the
"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
Jim Schaad
2017-10-12 18:07:50 UTC
Permalink
See inline - I have trimmed some items.
-----Original Message-----
Sent: Thursday, October 12, 2017 4:36 AM
Subject: Re: Review draft-ietf-core-object-security-05
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
Post by Jim Schaad
This update had a few things that came in out of left field and maybe a
couple of them should have stayed there.
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.
"Empty Message” is actually defined in RFC7252. I capitalised “Empty” for
clarity.
Consider a reference given that it is important people get this part right.
Post by Jim Schaad
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 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
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.
Post by Jim Schaad
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.
Uniqueness could easily be tested after left padding with zeros if that is really something that needs to be done.
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. 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.
Post by Jim Schaad
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?
Yes, the intent is that random Sender IDs MUST be generated in a large range
of integers. I made an update to clarify that.
Post by Jim Schaad
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'
Post by Jim Schaad
may
be better.
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.
Yeah, you are right - I was thinking options.
Post by Jim Schaad
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
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.
Post by Jim Schaad
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
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.
Is that true if there were an observe in the group communication?
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?
- keep “Partial IV SHALL NOT be present in responses”
- replace kid "SHALL NOT be present in responses” to “MAY be omitted in
responses"
Post by Jim Schaad
11. Section 5.1 - Does this mean that the Partial IV is limited to 2^(5*8)
different values?
Yes.
Post by Jim Schaad
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.
Just so we are clear, this may be a smaller number that is imposed by the algorithm.
Post by Jim Schaad
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?
As discussed above, this makes it easy to verify the (key, nonce) uniqueness.
Post by Jim Schaad
14. Section 5.3 - You need a rule for options for dealing with a
repeated option.
Why is repeated Class I options an issue?
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.
Post by Jim Schaad
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?
“2. Discard the message Code and all non-special Class E options from the
message."
It would be easier to understand if these rules are combined.

Jim
Göran
Göran Selander
2017-10-13 14:18:59 UTC
Permalink
Hi Jim,
Post by Jim Schaad
See inline - I have trimmed some items.
-----Original Message-----
Sent: Thursday, October 12, 2017 4:36 AM
Subject: Re: Review draft-ietf-core-object-security-05
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
Post by Jim Schaad
This update had a few things that came in out of left field and maybe a
couple of them should have stayed there.
1. Introduction: I am not sure what is meant by a "non-empty
message".
Post by Jim Schaad
This cannot refer to the payload being empty, so I am unclear what is
meant here.
"Empty Message” is actually defined in RFC7252. I capitalised “Empty” for
clarity.
Consider a reference given that it is important people get this part right.
Both the previous and the following sentence reference RFC 7252, but I've
added a reference in this sentence also.
Post by Jim Schaad
Post by Jim Schaad
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 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
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.
I opened an issue about changing to option B:

https://github.com/core-wg/oscoap/issues/179
Post by Jim Schaad
Post by Jim Schaad
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.
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?
Post by Jim Schaad
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.
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.
Post by Jim Schaad
Post by Jim Schaad
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?
Yes, the intent is that random Sender IDs MUST be generated in a large range
of integers. I made an update to clarify that.
Post by Jim Schaad
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'
Post by Jim Schaad
may
be better.
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.
Yeah, you are right - I was thinking options.
Post by Jim Schaad
9. Section 5 - I would like to have the Partial IV have a length of 1
in
Post by Jim Schaad
the event that the partial iv is zero. Ditto kid
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.
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
Post by Jim Schaad
Post by Jim Schaad
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
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.
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.
Post by Jim Schaad
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?
- keep “Partial IV SHALL NOT be present in responses”
- replace kid "SHALL NOT be present in responses” to “MAY be omitted in
responses"
Post by Jim Schaad
11. Section 5.1 - Does this mean that the Partial IV is limited to 2^(5*8)
different values?
Yes.
Post by Jim Schaad
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.
Just so we are clear, this may be a smaller number that is imposed by the algorithm.
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?
Post by Jim Schaad
Post by Jim Schaad
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?
As discussed above, this makes it easy to verify the (key, nonce) uniqueness.
Post by Jim Schaad
14. Section 5.3 - You need a rule for options for dealing with a
repeated option.
Why is repeated Class I options an issue?
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.
Post by Jim Schaad
Post by Jim Schaad
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?
“2. Discard the message Code and all non-special Class E options from the
message."
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
Jim Schaad
2017-10-13 17:39:24 UTC
Permalink
-----Original Message-----
Sent: Friday, October 13, 2017 7:19 AM
Subject: Re: Review draft-ietf-core-object-security-05
Hi Jim,
Post by Jim Schaad
See inline - I have trimmed some items.
-----Original Message-----
Sent: Thursday, October 12, 2017 4:36 AM
Subject: Re: Review draft-ietf-core-object-security-05
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
Post by Jim Schaad
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.
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.
Post by Jim Schaad
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.
Post by Jim Schaad
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.
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.
Post by Jim Schaad
Post by Jim Schaad
9. Section 5 - I would like to have the Partial IV have a length of 1
in
Post by Jim Schaad
the event that the partial iv is zero. Ditto kid
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.
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
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.
Post by Jim Schaad
Post by Jim Schaad
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
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.
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.
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.
Post by Jim Schaad
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?
- keep “Partial IV SHALL NOT be present in responses”
- replace kid "SHALL NOT be present in responses” to “MAY be omitted
in responses"
Post by Jim Schaad
11. Section 5.1 - Does this mean that the Partial IV is limited to 2^(5*8)
different values?
Yes.
Post by Jim Schaad
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.
Just so we are clear, this may be a smaller number that is imposed by the algorithm.
"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."
It is not the compression mechanism that is assuming this, it is the method for building nonces that is assuming this.
Do you miss anything there?
Post by Jim Schaad
Post by Jim Schaad
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?
As discussed above, this makes it easy to verify the (key, nonce) uniqueness.
Post by Jim Schaad
14. Section 5.3 - You need a rule for options for dealing with a
repeated option.
Why is repeated Class I options an issue?
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.
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.
Right, and each one could define a different mechanism. This is not what I want to here.


Jim
Post by Jim Schaad
Post by Jim Schaad
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?
“2. Discard the message Code and all non-special Class E options from
the message."
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
Francesca Palombini
2017-10-16 11:25:27 UTC
Permalink
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
-----Original Message-----
Sent: den 13 oktober 2017 19:39
Subject: RE: Review draft-ietf-core-object-security-05
-----Original Message-----
Sent: Friday, October 13, 2017 7:19 AM
Subject: Re: Review draft-ietf-core-object-security-05
Hi Jim,
Post by Jim Schaad
See inline - I have trimmed some items.
-----Original Message-----
Sent: Thursday, October 12, 2017 4:36 AM
Subject: Re: Review draft-ietf-core-object-security-05
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
Post by Jim Schaad
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.
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.
Post by Jim Schaad
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.
Post by Jim Schaad
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.
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.
Post by Jim Schaad
Post by Jim Schaad
9. Section 5 - I would like to have the Partial IV have a length
of
1
in
Post by Jim Schaad
the event that the partial iv is zero. Ditto kid
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.
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
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.
Post by Jim Schaad
Post by Jim Schaad
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
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.
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.
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.
Post by Jim Schaad
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?
- keep “Partial IV SHALL NOT be present in responses”
- replace kid "SHALL NOT be present in responses” to “MAY be
omitted in responses"
Post by Jim Schaad
11. Section 5.1 - Does this mean that the Partial IV is limited
to
2^(5*8)
different values?
Yes.
Post by Jim Schaad
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.
Just so we are clear, this may be a smaller number that is imposed by the algorithm.
"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."
It is not the compression mechanism that is assuming this, it is the method
for building nonces that is assuming this.
Do you miss anything there?
Post by Jim Schaad
Post by Jim Schaad
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?
As discussed above, this makes it easy to verify the (key, nonce) uniqueness.
Post by Jim Schaad
14. Section 5.3 - You need a rule for options for dealing with a
repeated option.
Why is repeated Class I options an issue?
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
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.
Right, and each one could define a different mechanism. This is not what I want to here.
Jim
Post by Jim Schaad
Post by Jim Schaad
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?
Post by Jim Schaad
“2. Discard the message Code and all non-special Class E options
from the message."
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
Loading...