Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-websocket-04: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Tue, 18 February 2020 00:15 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4634C120866; Mon, 17 Feb 2020 16:15:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3b2V5VqEOfmw; Mon, 17 Feb 2020 16:15:04 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9D0712002E; Mon, 17 Feb 2020 16:15:03 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01I0EkFO014964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 17 Feb 2020 19:14:49 -0500
Date: Mon, 17 Feb 2020 16:14:46 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Ken Murchison <murch@fastmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-jmap-websocket@ietf.org, Jim Fenton <fenton@bluepopcorn.net>, jmap-chairs@ietf.org, jmap@ietf.org
Message-ID: <20200218001446.GB43614@kduck.mit.edu>
References: <157843131129.21019.4453575321747210277.idtracker@ietfa.amsl.com> <b568c4bc-41c5-674c-de3e-2d5f2f2bcbab@fastmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b568c4bc-41c5-674c-de3e-2d5f2f2bcbab@fastmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/VE8PA5e6uEvEt7rSvZHxdFi64XE>
Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-websocket-04: (with DISCUSS and COMMENT)
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2020 00:15:05 -0000
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
- [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jma… Benjamin Kaduk via Datatracker
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Ken Murchison
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Ken Murchison