[core] WGLC core-object-security-07

[peter van der Stok]

Hi all,

I have read this document and found it well structured and
comprehensible.
I do have some suggestions and questions. Apologies if the the subjects
below have already been discussed on the ML.
My interest in this document is quite recent.

Abstract:
The abstract is intended for naive readers like me; and some text can be
improved.
To my understanding this document specifies "the transport of secured
data with CoAP or HTTP".
There is no phrase in the abstract which covers this.
It might be helpful to state that the distribution and generation of
keys is out of scope.
IMO end-to-end encryption is a bit terse for naive people. A phrase
about proxies would be nice.
The last phrase "OSCORE may ... draft." can be removed. It is an aspect
treated later in the text, and now creates the impression to be the main
reason for this document.

1 Introduction;
The abstractions coap message layer and coap request/response layer are
used. The discussions about coap over tcp taught me that these
abstractions are very differently interpreted by different people. A
more concrete statement about coap payload and coap headers will be more
informative.
What is an "in-layer security protocol"? This statement generates more
questions than its absence will.

State that the "Oject-security option" is new and defined in this
document.

The text "OSCORE provides protection of message payload... Figure1" is
really difficult to understand. Problems for me are: Not knowing what a
message is, difference between OSCORE payload and coap payload, and
others. With little extra effort this can be described more concretely.
I suggest to just describe figure 1 which is clearer than the text.

3 Security Context.
The text restricts itself to AEAD algorithms. COSE allows many more. I
can imagine that in some installations, only one context per server is
needed. In that case, the Additional Data can be empty. Is it possible
to extend the choice of algorithms to all COSE (and future ones) and
point out that transmitting the context identifier necessitates an AEAD
algorithm?
The text suggests that the derivation of the keys is done independently
in client and server. Is it not possible to distribute derived keys with
other mechanisms? (oauth-authz is mentioned later).
In 3.2 the text says that input parameters may be pre-established.
Additional text pointing out the current possibilities and their
consequences would be welcome to me.

4 protected message fields.
Again, what is a (coap, Oscore) message?
Most of the text is about Inner and Outer message fields. IMO Figure 5
should be expressed in those two aspects.
Integrity protected coap options does not exist to-day, but its eventual
presence is treated as main focus. This is a bit confusing especially as
letter "I" could stand for Inner and Integrity.
I found the separation of inner and outer Max-age confusing: Is it not
better to add a new option: cache-age?
Also the outer block option is confusing. I understand the block option
to be an end-to-end option, and to be no concern of intermediate
routers, bridges or proxies. The block option should be used by client
and server with knowledge about transmitted packet (datagram) size. If
packet size data are wrong, other means of fragmentation are possible
and these are outside the coap end-to-end security scope.

8 OSCORE compression.
If I understand correctly, the compression removes CBOR tags which are
self-evident.
Could that motivation be added; Once I realized that aspect, the section
became much clearer.

Thanks for all your work; Hope this helps.
Nice document,

Peter

[Göran Selander]

Hi Peter,

Many thanks for your review. Comments inline

On 2017-12-06 11:10, "core on behalf of peter van der Stok"

Post by peter van der Stok
Hi all,
I have read this document and found it well structured and
comprehensible.
I do have some suggestions and questions. Apologies if the the subjects
below have already been discussed on the ML.
My interest in this document is quite recent.
The abstract is intended for naive readers like me; and some text can be
improved.
To my understanding this document specifies "the transport of secured
data with CoAP or HTTP".
There is no phrase in the abstract which covers this.

[GS] Correct, the current abstract does neither explain how CoAP or HTTP
message fields are protected nor transported, this is described on high
level in Section 1. It may be difficult to phrase this briefly in the
abstract, since part of the CoAP message remains unchanged through the
OSCORE transformation so it is not a clean cut "transport with CoAP”.

I propose we leave it to section 1, but make sure that it is sufficiently
well described there (which I take from your later comments is not yet the
case).

Post by peter van der Stok
It might be helpful to state that the distribution and generation of
keys is out of scope.

[GS] It was not entirely clear to me what "distribution and generation of
keys” refers to. There is always a need to introduce some initial keys -
that is unavoidable and seems redundant to remark. Note that pre-shared
keys can be used directly with the key derivation specified in the
document, so in that case there is no need for additional "distribution
and generation of keys”.

