Discussion:
[core] Eric Rescorla's Discuss on
Eric Rescorla
2018-03-08 02:58:42 UTC
Permalink
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

https://mozphab-ietf.devsvcdev.mozaws.net/D3075

DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.

At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).

are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).

IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.

IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.

IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".

| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?

Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.

layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.

IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?

o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).

IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?

For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives

IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?

An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.

This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"

I.e., move the second comma

the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."

Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,

different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?

of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.

compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?

response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?

The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.

After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical

included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.

Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.

style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels

The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this

Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,

IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Göran Selander
2018-03-08 14:59:31 UTC
Permalink
Hi Eric and others who provided review comments,

Thanks for your reviews. We will get back with more detailed answers, but
just some remarks on recurring comments.

The reason for including CoAP-mappable HTTP is to handle settings like
HTTP client to CoAP server or v.v. There are a number of use cases for
this. OCF/Dave Thaler has requested this functionality for their
end-to-end REST functionality. A recent example is provided by:
https://tools.ietf.org/html/draft-ietf-ace-coap-est-00#section-6
Admittedly, the current text does not sufficiently well scope to this
setting and we will change that in addition to addressing the other
detailed comments about HTTP.

Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.

A third thing in Eric’s review is the construction of the nonce where the
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.


More later.

Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Eric Rescorla
2018-03-08 15:06:50 UTC
Permalink
Post by Göran Selander
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.
The question is what the security impact of these is.
Post by Göran Selander
A third thing in Eric’s review is the construction of the nonce where the
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients
I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?

-Ekr
Post by Göran Selander
. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.
More later.
Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Göran Selander
2018-03-08 15:23:20 UTC
Permalink
From: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Date: Thursday 8 March 2018 at 16:06
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>
Cc: The IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>, Carsten Bormann <***@tzi.org<mailto:***@tzi.org>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "core-***@ietf.org<mailto:core-***@ietf.org>" <core-***@ietf.org<mailto:core-***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>> wrote:
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.

The question is what the security impact of these is.

Yes, and we will try to address this. But it is a general property of CoAP when proxies are used.



A third thing in Eric’s review is the construction of the nonce where the
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?

The sender key is used both in the role of client making a request (with own partial IV) and in the role of server responding to a request (with the other endpoint’s partial IV).

Göran


-Ekr


. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.


More later.

Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Eric Rescorla
2018-03-08 15:39:17 UTC
Permalink
Post by Göran Selander
Date: Thursday 8 March 2018 at 16:06
(with DISCUSS and COMMENT)
On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <
Post by Göran Selander
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.
The question is what the security impact of these is.
Yes, and we will try to address this. But it is a general property of CoAP
when proxies are used.
Yes, but the whole point of this design is to protect to some extent
against malicious proxies.


A third thing in Eric’s review is the construction of the nonce where the
Post by Göran Selander
Post by Göran Selander
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients
I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?
The sender key is used both in the role of client making a request (with
own partial IV) and in the role of server responding to a request (with the
other endpoint’s partial IV).
This seems extremely hard to analyze. You should just use separate keys.

-Ekr
Post by Göran Selander
Göran
-Ekr
Post by Göran Selander
. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.
More later.
Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/stat
ement/discuss-criteria.html
Post by Eric Rescorla
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the
previously
Post by Eric Rescorla
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Göran Selander
2018-03-08 16:24:23 UTC
Permalink
From: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Date: Thursday 8 March 2018 at 16:39
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>
Cc: The IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>, Carsten Bormann <***@tzi.org<mailto:***@tzi.org>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "core-***@ietf.org<mailto:core-***@ietf.org>" <core-***@ietf.org<mailto:core-***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 7:23 AM, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>> wrote:


From: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Date: Thursday 8 March 2018 at 16:06
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>
Cc: The IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>, Carsten Bormann <***@tzi.org<mailto:***@tzi.org>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "core-***@ietf.org<mailto:core-***@ietf.org>" <core-***@ietf.org<mailto:core-***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>> wrote:
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.

The question is what the security impact of these is.

Yes, and we will try to address this. But it is a general property of CoAP when proxies are used.

Yes, but the whole point of this design is to protect to some extent against malicious proxies.

Yes, but not against proxy operations which are defined as legitimate by CoAP and/or where there are other means to verify the operation.



A third thing in Eric’s review is the construction of the nonce where the
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?

The sender key is used both in the role of client making a request (with own partial IV) and in the role of server responding to a request (with the other endpoint’s partial IV).

This seems extremely hard to analyze. You should just use separate keys.

That is an alternative solution which is less optimised e.g. in terms of size of group communication security context. Let us come back on that.

Göran


-Ekr


Göran


-Ekr


. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.


