Treat model (was: Re: dane-openpgp 2nd LC resolution)

John C Klensin <john-ietf@jck.com> Sun, 13 March 2016 15:40 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC1712D5CB for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 08:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 dXOP_0L2RKBD for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 08:40:46 -0700 (PDT)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9E0B12D5C2 for <ietf@ietf.org>; Sun, 13 Mar 2016 08:40:46 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1af88K-000AR7-Gu; Sun, 13 Mar 2016 11:40:44 -0400
Date: Sun, 13 Mar 2016 11:40:39 -0400
From: John C Klensin <john-ietf@jck.com>
To: Paul Wouters <paul@nohats.ca>, Doug Barton <dougb@dougbarton.us>
Subject: Treat model (was: Re: dane-openpgp 2nd LC resolution)
Message-ID: <7712DD353F3F286F2245B71F@JcK-HP5.jck.com>
In-Reply-To: <alpine.LFD.2.20.1603121603040.11476@bofh.nohats.ca>
References: <56DC484F.7010607@cs.tcd.ie> <3470AB158222ED0ECAF2CAEA@JcK-HP8200.jck.com> <56E478F7.5070907@dougbarton.us> <alpine.LFD.2.20.1603121603040.11476@bofh.nohats.ca>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/Rsyry_QR7A33cCmgTR5olMgPcXY>
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Mar 2016 15:40:48 -0000

Part 2 of 2 -- see introduction to immediately prior note.

--On Saturday, March 12, 2016 12:15 PM -0800 Doug Barton
<dougb@dougbarton.us> wrote:

> Given that the DNS RR in question is something the end user
> has to explicitly request, the danger is not immediately
> obvious to me.

--On Saturday, March 12, 2016 4:09 PM -0500 Paul Wouters
<paul@nohats.ca> wrote:

> 2 In an email server has paul@nohats.ca and Paul@nohats.ca,
> AND these are different users, then instead of JUST mailing
> the wrong user in plaintext, the wrong user is emailed
> encrypted to that user. This is functionaly still better than
> the current deployment, since only 1 wrong user can see the
> (encrypted) email instead of everyone on the path plus the
> user who can see the never-encrypted email.

That depends entirely on the threat model you are concerned
about.   I (and others) have repeatedly asked that you be
explicit in the I-D about applicable threat models (aka "the
problem you are trying to solve") in more specificity then you
have now and that you see if you can get consensus.   If the
goal is to try to get more email on the Internet encrypted as an
"opportunistic" matter, then certainly your reasoning is
correct, perhaps modulo one other issue.

In our quest for more privacy, language like "everyone on the
path" implies something similar to letters being posted in shop
windows for public viewing before being delivered (or as a means
of delivery).  The reality is the most ISPs, and most operators
of mail servers and relays, take at least some measures (often
strong ones) to ensure that the collection of people who can get
to a message in transit is very restricted and a lot short of
"everyone".  Yes, those measures, and the ISPs and mail
providers themselves, can be subverted or forced to expose
message traffic, but the parties who can do that aren't
"everyone" either.  If one is interested in attacks from them
--either on you or as part of a pervasive surveillance effort--
then the threat model changes quite a bit.

In particular, if a user has a sensitive information to
transmit, information that will not be transmitted at all unless
there is high assurance that it will go encrypted and encrypted
in the key of the right party, then the choice between "one
wrong person sees it" and "everyone sees it" is a not-starter.
With the treat model implied by that sort "must go encrypted"
model for sensitive material, the alternative to "correctly
encrypted" is "don't send" and sending and delivering to the
wrong party, encrypted with that party's key, is a disaster.

In the hope of avoiding a rat hole, the above has nothing to do
with the argument that everything should be encrypted to provide
cover for the sensitive stuff or make life harder for those
involved in pervasive surveillance.  If one believes that
everything should be encrypted, then it may be ok be less
careful about how messages that are less sensitive are encrypted
(keys found, etc.) than for ones containing really sensitive
materials.

best,
    john

p.s. See last paragraph of part 1 for comments -- slightly less
applicable here -- about the relationship of this discussion to
the dane-openpgp draft.