Then there may be TTP-assisted key distribution (like ACE), or the use of
a key exchange protocol to get an OSCORE master key in place. If that is
what you refer to, then I can agree we could give make clear that it is
out of scope earlier in the document but perhaps better in the section 1
rather than in the abstract?

Post by peter van der Stok
IMO end-to-end encryption is a bit terse for naive people.

[GS] While the term "end-to-end" is commonly used, I agree that we could
clarify what the endpoints can be.

Post by peter van der Stok
A phrase
about proxies would be nice.

[GS] OK, we add text about OSCORE allows proxy processing on certain
message data.

Post by peter van der Stok
The last phrase "OSCORE may ... draft." can be removed.
It is an aspect
treated later in the text, and now creates the impression to be the main
reason for this document.

[GS] Agreed. That comment was received also from another reviewer.

Post by peter van der Stok
1 Introduction;
The abstractions coap message layer and coap request/response layer are
used. The discussions about coap over tcp taught me that these
abstractions are very differently interpreted by different people. A
more concrete statement about coap payload and coap headers will be more
informative.

[GS] These abstractions are used in the Introduction to avoid going into
which CoAP headers are protected, which is done later in the document.
Perhaps a forward reference to relevant sections would be sufficient?
Also, the description of how CoAP works above Figure 1 gives a high level
explanation of how CoAP payload, options and header fields are handled
(again, this part can be made more clear).

Post by peter van der Stok
What is an "in-layer security protocol"? This statement generates more
questions than its absence will.

[GS] I agree that the term may be confusing and we should probably remove
it. Here is anyway the rationale for the term:

OSCORE is an extension to CoAP which protects the CoAP message and
replaces the original CoAP message with a modified CoAP message (the
OSCORE message). In this sense, it does not depend on any other layer in
the stack, which in turn enables the independence of underlying layers and
support for CoAP proxy operations etc.. We need to make this part clear,
but we don’t need to use the term “in-layer”.

Post by peter van der Stok
State that the "Oject-security option" is new and defined in this
document.

[GS] It is stated that:

"The use of OSCORE is signaled with the Object-Security CoAP option or
HTTP header, defined in Section 2 and Section 10.2.”

Is it the word “new” you are missing?

Post by peter van der Stok
The text "OSCORE provides protection of message payload... Figure1" is
really difficult to understand.

[GS] This is the part I’ve been referring to previously in this mail, and
I can agree upon re-reading that it has not transformed well in the latest
iterations of the text.

Post by peter van der Stok
Problems for me are: Not knowing what a
message is, difference between OSCORE payload and coap payload, and
others.

[GS] Aah, now I see what went wrong. There used to be a ‘CoAP’ before the
word ‘message', like this:

"The solution transforms a CoAP message into an "OSCORE message" before
sending, and vice versa after
receiving.”


But when we extended the scope the HTTP, we removed the explicit
mentioning of ‘CoAP’ in “CoAP message”, with the assumption that "message"
could be either "CoAP message" or "HTTP message”.

Likewise there used to be a sentence explaining that the OSCORE message is
indeed a CoAP message, but that seems also have been lost in the ambition
of explaining how it works with CoAP and HTTP at the same time. I need to
think about what is best, either reverting and discuss the HTTP part
separate or adding "CoAP/HTTP” before message.

Post by peter van der Stok
With little extra effort this can be described more concretely.
I suggest to just describe figure 1 which is clearer than the text.

[GS] Yes, let’s add that too.

Post by peter van der Stok
3 Security Context.
The text restricts itself to AEAD algorithms. COSE allows many more.

[GS] Yes, in OSCORE only COSE_Encrypt0 with AEAD is defined. There is a
placeholder for an additional countersignature, which is defined in the
Group OSCORE draft.

There has been a discussion about reading and verify integrity in proxies,
and that can be achieved e.g. by having a Class I or Class U option with a
COSE_Mac0 object verified in the proxy. This would be an application of
OSCORE, and if necessary, can described in a separate draft.

Are there any other kind of COSE objects you want to use (what are the use
cases)?

Post by peter van der Stok
I
can imagine that in some installations, only one context per server is
needed. In that case, the Additional Data can be empty.

[GS] I didn’t understand this part of the comment.