More later.

Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Eric Rescorla
2018-03-08 17:05:58 UTC
Permalink
Post by Göran Selander
Date: Thursday 8 March 2018 at 16:39
(with DISCUSS and COMMENT)
On Thu, Mar 8, 2018 at 7:23 AM, Göran Selander <
Post by Göran Selander
Date: Thursday 8 March 2018 at 16:06
(with DISCUSS and COMMENT)
On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <
Post by Göran Selander
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.
The question is what the security impact of these is.
Yes, and we will try to address this. But it is a general property of
CoAP when proxies are used.
Yes, but the whole point of this design is to protect to some extent
against malicious proxies.
Yes, but not against proxy operations which are defined as legitimate by
CoAP and/or where there are other means to verify the operation.
Whether these operations are in fact safe is the question at hand. I will
wait for your detailed analysis.

-Ekr
Post by Göran Selander
A third thing in Eric’s review is the construction of the nonce where the
Post by Göran Selander
Post by Göran Selander
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients
I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?
The sender key is used both in the role of client making a request (with
own partial IV) and in the role of server responding to a request (with the
other endpoint’s partial IV).
This seems extremely hard to analyze. You should just use separate keys.
That is an alternative solution which is less optimised e.g. in terms of
size of group communication security context. Let us come back on that.
Göran
-Ekr
Post by Göran Selander
Göran
-Ekr
Post by Göran Selander
. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.
More later.
Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/stat
ement/discuss-criteria.html
Post by Eric Rescorla
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-i
e]).
Post by Eric Rescorla
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class
I
Post by Eric Rescorla
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the
previously
Post by Eric Rescorla
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you
will
Post by Eric Rescorla
be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that
it
Post by Eric Rescorla
is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Göran Selander
2018-03-08 17:53:26 UTC
Permalink
From: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Date: Thursday 8 March 2018 at 18:05
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>
Cc: The IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>, Carsten Bormann <***@tzi.org<mailto:***@tzi.org>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "core-***@ietf.org<mailto:core-***@ietf.org>" <core-***@ietf.org<mailto:core-***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 8:24 AM, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>> wrote:


From: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Date: Thursday 8 March 2018 at 16:39
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>
Cc: The IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>, Carsten Bormann <***@tzi.org<mailto:***@tzi.org>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "core-***@ietf.org<mailto:core-***@ietf.org>" <core-***@ietf.org<mailto:core-***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 7:23 AM, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>> wrote:


From: Eric Rescorla <***@rtfm.com<mailto:***@rtfm.com>>
Date: Thursday 8 March 2018 at 16:06
To: Göran Selander <***@ericsson.com<mailto:***@ericsson.com>>
Cc: The IESG <***@ietf.org<mailto:***@ietf.org>>, "draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>" <draft-ietf-core-object-***@ietf.org<mailto:draft-ietf-core-object-***@ietf.org>>, Carsten Bormann <***@tzi.org<mailto:***@tzi.org>>, Jaime Jiménez <***@ericsson.com<mailto:***@ericsson.com>>, "core-***@ietf.org<mailto:core-***@ietf.org>" <core-***@ietf.org<mailto:core-***@ietf.org>>, "***@ietf.org<mailto:***@ietf.org>" <***@ietf.org<mailto:***@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)



On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <***@ericsson.com<mailto:***@ericsson.com>> wrote:
Another recurring comment is the impact of a proxy changing certain CoAP
message fields like e.g. Message ID, Token or Uri-Host. Since CoAP defines
legitimate proxy operations, these message fields cannot be integrity
protected end-to-end. Current security solutions either does not allow
proxy operations or leave all message fields unprotected in the proxy. We
will try to make this more clear.

The question is what the security impact of these is.

Yes, and we will try to address this. But it is a general property of CoAP when proxies are used.

Yes, but the whole point of this design is to protect to some extent against malicious proxies.

Yes, but not against proxy operations which are defined as legitimate by CoAP and/or where there are other means to verify the operation.

Whether these operations are in fact safe is the question at hand. I will wait for your detailed analysis.

Meanwhile, people interested in the problem statement can read this:
https://tools.ietf.org/html/draft-hartke-core-e2e-security-reqs-03

Göran


-Ekr



A third thing in Eric’s review is the construction of the nonce where the
ID is included. The reason for this is to handle endpoints switching roles
(CoAP client <-> CoAP server) which is supported by CoAP, and in
particular
group communications with one sender and multiple recipients

I don't see how that is relevant, given that you already have key separation
for the sender key, what separate information is there in the nonce?

The sender key is used both in the role of client making a request (with own partial IV) and in the role of server responding to a request (with the other endpoint’s partial IV).

This seems extremely hard to analyze. You should just use separate keys.

That is an alternative solution which is less optimised e.g. in terms of size of group communication security context. Let us come back on that.

Göran


-Ekr


Göran


-Ekr


