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

From: Göran Selander <[email-masked]>
Date: Mon, 22 Jan 2018 21:43:36 +0000

Hi Peter,

Thanks for your further comments. Responses inline:

On 2017-12-14 09:41, "peter van der Stok" <[email-masked]> wrote:

>Hi Goran,
>
>thanks for you reaction; some late clarifications of my comments below.
>
>> 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.

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

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

>> 
>> 
>>> 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”.
>
>I agree that I would never have guessed the semantics of in-layer as
>described above.

[GS] Term gone in the new revision.

>> 
>>> 
>>> 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?
>
>Yes, that's all.

 [GS] Done

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

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

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

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

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

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

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

---

From: peter van der Stok <[email-masked]>
Date: Mon, 29 Jan 2018 09:56:49 +0100

Hi Goran,

thanks for your reactions. Things are more understandable for me.
> 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
> considering in the document.

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

> Thanks for good comments!

thanks for a very readable document.