Subject: [core] WGLC core-object-security-07

From: peter van der Stok <[email-masked]>
Date: Wed, 06 Dec 2017 11:10:01 +0100

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

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Göran Selander <[email-masked]>
Date: Sat, 9 Dec 2017 16:10:38 +0000

Hi Peter,

Many thanks for your review. Comments inline

>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).

>It might be helpful to state that the distribution and generation of

[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?

>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.

>A phrase 

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

>reason for this document.

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

>more concrete statement about coap payload and coap headers will be more

[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).

>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”.

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

[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?

>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.

>Problems for me are: Not knowing what a
>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.

>With little extra effort this can be described more concretely.

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

>
>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)? 

>I 
>needed. In that case, the Additional Data can be empty.

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

> Is it possible 

[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.)

>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?

>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.

>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.

>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.

>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.

>This is a bit confusing especially as

[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.

>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.

>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.

>Could that motivation be added; Once I realized that aspect, the section

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

>Thanks for all your work; Hope this helps.

Thanks, very helpful!

Göran

---

From: peter van der Stok <[email-masked]>
Date: Thu, 14 Dec 2017 09:41:17 +0100

Hi Goran,

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

> OSCORE transformation so it is not a clean cut "transport with CoAP”.

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

> 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)

> what you refer to,
Indeed
then I can agree we could give make clear that it is
> rather than in the abstract?
both?

> (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.
> 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.
> Is it the word “new” you are missing?

Yes, that's all.

> separate or adding "CoAP/HTTP” before message.

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

> [GS] Yes, let’s add that too.
Adding? replacing is more concise?

> [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.

> could make an extension (e.g. using the OSCORE flag byte as an 

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.

> we wanted to include their processing in the specification.

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

> we can use the inner option to communicate with the endpoint. For the

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

> should highlight that better in the description about the outer block

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