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.
- dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution E Taylor
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Treat model (was: Re: dane-openpgp 2nd LC resolut… John C Klensin
- Case distinctions as theoretical exercise (was: R… John C Klensin
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution John Levine
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise Doug Barton
- Re: Threat model Doug Barton
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: Case distinctions as theoretical exercise John C Klensin
- Re: dane-openpgp 2nd LC resolution John R Levine
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Paul Wouters
- Re: dane-openpgp 2nd LC resolution Doug Barton
- Re: dane-openpgp 2nd LC resolution Viktor Dukhovni
- Re: dane-openpgp 2nd LC resolution Mark Andrews
- Re: dane-openpgp 2nd LC resolution Warren Kumari
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: Case distinctions as theoretical exercise John Levine
- Re: Case distinctions as theoretical exercise Phillip Hallam-Baker
- Re: dane-openpgp 2nd LC resolution Stephen Farrell
- Re: dane-openpgp 2nd LC resolution John C Klensin
- Hashing local-parts of addresses (was: dane-openp… ned+ietf