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

[Benjamin Kaduk <[e-mail]>]

On Sun, Mar 03, 2019 at 09:52:33PM -0500, Neil Jenkins wrote:
> On Sat, 2 Mar 2019, at 07:10, Benjamin Kaduk wrote
> > So this adversarial scenario just would need to change "create/update" to
> > "create/update/delete" to be covered.
> 
> Agreed, I'll make this change.
> 
> > > It's stating that on the next resync, whether that be due to a future push for the same type, or the client making any /get or /set for that type and seeing the different state string returned, will result in the client coming fully up to date. Losing the push does not mean there is data the client will now no longer see.
> > 
> > Perhaps there is room for a little more clarity on what "it syncs" means
> > (i.e., full sync or just scoped to a specific data type). To be clear,
> > this is a fine design; I just want to be sure that we have clarity of
> > language in describing it.
> 
> OK, how about this:
> 
> *It doesn't matter if some push events are dropped before they reach the client; next time it gets/sets any records of a changed type it will discover the data has changed and still sync all changes.*

That works (modulo the nit of "the next time").

> > > There isn't one, because as far as I can see RFC8291 <https://tools.ietf.org/html/rfc8291> doesn't have one and that's what this is supporting. What do you suggest?
> > 
> > The pragmatic thing to do would be to note in the security considerations
> > that there is no algorithm agility for Web Push Encryption, and if agility
> > becomes needed in the future a spec update would likely be needed to
> > provide it.
> 
> Sure, happy to do that.

I've been informed in the meantime that the idea of the HTTP Encryption
coding folks, as specified in Section 2 of RFC 8188, is that you define a
new content-coding scheme (i.e., other than "aes128gcm") if you need a new
cipher.  So it probably wouldn't be too painful if we did need to slot a
new one of these in.

> > > > Also, when these expirations fire (e.g., for Basic Authentication
> > > > credentials), we need a normative requirement to actually destroy the
> > > > private credentials; there's a lot going on here so maybe I missed it,
> > > > but I don't think I saw one.
> > > 
> > > I think we already have this. The spec says:
> > > 
> > > *The push subscription is tied to the credentials used to authenticate the API request that created it. Should these credentials expire or be revoked, the push subscription MUST be destroyed by the JMAP server.*
> > > 
> > > Or were you referring to something else?
> > 
> > I was thinking that you need to clear out the memory/disk storage that hold
> > the credentials (e.g., password), as well as destroying the subscription
> > object. We don't want plaintext credentials floating around longer than
> > needed.
> 
> Which credentials are you referring to here? The push subscription doesn't contain any except I guess for the URL itself; I can note that this and the encryption keys MUST be securely erased from memory/storage immediately when the subscription is destroyed? If you're referring to the client's credentials, we're explicitly talking about when they've been expired or revoked, so are already useless.

I may have been confused about whether this was JMAP Client/JMAP Server or
JMAP Server/push server interactions.  That is, I was thinking about the
JMAP server clearing out any keys or credentials it had for the second sort
of interaction.  So I guess that translates to "when the subscription
expires, wipe your copy of the client-generated encryption keys", right?

Thanks,

Benjamin