Post by peter van der Stok
Is it possible
to extend the choice of algorithms to all COSE (and future ones) and
point out that transmitting the context identifier necessitates an AEAD
algorithm?

[GS] Same question as above, what are the use cases for the COSE objects
not already mentioned? Since different COSE objects assume different
security contexts and different processing steps we didn’t try to cover
them all in one specification. Should additional COSE objects be needed we
could make an extension (e.g. using the OSCORE flag byte as an extension
point.)

Post by peter van der Stok
The text suggests that the derivation of the keys is done independently
in client and server. Is it not possible to distribute derived keys with
other mechanisms? (oauth-authz is mentioned later).

[GS] The derivations in client and server are identical. It is possible to
distribute the derived keys, but we didn’t see any benefits compared to
just distributing the few input parameters needed for key derivation. What
use case did you have in mind?

Post by peter van der Stok
In 3.2 the text says that input parameters may be pre-established.
Additional text pointing out the current possibilities and their
consequences would be welcome to me.

[GS] OK, good point. I note that the ACE framework is referenced instead
of the OSCORE profile of ACE and we should change that too.

Post by peter van der Stok
4 protected message fields.
Again, what is a (coap, Oscore) message?

[GS] Since this part has been lost from the introduction I can understand
the confusion. The original CoAP message is transformed by the sender into
a OSCORE message (which is a CoAP message containing the protected message
fields), and the OSCORE message is transformed back by the recipient.

Post by peter van der Stok
Most of the text is about Inner and Outer message fields. IMO Figure 5
should be expressed in those two aspects.

[GS] We have had some discussions about how to best illustrate the
different processing cases for the options. Since there are three classes
(E, I , U) and the term Outer maps to both I and U, some information gets
lost by only speaking about Inner and Outer. Then again, since there are
not any class I options defined yet, I understand your point of view.

Post by peter van der Stok
Integrity protected coap options does not exist to-day, but its eventual
presence is treated as main focus.

[GS] I would not say Class I options are main focus, but they require
special processing and anticipating their usefulness (see example above)
we wanted to include their processing in the specification.

Post by peter van der Stok
This is a bit confusing especially as
letter "I" could stand for Inner and Integrity.

[GS] Yes, these words do start with the same letter, but there is no
"Class O” so I believe it should be possible to make the distinction.

Post by peter van der Stok
I found the separation of inner and outer Max-age confusing: Is it not
better to add a new option: cache-age?

[GS] Sorry, I didn’t understand what is confusing and why a new option
would be better.

As all options which has both inner and outer instances, this enables the
feature to communicate differently with endpoint and with an intermediate
proxy. In particular for legacy proxies, we need to use the legacy options
as outer option instances to communicate with the proxy. And at the same
time we can use the inner option to communicate with the endpoint. For the
endpoint we use Max-Age in the usual way, for a proxy we use Max-age to
avoid unnecessary caching.

Post by peter van der Stok
Also the outer block option is confusing. I understand the block option
to be an end-to-end option, and to be no concern of intermediate
routers, bridges or proxies. The block option should be used by client
and server with knowledge about transmitted packet (datagram) size. If
packet size data are wrong, other means of fragmentation are possible
and these are outside the coap end-to-end security scope.

[GS] Your understanding is entirely correct. However, we need to describe
outer block processing to the extent it has an impact on the OSCORE
processing. Since proxies may perform block processing on OSCORE messages,
a recipient may receive a fragment (block) of an OSCORE message, and thus
first need to wait for the remaining blocks before processing the OSCORE
message.

This is in contrast to other CoAP processing which comes after OSCORE has
verified and decrypted the message. Outer block is thus an exception,
which is visible in the processing steps, see e.g. section 7.2, but we
should highlight that better in the description about the outer block
option.

Post by peter van der Stok
8 OSCORE compression.
If I understand correctly, the compression removes CBOR tags which are
self-evident.
Could that motivation be added; Once I realized that aspect, the section
became much clearer.

[GS] Good point. Yes, compression can mean different things, in this case
it is basically eliding fixed data. We include your proposal.

Post by peter van der Stok
Thanks for all your work; Hope this helps.
Nice document,

Thanks, very helpful!

Göran

[peter van der Stok]

Hi Goran,

thanks for you reaction; some late clarifications of my comments below.

