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

Ned Freed <ned.freed@mrochek.com> Sat, 05 January 2019 19:34 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 2FDA5130DD7; Sat, 5 Jan 2019 11:34:04 -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 Se7xloCgjvoG; Sat, 5 Jan 2019 11:34:02 -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 9176B130EBE; Sat, 5 Jan 2019 11:34:02 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1NGKEZT6O00CU83@mauve.mrochek.com>; Sat, 5 Jan 2019 11:28:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1546716534; bh=sf4c36YZ4BNCMpQJ5V5igQn3Ldam/WhPWvkvpXIiZ/I=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=ZSTpVD8P5VUslVAyBlJ9Xs6X28+x6NMouWyQMA2dJ5GBeP9M8DtAIBvTaZ25Q/idR FYMHUyMhczd8Wdb9WCZ/pbLJP+TPhCs/iNpikkJFc3vG81ACGX/HHPqI1w+WVPqVV6 APOvuz5PZ4gUgglioX7ClZW4jLAssQexc6lXs5EE=
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 <01R1N39ADWKW00004L@mauve.mrochek.com>; Sat, 5 Jan 2019 11:28:47 -0800 (PST)
Cc: Ned Freed <ned.freed@mrochek.com>, "Kurt Andersen (IETF)" <kurta+ietf@drkurt.com>, IETF JMAP Mailing List <jmap@ietf.org>, "draft-ietf-jmap-core.all@ietf.org" <draft-ietf-jmap-core.all@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Message-id: <01R1NGKAIUZQ00004L@mauve.mrochek.com>
Date: Sat, 05 Jan 2019 11:15:43 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 04 Jan 2019 23:10:10 +0000" <a7fdf568d65e4d5aa60201dcfc5c45e0@cmu.edu>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com> <01R1M7QIBP9I00004R@mauve.mrochek.com> <a7fdf568d65e4d5aa60201dcfc5c45e0@cmu.edu>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/95RTYkuAMI8z9Z9N6KSzFAuwJLw>
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: Sat, 05 Jan 2019 19:34:04 -0000

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

Not really. The security considerations, while extensive, do not cover
traffic analysis of notifications pushed directly to the client, which is
the main concern here. And neither do the other RFCs defining specific sieve
notification mechanisms.

This is likely because all of the mechanisms we were standardizing have a
different set of security issues. Indeed, almost all of the considerations
covered in RFC 5435 et al. are orthogonal to the current case, which is why I
didn't suggest citing RFC 5435 et al. in the current document.

				Ned