Re: [core] Eric Rescorla's Discuss on draft-ietf-core-object-security-09: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Mar 8, 2018 at 6:59 AM, Göran Selander <[e-mail]>
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.



> 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



> . 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
>
>
>
>
> On 2018-03-08 03:58, "Eric Rescorla" <[e-mail]> wrote:
>
> >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.
> >
> >
>
>