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

Barry Leiba <barryleiba@computer.org> Sun, 06 January 2019 01:01 UTC

Return-Path: <barryleiba@gmail.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 360F0130ED9; Sat, 5 Jan 2019 17:01:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 gqdWx6ntjU9T; Sat, 5 Jan 2019 17:01:15 -0800 (PST)
Received: from mail-it1-f173.google.com (mail-it1-f173.google.com [209.85.166.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59E3130ED4; Sat, 5 Jan 2019 17:01:15 -0800 (PST)
Received: by mail-it1-f173.google.com with SMTP id i145so6433696ita.4; Sat, 05 Jan 2019 17:01:15 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YsAUkMcUOqZMdFK1YecIWKd8txpq7HeDgJYQou/tk8w=; b=H5wLMLouvSdcGk50sLTpAPV5IDGfg3IVuG4QT1XFnlgSnrjwwVXpmHck/m/ONVAmAL gPe3Bh3cZaC2qLTEJXO5EagUMeXUA7fwIFcxhKf8GwJg6QmsJEK7cBpPoeCgxduKJGqf 5o0ygtN4unjIHj0tKBbZw+KnR5G+Q73yUz6H+a3zEBlS+IWjIv3+PiRoqubYBzxu/EyD Ie5ZgXMd6tcxWXZbLZWNbSa/nMbRrZO9L/T1tTbMUn+VcmunX+JsIjmg5H8Eiqj8U/y+ cZ5tyLV7L7S2i4EBC62kAqxuVr3dEwTziD5RFjzwzBzBUAcMKwWbiKLsCEMuPoTAdJ+2 kncw==
X-Gm-Message-State: AJcUukfEixiiYD26s/gdfuSRKgGE9T5N32/CrZ0lyTDiC9so4NdV0ukP ISkaQ0RtlWzYx8DPzo/LhXdSR+bvbpDxFXp+uX8=
X-Google-Smtp-Source: ALg8bN6NVr0yZbxhykAk6YAFcOPSFUGFublIW5Uw0kTWcIYYD01tFEEzsARTpjLBqcZmPr9HLKpVeT7Cdwm6CpcOCd8=
X-Received: by 2002:a24:a04:: with SMTP id 4mr4271565itw.122.1546736473687; Sat, 05 Jan 2019 17:01:13 -0800 (PST)
MIME-Version: 1.0
References: <154651703823.29557.748556981627156046@ietfa.amsl.com> <CABuGu1oM4qBcMNxh=rnWCSD-tVJYcNmDaL+orwBqq=OAvKWOZg@mail.gmail.com> <20190105185050.GB28515@kduck.kaduk.org>
In-Reply-To: <20190105185050.GB28515@kduck.kaduk.org>
From: Barry Leiba <barryleiba@computer.org>
Date: Sun, 6 Jan 2019 09:01:02 +0800
Message-ID: <CALaySJKezOW02CUfUnCSTUfC4CTcrmLnFu-Ttwd4U3Cn7Txt-A@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: IETF JMAP Mailing List <jmap@ietf.org>, "Kurt Andersen (IETF)" <kurta+ietf@drkurt.com>, Tero Kivinen <kivinen@iki.fi>, draft-ietf-jmap-core.all@ietf.org, iesg@ietf.org, secdir@ietf.org
Content-Type: multipart/alternative; boundary="000000000000134dbe057ebfa6be"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/bLl572APF6oUNYLSlcmdnxMTdr8>
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: Sun, 06 Jan 2019 01:01:18 -0000

I agree with Ben that when documentation has been lacking in the past we
may need to fix that in current documents.  The problem, I fear, is that we
write much of this, especially at the app layer, to the wrong readers, so
let’s think about the shared mailbox case, for example, and see if we know
what will actually help, rather than tick off some IETF-process-related box.

What we write in RFCs is primarily for software developers.  It would be
truly bad if security/privacy warnings dissuaded developers from supporting
shared mailboxes: any mail system that lacks such support would be hobbled
and bad.

So the best we could try would be to get vendors to copy or paraphrase our
warnings in their documents, and/or to show warnings when the features are
configured at installation.  I think it’s unlikely to happen.  Similarly,
when a user shares a mailbox a popup could show... also unlikely.

And what are we going to say?  That sharing a mailbox that contains
personal mail can expose private information?  That’s at the same time so
obvious as to be silly, and entirely irrelevant to the actual
shared-mailbox use cases.

I think the best approach is to give examples of common use cases for
sharing.  That might be informative and might actually prompt some vendors
to include similar examples in their doc.

Barry

On Sun, Jan 6, 2019 at 2:51 AM Benjamin Kaduk <kaduk@mit.edu>; wrote:

> [I wrote this before I noticed that half the thread was stuck in my spam
> quarantine.  Some of the points were made already, but I've left my text
> unchanged to avoid making it even less comprehensible that it was to start
> with.]
>
> On Thu, Jan 03, 2019 at 09:21:12AM -0800, Kurt Andersen (IETF) wrote:
> > 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.
>
> But where is it documented for those other protocols?
>
> > 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.
>
> In general, we need to either document ourselves or point to existing
> documentation of the security considerations relating to protocols we
> publish.  "Everybody already does [bad practice X]" does not excuse us from
> ensuring that the risks are adequately documented.  Is it unfair?  Perhaps.
> But the IETF consensus so far seems to be that we need to properly document
> that which we cannot make secure, and if we're the first one to actually
> document it properly, then we do incur the extra burden of doing things
> right.
>
> -Benjamin
>