. While the
latter is the topic of a separate draft
(draft-tiloca-core-multicast-oscoap) and the properties in that setting is
out of scope of this draft, we will add more explanation to the security
design and the unicast security properties in general to this draft.


More later.

Göran
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values. I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
Göran Selander
2018-03-30 11:03:53 UTC
Permalink
Hi Eric,
Thanks for good comments. Version -12 submitted. Replies inline labelled
[GS].
Post by Eric Rescorla
Eric Rescorla has entered the following ballot position for
draft-ietf-core-object-security-09: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
https://datatracker.ietf.org/doc/draft-ietf-core-object-security/
----------------------------------------------------------------------
----------------------------------------------------------------------
https://mozphab-ietf.devsvcdev.mozaws.net/D3075
DISCUSS
My overall concern with this document is that I am unable to evaluate
the security properties of the system. I have described a number of
issues below, but the basic problem is that this sort of partial
protection is extremely hard to reason about and the security
considerations do not do an adequate job of evaluating the impact of
proxies modifying these values.
[GS] A new appendix (D) is written which hopefully addresses this concern.
Post by Eric Rescorla
I am similarly concerned about the
HTTP mapping and link section which seems extremely sketchy and has
essentially no security analysis, and yet potentially have a lot
of landmines.
[GS] Please see our response to Martin Thomson’s review.
Post by Eric Rescorla
At minimum, this document needs to walk through the implications
of modifications by the proxy to every unprotected field in
the pure CoAP context as well as the HTTP context (if you want
to retain that binding).
[GS] The new appendix D walks through the unprotected CoAP headers and the
role of the HTTP headers. Please check if you are happy with this.
Post by Eric Rescorla
are given in Appendix A. OSCORE does not depend on underlying
layers, and can be used anywhere where CoAP or HTTP can be used,
including non-IP transports (e.g., [I-D.bormann-6lo-coap-802-15-ie]).
IMPORTANT: This document claims to be applicable to protocols other
than COAP, in particular HTTP. Has this been reviewed by the HTTP
working group? Martin Thomson's review suggests that this is out of
step with HTTP practice.
[GS] No, prior to Martin’s review we did not have an HTTP expert review so
we are grateful for his review.
Post by Eric Rescorla
IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible.
IMPORTANT: I don't understand how this paragraph and the previous
paragraph interact. You say that the maximum length is 7 octets in the
previous paragraph, which I don't think qualifies as "long".
[GS] The WG did not confirm interest in random IDs so we dropped that and
rewrote this text accordingly.
Post by Eric Rescorla
| 1 | If-Match | x | |
| 3 | Uri-Host | | x |
| 4 | ETag | x | |
IMPORTANT: Why do you think that it's not important to have integrity
protection for Uri-Host and Uri-port?
[GS] The Uri-Host and Uri-Port may be changed by a CoAP proxy so cannot be
integrity protected end-to-end. This is discussed in the new D.4.
Post by Eric Rescorla
Outer option message fields (Class U or I) are used to support proxy
operations.
IMPORTANT: This seems problematic because the proxy cannot verify class I
fields.
[GS] “support proxy operations” means allowing a proxy perform its
intended operation. We have tried to clarify this in appendix D.1.
Post by Eric Rescorla
layer only, and not the Messaging Layer (Section 2 of [RFC7252]), so
fields such as Type and Message ID are not protected with OSCORE.
IMPORTANT: This seems extremely hard to reason about. What are the
implications of the proxy being able to change these?
[GS] These are UDP binding parameters which a proxy is entitled to change
so cannot be integrity protected end-to-end. Discussed in the new appendix
D.4
Post by Eric Rescorla
o request_piv: contains the value of the 'Partial IV' in the COSE
object of the request (see Section 5).
IMPORTANT: I think what I am getting here is that the request_piv is
used to verify that the request and response match. However, I do not
see this explicitly stated anywhere, and it's not clear to me how the
client is supposed to recover the request_piv and the text is pretty
unclear here? Is the external_aad carried somewhere in the message? Am
I supposed to reconstruct it from the message id?
[GS] The request_piv is intended to be cached by the client, that wasn’t
sufficiently clear. See new text in step 6 of section 8.1
Post by Eric Rescorla
For responses, the message binding guarantees that a response is not
older than its request. For responses without Observe, this gives
IMPORTANT: I am not sure that this is true. What happens of the
counterparty lies? What is your threat model?
[GS] The client and server are assumed to be honest. This mechanism is
intended to address attacks from other parties. We have tried to clarify
this in D.1.
Post by Eric Rescorla
An extension of OSCORE may also be used to protect group
communication for CoAP [I-D.tiloca-core-multicast-oscoap]. The use
of OSCORE does not affect the URI scheme and OSCORE can therefore be
used with any URI scheme defined for CoAP or HTTP. The application
decides the conditions for which OSCORE is required.
This is pretty surprising to just drop in here. Multicast has totally different
security properties from non-multicast.
[GS] This text is taken out.
Post by Eric Rescorla
----------------------------------------------------------------------
----------------------------------------------------------------------
but is also able to eavesdrop on, or manipulate any part of the
message payload and metadata, in transit between the endpoints. The
proxy can also inject, delete, or reorder packets since they are no
Nit: you want
"eavesdrop on, or manipulate any part of, the message payload and metadata in
transit"
I.e., move the second comma
[GS] Done.
Post by Eric Rescorla
the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport
Nit: "OSCORE protects neither .... nor...."
[GS] Done.
Post by Eric Rescorla
Salt. Length is determined by the AEAD Algorithm. Its value is
immutable once the security context is established.
Nit: you might just say above or below this list that all the values are
immutable,
[GS] Done.
Post by Eric Rescorla
different operations. One mechanism enabling this is specified in
[I-D.ietf-core-echo-request-tag].
Is this a security condition?
[GS] This information is redundant and removed, since that draft updates
RFC7959, which is referenced in the previous paragraph.
Post by Eric Rescorla
of [RFC7252], where the delta is the difference to the previously
included class I option.
Is the delta here the previously included Class I option or the previously
included instance of the same option, as it appears to say in S 3.1.
[GS] Instance, fixed.
Post by Eric Rescorla
compressed COSE object. The values n = 6 and n = 7 are
reserved.
How can Partial IV not be present? it's the sequence number. Is the answer that
it is the 0 value?
[GS] Partial-IV is typically not included to reduce message
overhead, see new text at the end of section 5.2.
Post by Eric Rescorla
response. The server therefore needs to store the kid and Partial IV
of the request until all responses have been sent.
It was my understanding that the kid was needed to look up the key. Why are kid
substitution attacks an issue?
[GS] The kid has multiple uses. It is used to look up the key, but in this
case
this is about the binding of response to request as the previous sentence
explains.
Post by Eric Rescorla
The maximum Sender Sequence Number is algorithm dependent (see
Section 11), and no greater than 2^40 - 1. If the Sender Sequence
Number exceeds the maximum, the endpoint MUST NOT process any more
If you take my suggestion about removing senderID from the nonce you will be
able to relax this.
[GS] Yes, that would have been an alternative, but there seems to be no
need
for more messages.
Post by Eric Rescorla
After boot, an endpoint MAY reject to use existing security contexts
from before it booted and MAY establish a new security context with
Nit: this is ungrammatical
[GS] Done.
Post by Eric Rescorla
included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message.
IMPORTANT: You are now violating the invariant of using the same nonce twice.
That's fine in this case, because you have per-sender keys but it demonstrates
that it is unnecessary to encode the sender_id in the nonce field.
[GS] The use of sender_id in the nonce is to handle notifications and
client-server role change with the same construction as is analysed in
the new
appendix D.3
Post by Eric Rescorla
Security level here means that an attacker can recover one of the m
keys with complexity 2^(k + n) / m. Protection against such attacks
can be provided by increasing the size of the keys or the entropy of
This paragraph is extremely hard to follow but I am not persuaded that it is
correct. Do you have a citation for the claim that you can add the key entropy
and the nonce entropy like this.
[GS] The reference is: McGrew, D. and S. Fluhrer, "Attacks on Encryption of
Redundant Plaintext and Implications on Internet Security", 2010. But on
second thought, we removed this data point since that is just one attack
and it can give the impression that the is a guaranteed security level.
Post by Eric Rescorla
style of padding means that all values need to be padded. Similar
arguments apply to other message fields such as resource names.
The PKCS#7 padding scheme at minimum has potential timing channels
[GS] Agreed, we replaced this text with a more general text.
Post by Eric Rescorla
The server verifies that the Partial IV has not been received before.
The client verifies that the response is bound to the request.
How does the client verify this
[GS] If ciphertext decrypts, the request PIV has been used in the
external_aad by the server. Again, binding here means protecting against
other parties besides client and server.
Post by Eric Rescorla
Partial IV (in network byte order) with zeroes to exactly nonce
length - 6 bytes,
IMPORTANT: I don't understand the reason for this construction. You
already require that the key be derived via HKDF from the |master key|
and |sender ID| therefore, it is not necessarily to separately encode
the sender ID in the nonce. This would ordinarily not be a large
issue, but as it requires very extreme restrictions on the sender ID
(and essentially precludes random sender IDs) I believe it is worth
considering changing, but it's ultimately a WG decision, hence not
in my discuss.
[GS] The construction is to address the additional case of client and
server changing roles as well as omitting nonce in simple responses, as is
analysed in appendix D.3.


Thanks for a good review.

Göran
Loading...