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

>
>
> From: Eric Rescorla <[e-mail]>
> Date: Thursday 8 March 2018 at 16:39
> 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 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.
>
>
> Yes, but not against proxy operations which are defined as legitimate by
> CoAP and/or where there are other means to verify the operation.
>

Whether these operations are in fact safe is the question at hand. I will
wait for your detailed analysis.

-Ekr


>
> 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.
>
>
> That is an alternative solution which is less optimised e.g. in terms of
> size of group communication security context. Let us come back on that.
>
> Göran
>
>
> -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-i
>>> e]).
>>> >
>>> >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.
>>> >
>>> >
>>>
>>>
>>
>