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

[Benjamin Kaduk <[e-mail]>]

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