Post by Göran Selander
abstract, since part of the CoAP message remains unchanged through the
OSCORE transformation so it is not a clean cut "transport with CoAP”.

May be: "Application layer security addition to http and coap transport"

Post by Göran Selander

Post by peter van der Stok
It might be helpful to state that the distribution and generation of
keys is out of scope.

[GS] It was not entirely clear to me what "distribution and generation of
keys” refers to. There is always a need to introduce some initial keys -
that is unavoidable and seems redundant to remark.

The remark is not about the necessity of the initial keys but on the
fact tat the draft does not specify it.
I like it when drafts clearly specify their scope. (especially in the
abstract)

Post by Göran Selander
Then there may be TTP-assisted key distribution (like ACE), or the use of
a key exchange protocol to get an OSCORE master key in place. If that is
what you refer to,

Indeed
then I can agree we could give make clear that it is

Post by Göran Selander
out of scope earlier in the document but perhaps better in the section 1
rather than in the abstract?

both?

Post by Göran Selander

Post by peter van der Stok
1 Introduction;
The abstractions coap message layer and coap request/response layer are
used. The discussions about coap over tcp taught me that these
abstractions are very differently interpreted by different people. A
more concrete statement about coap payload and coap headers will be more
informative.

[GS] These abstractions are used in the Introduction to avoid going into
which CoAP headers are protected, which is done later in the document.
Perhaps a forward reference to relevant sections would be sufficient?
Also, the description of how CoAP works above Figure 1 gives a high level
explanation of how CoAP payload, options and header fields are handled
(again, this part can be made more clear).

Abstractions are always difficult. Once found they are obvious.
My impression was that with few words you could define your own
abstractions that will inherit less confusion than the coap layers do.

Post by Göran Selander

Post by peter van der Stok
What is an "in-layer security protocol"? This statement generates more
questions than its absence will.

[GS] I agree that the term may be confusing and we should probably remove
OSCORE is an extension to CoAP which protects the CoAP message and
replaces the original CoAP message with a modified CoAP message (the
OSCORE message). In this sense, it does not depend on any other layer in
the stack, which in turn enables the independence of underlying layers and
support for CoAP proxy operations etc.. We need to make this part clear,
but we don’t need to use the term “in-layer”.

I agree that I would never have guessed the semantics of in-layer as
described above.

Post by Göran Selander

Post by peter van der Stok
State that the "Oject-security option" is new and defined in this
document.

"The use of OSCORE is signaled with the Object-Security CoAP option or
HTTP header, defined in Section 2 and Section 10.2.”
Is it the word “new” you are missing?

Yes, that's all.

Post by Göran Selander
But when we extended the scope the HTTP, we removed the explicit
mentioning of ‘CoAP’ in “CoAP message”, with the assumption that "message"
could be either "CoAP message" or "HTTP message”.
Likewise there used to be a sentence explaining that the OSCORE message is
indeed a CoAP message, but that seems also have been lost in the ambition
of explaining how it works with CoAP and HTTP at the same time. I need to
think about what is best, either reverting and discuss the HTTP part
separate or adding "CoAP/HTTP” before message.

Defining them will be enough and does not cost much in words.

Post by Göran Selander

Post by peter van der Stok
With little extra effort this can be described more concretely.
I suggest to just describe figure 1 which is clearer than the text.

[GS] Yes, let’s add that too.

Adding? replacing is more concise?

Post by Göran Selander

Post by peter van der Stok
3 Security Context.
The text restricts itself to AEAD algorithms. COSE allows many more.
I
can imagine that in some installations, only one context per server is
needed. In that case, the Additional Data can be empty.

[GS] I didn’t understand this part of the comment.

IMU the AEAD restriction was needed because there is additional data to
be protected against tampering.
That concerns the not yet existing options and the kid, etc data.
When these data are not needed (no confusion to select because only one
connection exists) the AEAD restriction was not needed; and therefore
the AEAD restriction is not a MUST but a recommendation for most use
cases.

Post by Göran Selander

Post by peter van der Stok
Is it possible
to extend the choice of algorithms to all COSE (and future ones) and
point out that transmitting the context identifier necessitates an AEAD
algorithm?

[GS] Same question as above, what are the use cases for the COSE objects
not already mentioned? Since different COSE objects assume different
security contexts and different processing steps we didn’t try to cover
them all in one specification. Should additional COSE objects be needed we
could make an extension (e.g. using the OSCORE flag byte as an
extension
point.)

Possibly, I'm making a point about nothing, and can new algorithms
always be added to OSCORE.
The current text creates the impression that this is not possible.

Post by Göran Selander

Post by peter van der Stok
4 protected message fields.
Integrity protected coap options does not exist to-day, but its eventual
presence is treated as main focus.

[GS] I would not say Class I options are main focus, but they require
special processing and anticipating their usefulness (see example above)
we wanted to include their processing in the specification.

The text surface about Class I is really large compared to its use.

Post by Göran Selander

Post by peter van der Stok
I found the separation of inner and outer Max-age confusing: Is it not
better to add a new option: cache-age?

[GS] Sorry, I didn’t understand what is confusing and why a new option
would be better.
we can use the inner option to communicate with the endpoint. For the
endpoint we use Max-Age in the usual way, for a proxy we use Max-age to
avoid unnecessary caching.

Exactly my point; the semantics are different, but they have the same
name, and Max_age is defined for inner in 7252.

Post by Göran Selander

Post by peter van der Stok
Also the outer block option is confusing. I understand the block option
to be an end-to-end option, and to be no concern of intermediate
routers, bridges or proxies. The block option should be used by client
and server with knowledge about transmitted packet (datagram) size. If
packet size data are wrong, other means of fragmentation are possible
and these are outside the coap end-to-end security scope.

[GS] Your understanding is entirely correct. However, we need to describe
outer block processing to the extent it has an impact on the OSCORE
processing. Since proxies may perform block processing on OSCORE messages,
a recipient may receive a fragment (block) of an OSCORE message, and thus
first need to wait for the remaining blocks before processing the OSCORE
message.
This is in contrast to other CoAP processing which comes after OSCORE has
verified and decrypted the message. Outer block is thus an exception,
which is visible in the processing steps, see e.g. section 7.2, but we
should highlight that better in the description about the outer block
option.

Right, and where and how are these new block options generated? in
routers? or does this necessitate an extension to coap proxy
specifications?

Greetings,
thanks for your explanations,

Peter

[Göran Selander]

Hi Peter,

Post by peter van der Stok
Hi Goran,
thanks for you reaction; some late clarifications of my comments below.

Post by Göran Selander
abstract, since part of the CoAP message remains unchanged through the
OSCORE transformation so it is not a clean cut "transport with CoAP”.

May be: "Application layer security addition to http and coap transport"

[GS] To try to set the right expectations we now use the term
"CoAP-mappable HTTP”. We did not use the term “coap transport” since this
is somehow giving the impression that CoAP would only be used for
transport, whereas OSCORE defines a CoAP option and the CoAP message being
sent should be viewed as a modification of the original CoAP message.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
It might be helpful to state that the distribution and generation of
keys is out of scope.

[GS] It was not entirely clear to me what "distribution and generation of
keys” refers to. There is always a need to introduce some initial keys -
that is unavoidable and seems redundant to remark.

The remark is not about the necessity of the initial keys but on the
fact tat the draft does not specify it.
I like it when drafts clearly specify their scope. (especially in the
abstract)

Post by Göran Selander
Then there may be TTP-assisted key distribution (like ACE), or the use of
a key exchange protocol to get an OSCORE master key in place. If that is
what you refer to,

Indeed
then I can agree we could give make clear that it is

Post by Göran Selander
out of scope earlier in the document but perhaps better in the section 1
rather than in the abstract?

both?

[GS] We opted for short abstract. Since OSCORE does not require but may be
used with a key establishment protocol, the explanation of that seemed
better suited to only have in the Introduction.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
1 Introduction;
The abstractions coap message layer and coap request/response layer are
used. The discussions about coap over tcp taught me that these
abstractions are very differently interpreted by different people. A
more concrete statement about coap payload and coap headers will be more
informative.

[GS] These abstractions are used in the Introduction to avoid going into
which CoAP headers are protected, which is done later in the document.
Perhaps a forward reference to relevant sections would be sufficient?
Also, the description of how CoAP works above Figure 1 gives a high level
explanation of how CoAP payload, options and header fields are handled
(again, this part can be made more clear).

Abstractions are always difficult. Once found they are obvious.
My impression was that with few words you could define your own
abstractions that will inherit less confusion than the coap layers do.

