Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-core-14: (with DISCUSS and COMMENT)
"Neil Jenkins" <neilj@fastmailteam.com> Wed, 13 March 2019 02:15 UTC
Return-Path: <neilj@fastmailteam.com>
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 9329C1311C1; Tue, 12 Mar 2019 19:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.982
X-Spam-Level:
X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=ffGuPn9x; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ix1JdX7R
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 UzMv0vDv1o90; Tue, 12 Mar 2019 19:14:58 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B28C13119D; Tue, 12 Mar 2019 19:14:58 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 13D9221D19; Tue, 12 Mar 2019 22:14:55 -0400 (EDT)
Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 12 Mar 2019 22:14:55 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:cc:subject:content-type; s=fm2; bh=m9idBWjz8z78pims0natO7ueN CDGho8dNtfU3NqB8lk=; b=ffGuPn9xEDgunp8bXPy4X+eMafgITAYkzcwFynZi6 nM4UyJQxfHfXjRVqSxD1BamZosOTd4Evyy6d0pE4XLlUETTACwF8DlKm/4Y9iYdq xqfD3GEFxMnjol8uD3ifk3regY1JqgPGxqz7K+kTemBb1HyUt3MaFGvvrYzdS5jc M1wWaD/fpqJ/PSjvyO2CfQJ5w+ZOA3Ev5pQohN8RCCI/LPF8sTre6RpXjnhFn1gY 24H42iRYNBHZhJ3DWFeHSjuGIcxNGRfRCX8hzf5D7upPfbioARlcDetzdOYDZjJj 2FDNVHev/HSppgOer+VjCAbMcL5ut1Caj/CYsm+1yDmGQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=m9idBWjz8z78pims0 natO7ueNCDGho8dNtfU3NqB8lk=; b=Ix1JdX7R8w41hZeuuwszTMphY0rlMWbtb qCUxVC8FOC8AYpxuzd7nzecZNJWAwcTRY6XDbRkmfko6vcDxOxpFzp7ysvlDcFh+ rMMYfb80zWta1ErZxToPZsC0NUayNEe6ckRw/his2wvaB0Vn6cYKwh3PIyC4osOu YSpN2Aw1SQEVBgpN8D92/FcQJLbW/TzOTeItGeWGlUX01tUer2WHEwgzObqFlZg5 YUnRIziq7v5bFLEWoqEkNWfmSGjBxD3LvhxIaanPKuAZNYx41vyUJBwSVeJdqKkG Ci4TlKc5uNWZqfhPJPQL4TwxtnQrrlSgo44nWIPwZQ4eASv2UUihA==
X-ME-Sender: <xms:nmeIXNCni1HyB0cRkwqBSWEUwPr71xhrLVKCVezY7PXOOYREsPMpow>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgeelgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghilhcu lfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqeenuc ffohhmrghinhepghhithhhuhgsrdgtohhmpdhjmhgrphdrihhonecurfgrrhgrmhepmhgr ihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomhenucevlhhush htvghrufhiiigvpedt
X-ME-Proxy: <xmx:nmeIXGn676op07WoFpJ-nsiTjZTZpTcyKh_ri7-maFdyBjHGw4hpqA> <xmx:nmeIXAqEeCPfcBFrqj2SCcFYiVFbuGLp14ih2FK-SBrjB_fPxSsyUQ> <xmx:nmeIXKBtkXJT1frx9SXJdPIlWXgByFvJo1KkBQTbDLbsiMP-sizr4w> <xmx:n2eIXNtomuF9HzVjeQcmc11h1ou6V12yPnhgS5bviSboadLpsI824w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4103920431; Tue, 12 Mar 2019 22:14:54 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5
X-Me-Personality: 64588216
Message-Id: <13279c7a-980a-4cd3-b37f-a9b7b26854c4@beta.fastmail.com>
In-Reply-To: <20190308194418.GU9824@kduck.mit.edu>
References: <155072687005.20308.1288342758446844678.idtracker@ietfa.amsl.com> <ebf89939-bf68-4458-a24f-5a37090385fd@beta.fastmail.com> <20190308194418.GU9824@kduck.mit.edu>
Date: Tue, 12 Mar 2019 22:14:53 -0400
From: Neil Jenkins <neilj@fastmailteam.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: iesg <iesg@ietf.org>, draft-ietf-jmap-core@ietf.org, Bron Gondwana <brong@fastmailteam.com>, jmap-chairs@ietf.org, IETF JMAP Mailing List <jmap@ietf.org>
Content-Type: multipart/alternative; boundary="8db7089f433a4383999ebd45860b1adb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/Edj_peIdHiTtIt7TRcF4HIxTnwk>
Subject: Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jmap-core-14: (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: Wed, 13 Mar 2019 02:15:06 -0000
On Sat, 9 Mar 2019, at 06:44, Benjamin Kaduk wrote: > > > An authenticated client can fetch the JMAP Session object with > > > details about the data and capabilities the server can provide as > > > > > > nit: maybe this is "a JAMP session object" with the indefinite article? > > > > I used the definite article here because the client is authenticated, and therefore has access to one specific JMAP session object associated with those credentials. > > Would that indicate "their"/"its", then? I'll make it *the *user's* JMAP session object.* > > > The 'prefixed with a "#"' laguage seems like it has some potential for > > > confusion; is it better to write this like "the first character of the > > > creation ID MUST be octothorpe ('#')"? > > > > The # is not part of the creation id. References to a creation id may be used in a context where an id is expected by prefixing the creation id with a #. Since this is not a valid character in an id, it is easy to determine that this must be a creation reference. I have added a reference at this point to the /set definition where this is explained in more detail. > > That will help, though I'm not sure exactly how much. > Looking at this again, I think the biggest thing that confused me on my > first read is that I didn't internalize that creation ids and > ResultReferences are different things (since they both use the magic "#" > prefix), and I was trying to reconcile them into the same bucket. > So maybe when ResultReference is introduced there could be a note about how > "the ResultReference performs a similar role to that of the creation id, in > that it allows a chained method call to refer to information not available when > the request is generated. However, they are different types and not > interchangable; the only commonality is the octothorpe used to indicate > them". But, maybe I'm unusual for being confused about this and it's not > worth the extra text. I don't think it hurts to clarify; I'll add this in. > > > Section 5.4 > > > > > > o *destroyFromIfInState*: "String|null" This argument is passed on > > > as the "ifInState" argument to the implicit _Foo/set_ call, if > > > made at the end of this request. > > > > > > This is "the Implicit _Foo/set_ call that effectuates the destruction of > > > the original", right? > > > > Yes. > > I think I was asking for a little more text here, basically to reiterate > that the Foo/set call is a deletion call. OK, I'll clarify this. > > > o *fromAccountId*: "Id" The id of the account emails were copied > > > from. > > > > > > o *accountId*: "Id" The id of the account emails were copied to. > > > > > > I assme the "emails" are copy/paste bugs. > > > > Yes, good spot. I've fixed this. > > > > > Section 7.2 > > > > > > o *deviceClientId*: "String" (immutable) An id that uniquely > > > identifies the client + device it is running on. The purpose of > > > this is to allow clients to identify which PushSubscription > > > objects they created even if they lose their local state, so they > > > can revoke or update them. This string MUST be different on > > > different devices, and be different from other vendors. It SHOULD > > > > > > What's the first vendor that's the basis for comparison? > > > > Sorry, I'm not quite sure what you're asking here. > > I think my fundamental confusion here is about where the device ID is > coming from -- is this supposed to be something like the serial number or > IMEI number from my phone, that is a fixed and permanently bound to a > specific device (and not changeable)? I think we delved into related > topics for Alissa's Discuss, but not quite into this aspect of things. If > I start talking about "vendors", is there some implication that the > identity of the current device's vendor is input to the > deviceClientId-generation process (whether explicitly or implicitly via a > manufacturer prefix in some other identifier)? So the literal answer to my > question here is something like the "first vendor" is the manufacturer of > the device being identified, or the author of the app generating this > specific deviceClientId. > > Even in the current text (-16), I wonder if "a device id" is quite enough, > as opposed to "a unique identifier associated with the device where the > JMAP client is running" or similar. Yes, this should be clearer. I have rewritten this to be: *This string MUST be different on different devices, and be different from apps from other vendors. It SHOULD be easy to re-generate, not depend on persisted state. **It is RECOMMENDED to use a secure hash of a string that contains:* * * 1. *A unique identifier associated with the device where the JMAP client is running, normally supplied by the device's operating system. * 2. *A custom vendor/app id, including a domain controlled by the vendor of the JMAP client. * * * *To protect the privacy of the user, the deviceClientId id MUST NOT contain an unobfuscated device id.* > > > Section 8.3 > > > > > > DNS SRV-based autodiscovery seems the only type of autodiscovery > > > available that is susceptible to the attack described here; you should > > > probably just state that explicitly. > > > > OK, will do. > > > > > Section 8.4 > > > > > > While true, 8529's security considerations are pretty sparse; we could > > > say more here about not overscanning, limiting string length, being > > > strict about tokenization, etc. > > > > Do you have any suggested text? > > As for any serialization format, parsers need to thoroughly check the > syntax of the supplied data. JSON uses opening and closing tags for > several types and structures, and it is possible that the end of supplied > data will be reached when scanning for a matching closing tag; this is an > error condition and implementations need to stop scanning at the end of the > supplied data. > > JSON also uses a string encoding with some escape sequences to encode > special characters within a string. Care is needed when processing these > escape sequences to ensure that an escape sequence is fully formed before > the special processing is triggered, with special care taken when the > escape sequences appear adjacent to other (non-escaped) special characters > or the end of data (as in the previous paragraph). > > If parsing JSON into a non-textual structured data format, implementations > may need to allocate storage to hold JSON string elements. Since JSON > does not use explicit string lengths, the risk of denial of service due to > resource exhaustion is small, but implementations may still wish to place > limits on the size of allocations they are willing to make in any given > context, to avoid untrusted data causing excessive memory allocation. Great, thanks, I'll add that in. > P.S. I appreciate the separate "description" column for the error registry > in the -16, but the formatting of the current table is basically > unreadable. I had to go find > https://github.com/jmapio/jmap/commit/3f4b7f83c99596a553bd81324c092516a9babbcf#diff-3004124a0560c91bfc79eb996bd81433 > to get something useful to look at. Yes, I'm hopeful the RFC editors may help with this; I'm not sure what the best approach is. (Just as an FYI, I also publish the latest version of the spec in a more readable HTML format at https://jmap.io/spec-core.html and https://jmap.io/spec-mail.html.) I'll post a -17 when submissions reopen and hopefully this can progress through to join the mail spec in the final editing stage. Cheers, Neil.
- [Jmap] Benjamin Kaduk's Discuss on draft-ietf-jma… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Alexey Melnikov
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Alexey Melnikov
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Neil Jenkins
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Neil Jenkins
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Neil Jenkins
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Neil Jenkins
- Re: [Jmap] Benjamin Kaduk's Discuss on draft-ietf… Benjamin Kaduk