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

["Neil Jenkins" <[e-mail]>]

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.*

> > 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.

> > > 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.

Neil.