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

Ned Freed <ned.freed@mrochek.com> Fri, 04 January 2019 22:10 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 35A18130E90; Fri, 4 Jan 2019 14:10:50 -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 4_GoaJV21sNr; Fri, 4 Jan 2019 14:10:49 -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 2F7BC126BED; Fri, 4 Jan 2019 14:10:49 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1M7QJJPG000AVXT@mauve.mrochek.com>; Fri, 4 Jan 2019 14:05:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546639545; bh=kkXce7HsCIDRBhoN1l8cVfW+AEXOob5s5Yj/yXjMRp0=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=gZkOylh7WTm1Wrdtb+eRtO9TdY58lY1yOL/JvQA8i2RlpnhXTfh+tzv56GmZXo4zW csfFWywde8W1esxzfgArNwTkWzbtlbW6Wu4b/191wx8okz33w8KkQPdcW/wwN+GL+D I332p1fpU3XwcMSm3E1K2oW2u+7NeGZfIcY9oDqU=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1LW7PXKJ400004R@mauve.mrochek.com>; Fri, 4 Jan 2019 14:05:41 -0800 (PST)
Cc: Tero Kivinen <kivinen@iki.fi>, IETF JMAP Mailing List <jmap@ietf.org>, draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org
Message-id: <01R1M7QIBP9I00004R@mauve.mrochek.com>
Date: Fri, 04 Jan 2019 13:45:49 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Thu, 03 Jan 2019 09:21:12 -0800" <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com>
To: "Kurt Andersen (IETF)" <kurta+ietf@drkurt.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/xVHXeSIKAlUFR0WpN-7vXkYJeCA>
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: Fri, 04 Jan 2019 22:10:50 -0000

> On Thu, Jan 3, 2019 at 4:04 AM Tero Kivinen <kivinen@iki.fi>; 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.

An update to RFC5598 may also be order, but that's a problem for another day.

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

				Ned