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 7:23 AM, Göran Selander <[e-mail]>
wrote:

>
>
> From: Eric Rescorla <[e-mail]>
> Date: Thursday 8 March 2018 at 16:06
> To: Göran Selander <[e-mail]>
> Cc: The IESG <[e-mail]>, "[e-mail]" <
> [e-mail]>, Carsten Bormann <[e-mail]>,
> Jaime Jiménez <[e-mail]>, "[e-mail]" <
> [e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: Eric Rescorla's Discuss on draft-ietf-core-object-security-09:
> (with DISCUSS and COMMENT)
>
>
>
> 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.
>
>
> Yes, and we will try to address this. But it is a general property of CoAP
> when proxies are used.
>

Yes, but the whole point of this design is to protect to some extent
against malicious proxies.


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?
>
>
> The sender key is used both in the role of client making a request (with
> own partial IV) and in the role of server responding to a request (with the
> other endpoint’s partial IV).
>

This seems extremely hard to analyze. You should just use separate keys.

-Ekr


> Göran
>
>
> -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/stat
>> ement/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.
>> >
>> >
>>
>>
>