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

Tero Kivinen <kivinen@iki.fi> Fri, 04 January 2019 23:10 UTC

Return-Path: <kivinen@iki.fi>
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 6ACDA130EA2; Fri, 4 Jan 2019 15:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level:
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no
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 2UKthjD4mCPm; Fri, 4 Jan 2019 15:10:03 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 49215126BED; Fri, 4 Jan 2019 15:10:03 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x04N9vP9021362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 5 Jan 2019 01:09:57 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x04N9vWC011125; Sat, 5 Jan 2019 01:09:57 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23599.59333.151268.270953@fireball.acr.fi>
Date: Sat, 05 Jan 2019 01:09:57 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Barry Leiba <barryleiba@computer.org>
Cc: "Kurt Andersen (IETF)" <kurta+ietf@drkurt.com>, IETF JMAP Mailing List <jmap@ietf.org>, draft-ietf-jmap-core.all@ietf.org, secdir@ietf.org
In-Reply-To: <CALaySJ+-CCiQbgkF8fb_+60yD8t=UHKAPZqBuDZRZQ6NYppu0Q@mail.gmail.com>
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com> <CALaySJ+-CCiQbgkF8fb_+60yD8t=UHKAPZqBuDZRZQ6NYppu0Q@mail.gmail.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 8 min
X-Total-Time: 8 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/XNdhX7xsEhS2trv1sC8Mu7R3Jgg>
Subject: Re: [secdir] 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 23:10:06 -0000

Barry Leiba writes:
> I think that advice to use TLS whenever possible is the extent of
> what makes sense to say here.

Using TLS does not help here, as this attack is traffic analysis
attack, and you can do traffic analysis even when all the traffic is
encrypted. The current draft already says that all request MUST use
TLS.

> As to shared folders, that is neither “bad” nor “risky”: it’s necessary for
> many use cases.  For example, IETF itself uses shared IMAP folders to serve up
> our mailing lists.  Help desks will use a shared inbox for, say, 
> ithelp@example.com, to allow multiple agents to handle questions and
> complaints, while maintaining accountability (each agent has a separate login,
> so their activity is tracked).

Agreed. I was not saying it is bad or risky, but the none of the
examples you gave are not really examples of

  ... if another user is sharing their mail with the logged in
   user, ...

All of those are examples of user gaining access of group account
(which is also mentioned). So my comment was that two individual users
sharing their individual mails with each other is not really that
common, and has much more privacy concerns than it help desk having
shared inbox. Sharing calendar entries also has privacy concerns, but
most people do understand them better and calendars provide ways of
separating private / public entries already.

So, I think changing the text:

   A single set of credentials may provide access to multiple accounts,
   for example if another user is sharing their mail with the logged in
   user, or if there is a group account.

to something like this:

   A single set of credentials may provide access to multiple
   accounts, for example if another user is sharing their work
   calendar information with the logged in user. Another example of
   cases where access to multiple accounts can be useful is when
   logged in user can also access shared group account mailbox (for
   example it help desk inbox).

would make the text better. 
-- 
kivinen@iki.fi