[GS] We removed the details about payload, option and header from the
introduction and included a new figure 1, hopefully that provides for
better intuition.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
What is an "in-layer security protocol"? This statement generates more
questions than its absence will.

[GS] I agree that the term may be confusing and we should probably remove
OSCORE is an extension to CoAP which protects the CoAP message and
replaces the original CoAP message with a modified CoAP message (the
OSCORE message). In this sense, it does not depend on any other layer in
the stack, which in turn enables the independence of underlying layers and
support for CoAP proxy operations etc.. We need to make this part clear,
but we don’t need to use the term “in-layer”.

I agree that I would never have guessed the semantics of in-layer as
described above.

[GS] Term gone in the new revision.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
State that the "Oject-security option" is new and defined in this
document.

"The use of OSCORE is signaled with the Object-Security CoAP option or
HTTP header, defined in Section 2 and Section 10.2.”
Is it the word “new” you are missing?

Yes, that's all.

[GS] Done

Post by peter van der Stok

Post by Göran Selander
But when we extended the scope the HTTP, we removed the explicit
mentioning of ‘CoAP’ in “CoAP message”, with the assumption that "message"
could be either "CoAP message" or "HTTP message”.
Likewise there used to be a sentence explaining that the OSCORE message is
indeed a CoAP message, but that seems also have been lost in the ambition
of explaining how it works with CoAP and HTTP at the same time. I need to
think about what is best, either reverting and discuss the HTTP part
separate or adding "CoAP/HTTP” before message.

Defining them will be enough and does not cost much in words.

[GS] Part of the update of the Introduction.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
With little extra effort this can be described more concretely.
I suggest to just describe figure 1 which is clearer than the text.

[GS] Yes, let’s add that too.

Adding? replacing is more concise?

[GS] Part of the Introduction is now rewritten. However, we kept a
high-level explanation of the process when a CoAP / HTTP message is
transformed into an OSCORE message.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
3 Security Context.
The text restricts itself to AEAD algorithms. COSE allows many more.
I
can imagine that in some installations, only one context per server is
needed. In that case, the Additional Data can be empty.

[GS] I didn’t understand this part of the comment.

IMU the AEAD restriction was needed because there is additional data to
be protected against tampering.
That concerns the not yet existing options and the kid, etc data.
When these data are not needed (no confusion to select because only one
connection exists) the AEAD restriction was not needed; and therefore
the AEAD restriction is not a MUST but a recommendation for most use
cases.

[GS] This specification only describes the use of AEAD for protection of
messages. The Additional Authenticated Data (AAD) is actually used in each
message. The use of other COSE message types is not defined in this
specification, but other specifications define public key usage with
OSCORE, including the use of signatures and public key based key
encryption.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
Is it possible
to extend the choice of algorithms to all COSE (and future ones) and
point out that transmitting the context identifier necessitates an AEAD
algorithm?

[GS] Same question as above, what are the use cases for the COSE objects
not already mentioned? Since different COSE objects assume different
security contexts and different processing steps we didn’t try to cover
them all in one specification. Should additional COSE objects be needed we
could make an extension (e.g. using the OSCORE flag byte as an extension
point.)

Possibly, I'm making a point about nothing, and can new algorithms
always be added to OSCORE.
The current text creates the impression that this is not possible.

[GS] OSCORE uses COSE_Encrypt0 and has a default algorithm, but other
algorithms are specified in COSE and additional algorithms are possible to
define.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
4 protected message fields.
Integrity protected coap options does not exist to-day, but its eventual
presence is treated as main focus.

[GS] I would not say Class I options are main focus, but they require
special processing and anticipating their usefulness (see example above)
we wanted to include their processing in the specification.

The text surface about Class I is really large compared to its use.

[GS] Agreed, it is currently not used at all. But some text is needed to
make the description of its use clear, since there will most likely be
future options which are only integrity protected (addressing use cases
with partially trusted intermediaries who, e.g. are allowed to read but
not write application data).

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
I found the separation of inner and outer Max-age confusing: Is it not
better to add a new option: cache-age?

[GS] Sorry, I didn’t understand what is confusing and why a new option
would be better.
we can use the inner option to communicate with the endpoint. For the
endpoint we use Max-Age in the usual way, for a proxy we use Max-age to
avoid unnecessary caching.

