Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12

[Jeffrey Hutzelman <[e-mail]>]

From: secdir <[e-mail]> on behalf of Ned Freed <[e-mail]>
Sent: Friday, January 4, 2019 4:45 PM
To: Kurt Andersen (IETF)
Cc: IETF JMAP Mailing List; [e-mail]; [e-mail]
Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12

> On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <[e-mail]> wrote:

> > Reviewer: Tero Kivinen
> > Review result: Has Issues
> >
> > This document also has quite a lot of privacy concerns which are not
> > addressed by it. For example email delivery and event notifications can
> > leak lots of information even to passive attackers.
> >

> How is this any different than the risks present in current mechanisms
> (websockets, HTTP, MAPI, IMAP, etc.)? I don't see this as a new risk being
> introduced by the JMAP protocol.

AFAICT it's different in the sense that this is the first push email
notification mechanism we have standardized. Push notifications also
aren't mentioned in RFC 5598.

So we get stuck with documenting the security concerns.

It may be the first such mechanism we've standardized, but it's certainly not the first time we've contemplated push notification of email delivery. Consider RFC5435 (the Sieve notify extension), published just about 10 years ago this month. Among other things, it contains extensive discussion of security considerations surrounding push notification.



> > Of course sharing mailboxes between multiple users (one of the
> > examples given in 1.6.2), has lots of privacy issues.

> Again, this is not a new risk being introduced by JMAP. It seems unfair to
> saddle the JMAP protocol with the responsibility of documenting a
> comprehensive set of privacy and security risks for bad or risky behaviours
> that have been a wide part of common practice for decades.

I'll first note that although the JMAP specification refers to the IMAP ACL
security model extensively, RFC 4314 is not in the references list. That needs
to be fixed, and a note in the security considerations section saying that the
security considerations for IMAP ACLs apply to JMAP would also be good.

And if the security considerations in the IMAP ACL document are
deemed to be insufficient, further elaboration of some additional points may
also be in order.

As for fairness, the goal here is to produce quality standards. Sometimes
achieving that goal means you get stuck with stuff you'd rather not have
to do.

True, but shared mailboxes are hardly new. They've been around pretty much since the beginning of time. Giving advice to operators about security and privacy issues surrounding shared mailboxes or any of a number of common user practices seems, to me, to be far out of scope for an access protocol specification.

That's not to say that JMAP doesn't need to document security issues; of course it does. If those are substantially similar to, say, IMAP, then the documentation is going to be, too. And if there are issues that were missed in the past or have only recently become topics of discussion, that doesn't mean they can just be ignored. But I do think it's important to keep the scope manageable.

-- Jeff