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

Ned Freed <ned.freed@mrochek.com> Tue, 08 January 2019 17:22 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D61130F0B; Tue, 8 Jan 2019 09:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Level:
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 KWAIxI9tmppO; Tue, 8 Jan 2019 09:22:35 -0800 (PST)
Received: from mauve.mrochek.com (unknown [66.159.242.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFD56130F08; Tue, 8 Jan 2019 09:22:34 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1RITPR28000DL4N@mauve.mrochek.com>; Tue, 8 Jan 2019 09:16:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546967843; bh=YlmX2BSOFsNN3GP6rqL6fsCWlPdXnoDAor4nhcv9/LY=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=K/5tbu6n+deV3YKpbscIujqHwySaZpKv33Yqmgm/NfzAAlWeQjXCjKx4Pq/WUH9wI Y+2dvBXkkjBgGsWPwNWdIHqnqbLs8XC/clJOmjsGaYE6fIunu/BApYzzU9dOSwqaid PqhocFAch1HMjE5o/5+Qa/ehvnHJx7o2NksvAOAw=
MIME-version: 1.0
Content-transfer-encoding: 8BIT
Content-type: TEXT/PLAIN; charset=UTF-8
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Tue, 8 Jan 2019 09:16:43 -0800 (PST)
Cc: Ned Freed <ned.freed@mrochek.com>, IETF JMAP Mailing List <jmap@ietf.org>, "Kurt Andersen (IETF)" <kurta+ietf@drkurt.com>, Tero Kivinen <kivinen@iki.fi>, Tony Finch <dot@dotat.at>, draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org
Message-id: <01R1RITKNL3G00004L@mauve.mrochek.com>
Date: Tue, 08 Jan 2019 08:04:29 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 08 Jan 2019 07:46:36 +0800" <CALaySJ+B4upNdNcieMoR5uUJ-06vxu4UzHWKKzStTrF0k-9u9w@mail.gmail.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <alpine.DEB.2.20.1901071223520.3160@grey.csi.cam.ac.uk> <01R1Q3OA5O7800004L@mauve.mrochek.com> <CALaySJ+B4upNdNcieMoR5uUJ-06vxu4UzHWKKzStTrF0k-9u9w@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/yqcmuRD_qjMn4ec4j0DJDUnVsSs>
Subject: Re: [secdir] [Jmap] Secdir last call review of draft-ietf-jmap-core-12
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jan 2019 17:22:36 -0000

> 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