Re: [core] Review of draft-hartke-core-e2e-security-reqs-01

[Klaus Hartke <[e-mail]>]

Hi Jim,

thanks a lot for your review. Comments inline below.

Klaus


Jim Schaad wrote:
> 1.  Note that the title of the COSE document has changed you should pick
> that up.

Fixed.

> 2. Section 2.1.1 - Should "client receives a response" include
>
>     * (Threat ?) The proxy returns a stale or outdated response based on
> data it previously obtained from the origin server or some fourth party.
>
>                I'm thinking of both out of date caches and poisoned caches.
> Note that these are valid from a security point of view, but not 'fresh'

This is a part of (Threat 1:) The proxy spoofs a response.

In the mitigation section (2.1.1.1.) we define that a response is
valid from a security point of view only if it is fresh.

(We use the term "authentic" instead of "valid" though, because
"valid" is already used in the context of cache validation.)

I've expanded the text with your suggestion:

      *  (Threat 1:) The proxy spoofs a response.  For example, the
         proxy could return a stale or outdated response based on data
         it previously obtained from the server or some fourth party, or
         could craft an illicit response itself.

> 3.  Section 2.1.1.3 - based on a brief look at mattsson-core-coap-actuators,
> it appears to have some solutions to the Withholding attack as well as the
> Delaying attack.  This should probably be noted.

I've opened an issue on GitHub for this:

https://github.com/ektrah/coap-object-security/issues/5

> 4.  Section 2.1.1.5 - It is not clear to me that there is a requirement that
> all messages be protected from eavesdropping.  It might just be the way
> things are stated here, but there is a difference between the fact that the
> solution must provide a method to deal with this and the fact that integrity
> protection might be sufficient in some cases.  This would also influence the
> analysis below in some cases.

Currently the text is written with the assumption that it is a
requirement that all messages are protected from eavesdropping.

However, as Carsten mentioned at the F2F meeting, there may indeed be
use cases where it's desirable that the proxy can eavesdrop on the
messages.

We will clarify this in the draft.

https://github.com/ektrah/coap-object-security/issues/6

> 5.  Section 2.1.1.5 - You need to have a better statement of what it means
> to provide forward secrecy.  This requirement would appear to potentially
> rule out the use of the same session content encryption key for multiple
> messages.  I do not believe that is true, but given that we are looking a
> message based security some people might think this is the case.  I would
> expand this statement to define the conditions under which PFS must be
> provided.

https://github.com/ektrah/coap-object-security/issues/7

> 6. Section 2.1.2 - Do you consider a proxy re-ordering requests to be a
> threat?

No. If a client wants to ensure that a request is processed after
another request, it needs to wait for the response to the first
request before it makes the second request.

> 7.  Section 2.1.2.1 - Next to last para.  I am not sure that 'involve' is
> the correct word in this sentence.  Perhaps you meant 'include'

Fixed.

> 8.  Section 3 - when I look at figure 10, I keep feeling that it is not a
> complete picture of what you need to be looking at
> [...]
>
> There needs to be a discussion of all of the different potential security
> associations in this diagram.  Some of these can be reduced to simple
> client-server associations, but some of the implications of this diagram are
> potentially used for the entirety of the picture.
> [...]

https://github.com/ektrah/coap-object-security/issues/8

> 9.  Threats in section 3 also include
>
>   * out of order delivery of items.
>
>   * Issues about a broker either granting or denying access to a stream.
>
>   * Subscriber does not receive a response because the broker pre-maturely
> unsubscribes the subscriber

https://github.com/ektrah/coap-object-security/issues/9