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

[Ned Freed <[e-mail]>]

> Hm.  I don’t see that.  All you get in response to the IDLE command is the
> same stuff you get from the NOOP command or from any other IMAP command:
> untagged FETCH and EXPUNGE responses.

If IDLE was the same as NOOP then we wouldn't have added the IDLE command to
the protocol.

> Technically, they’re not actually
> responses to the command: they’re unsolicited messages in the IMAP protocol.

It's right there in the abstract:

   The Internet Message Access Protocol [IMAP4] requires a client to
   poll the server for changes to the selected mailbox (new mail,
   deletions).  It's often more desirable to have the server transmit
   updates to the client in real time.  This allows a user to see new
   mail immediately.  It also helps some real-time applications based on
   IMAP, which might otherwise need to poll extremely often (such as
   every few seconds).  (While the spec actually does allow a server to
   push EXISTS responses aysynchronously, a client can't expect this
   behaviour and must poll.)

Note the last sentence: If accepted IDLE requires that the server return
changes in mailbox state in real time. That opens the door to certain
types of traffic analysis.

Now, since the protocol does allow EXISTS responses to be pushed regardless
of IDLE, you can include RFC 3501 in having deficient security considerations
in this regard.

The fact remains that there's a missing security consideration here.

> What security considerations should there be for IDLE that are beyond those
> for NOOP (that is, IMAP itself?

NOOP is pull and done at the client's discretion, IDLE is push and triggered
by server changes.

				Ned