Exactly my point; the semantics are different, but they have the same
name, and Max_age is defined for inner in 7252.

[GS] Both endpoint and proxy processing are defined in RFC 7252, and it is
these definitions that has lead to the specification of the Inner/Outer
Max-Age options, so using the same term in both cases seems relevant.

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
Also the outer block option is confusing. I understand the block option
to be an end-to-end option, and to be no concern of intermediate
routers, bridges or proxies. The block option should be used by client
and server with knowledge about transmitted packet (datagram) size. If
packet size data are wrong, other means of fragmentation are possible
and these are outside the coap end-to-end security scope.

[GS] Your understanding is entirely correct. However, we need to describe
outer block processing to the extent it has an impact on the OSCORE
processing. Since proxies may perform block processing on OSCORE messages,
a recipient may receive a fragment (block) of an OSCORE message, and thus
first need to wait for the remaining blocks before processing the OSCORE
message.
This is in contrast to other CoAP processing which comes after OSCORE has
verified and decrypted the message. Outer block is thus an exception,
which is visible in the processing steps, see e.g. section 7.2, but we
should highlight that better in the description about the outer block
option.

Right, and where and how are these new block options generated? in
routers? or does this necessitate an extension to coap proxy
specifications?

[GS] The outer block options are generated in proxies and endpoints just
as ordinary block options. The processing of outer Blockwise coincide with
how Blockwise is defined (RFC7959), so maybe that does not require further
specification? However, an endpoint supporting OSCORE receiving a
fragmented OSCORE message needs to first put together the OSCORE message
before processing it, and also the implication of proxies fragmentation on
the integrity protection of messages - this is the new processing we are
considering in the document.

Hope that makes sense.

Thanks for good comments!

Göran

[peter van der Stok]

Hi Goran,

thanks for your reactions. Things are more understandable for me.

Post by Göran Selander

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
I found the separation of inner and outer Max-age confusing: Is it not
better to add a new option: cache-age?

[GS] Sorry, I didn’t understand what is confusing and why a new option
would be better.
we can use the inner option to communicate with the endpoint. For the
endpoint we use Max-Age in the usual way, for a proxy we use Max-age to
avoid unnecessary caching.

Exactly my point; the semantics are different, but they have the same
name, and Max_age is defined for inner in 7252.

[GS] Both endpoint and proxy processing are defined in RFC 7252, and it is
these definitions that has lead to the specification of the Inner/Outer
Max-Age options, so using the same term in both cases seems relevant.

That's right. Esko also pointed this out to me. My problem is with RFC
7252, so my remark was irrelevant

Post by Göran Selander

Post by peter van der Stok

Post by Göran Selander

Post by peter van der Stok
Also the outer block option is confusing. I understand the block option
to be an end-to-end option, and to be no concern of intermediate
routers, bridges or proxies. The block option should be used by client
and server with knowledge about transmitted packet (datagram) size. If
packet size data are wrong, other means of fragmentation are possible
and these are outside the coap end-to-end security scope.

[GS] Your understanding is entirely correct. However, we need to describe
outer block processing to the extent it has an impact on the OSCORE
processing. Since proxies may perform block processing on OSCORE messages,
a recipient may receive a fragment (block) of an OSCORE message, and thus
first need to wait for the remaining blocks before processing the OSCORE
message.
This is in contrast to other CoAP processing which comes after OSCORE has
verified and decrypted the message. Outer block is thus an exception,
which is visible in the processing steps, see e.g. section 7.2, but we
should highlight that better in the description about the outer block
option.

Right, and where and how are these new block options generated? in
routers? or does this necessitate an extension to coap proxy
specifications?

[GS] The outer block options are generated in proxies and endpoints just
as ordinary block options. The processing of outer Blockwise coincide with
how Blockwise is defined (RFC7959), so maybe that does not require further
specification? However, an endpoint supporting OSCORE receiving a
fragmented OSCORE message needs to first put together the OSCORE message
before processing it, and also the implication of proxies fragmentation on
the integrity protection of messages - this is the new processing we are
considering in the document.
Hope that makes sense.

Looks convincing, but "block" has this habit of provoking unexpected
issues.

Post by Göran Selander
Thanks for good comments!

thanks for a very readable document.

Post by Göran Selander
Göran

_______________________________________________
core mailing list