Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-websocket-04: (with DISCUSS and COMMENT)

From: Ken Murchison <[email-masked]>
Date: Sun, 8 Mar 2020 20:41:33 -0400

Hi Benjamin,

Is the scenario that you outline below related to just use of 
compression where an attacker is injecting content?

And are you suggesting that including IDs in each request can help 
detect and mitigate such an attack?

On 2/17/20 7:14 PM, Benjamin Kaduk wrote:
> Hi Ken,
>
> Sorry for the slow response time: I tried a few times to dig into things
> but each time had failed to allocate a large enough time slot to pull up
> the needed state.
>
> On Mon, Jan 20, 2020 at 03:02:11PM -0500, Ken Murchison wrote:
>> Hi Benjamin,
>>
>> Thank you very much for the detailed review.  I believe that I have
>> addressed all of your points in my forthcoming draft, except the one below.
> Thanks for the updates in the -05; they help quite a lot.  (I will have
> some more comments under separate cover, but respond here on the
> "out-of-order" topic.)
>
>> On 1/7/20 4:08 PM, Benjamin Kaduk via Datatracker wrote:
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> The discussion of compression bears some closer scrutiny, as if we allow
>>> the entire websocket frame to be part of the compression state,
>>> then there may be more avenues for an attacker to inject content into
>>> the same compression state as data that we want to keep somewhat
>>> confidential.  (This is not as bad as, say, the initial CRIME attack
>>> impact, as the authentication credentials are not being repeatedly sent,
>>> but the general principle of mixing attacker-controlled and confidential
>>> data into the same compression domain is the same.)
>>>
>>> We could say something in the security considerations about the
>>> potential consequences for a client that sends multiple requests in
>>> parallel without request IDs and gets back responses in a different
>>> order.  (Or just require unique request IDs, I suppose.)
>>
>> Can you expand on this?  I'm not sure I fully understand the exploit or
>> the way(s) to mitigate it.
> I must apologize for the handwaviness of the following, as I seem to have
> forgotten a fair amount of how JMAP works.
>
> At a very high level, the idea is that in JMAP, each request has an
> associated response, and the basic response object is just a JSON object
> with methodResponses, sessionState, and optional createdIds.  The concern
> would be if a naive client could make two requests with similar enough
> methodCalls that the corresponding methodResponses could be matched up to
> the "wrong" requests.  It's not exactly trivial to construct an example of
> how this would happen, though, given how the response object is roughly the
> request object with additional outputs appended.  That said, if the method
> in question was something weird and side-effect-ful like "return an element
> from an array of names, without replacement, obtained by using the next
> number from the fibonnacci sequence (modulo the size of the array) as index
> into the array", it seems likely that the client could get confused about
> which response came when the array of names was size N and which when it
> was size N-1.  (Yes, this is a ridiculously contrived example, but this is
> a general protocol that needs to handle whatever we throw at it.)  I guess
> it may be enough to just note that when a client is making "identical
> requests" in parallel it needs to use request IDs to associate the
> responses.
>
> Does that help?
>
> -Ben

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC