Re: Threat model

Doug Barton <dougb@dougbarton.us> Mon, 14 March 2016 01:56 UTC

Return-Path: <dougb@dougbarton.us>
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 BAC6412D8B6 for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 18:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dougbarton.us
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 W5qNq23pmUDt for <ietf@ietfa.amsl.com>; Sun, 13 Mar 2016 18:56:19 -0700 (PDT)
Received: from dougbarton.us (dougbarton.us [IPv6:2607:f2f8:ab14::2]) (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 3CB9712D8B2 for <ietf@ietf.org>; Sun, 13 Mar 2016 18:56:19 -0700 (PDT)
Received: from [IPv6:2001:4830:1a00:8056:e0ab:e13a:62e3:f2b0] (unknown [IPv6:2001:4830:1a00:8056:e0ab:e13a:62e3:f2b0]) by dougbarton.us (Postfix) with ESMTPSA id 0A92E3A0BD; Mon, 14 Mar 2016 01:56:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dougbarton.us; s=dkim; t=1457920578; bh=P6OzfwvzrB4LInJRNnet1ImYuayRdFl+6tr254FIWII=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=T7CmH5vLHC3EwVGRgWNN7JvBkk8c2CkXw0cHjI8Rtm0d2spp807UykCsKuXjMKSOp uyDWPEG+G+FnISkDNONudUaJEMltZCiE9BwuMz+Mc6ATBiYaSX7PdUcHgCNHy6ra9o VxCgCo/IPcR0uCl3tGt8NsFORWe9OoOjigrV3SBE=
Subject: Re: Threat model
To: John C Klensin <john-ietf@jck.com>, Paul Wouters <paul@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> <7712DD353F3F286F2245B71F@JcK-HP5.jck.com>
From: Doug Barton <dougb@dougbarton.us>
Openpgp: id=E3520E149D053533C33A67DB5CC686F11A1ABC84
Message-ID: <56E61A3B.1010201@dougbarton.us>
Date: Sun, 13 Mar 2016 18:56:11 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <7712DD353F3F286F2245B71F@JcK-HP5.jck.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/q4qN0eNs-fAwpzaIJ-VFdpuxYfQ>
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: Mon, 14 Mar 2016 01:56:20 -0000

On 03/13/2016 08:40 AM, John C Klensin wrote:
> 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.

I agree that the draft needs to spell this out in more detail.

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

Paul has a point here. For good reasons or ill, the number of "eyes" 
(where "eyes" can also be various forms of machine tools) "on the path" 
can be non-trivial.

It's also worth reiterating one of his points ... the risk to neither 
the sending nor the receiving user is not increased, and may in fact be 
decreased, by the mechanism described in the draft. Do you believe 
differently? (Note, I'm not asking about your analysis of the relative 
"worth" of the decrease. I'm only interested in whether you see that 
there is a decrease, or more significantly, if you see an increase in 
risk, and why.)

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

I disagree quite strongly with your assessment here.

Further, your caveat of "encrypted in the key of the right party" by 
definition precludes using OPENPGPKEY as the sole point of information 
in determining said key, which renders your argument here moot.

Doug