Re: dane-openpgp 2nd LC resolution

Paul Wouters <paul@nohats.ca> Mon, 14 March 2016 23:26 UTC

Return-Path: <paul@nohats.ca>
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 1FED012D7F5 for <ietf@ietfa.amsl.com>; Mon, 14 Mar 2016 16:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.101
X-Spam-Level:
X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.001] autolearn=no 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 xoRTHOuglMMh for <ietf@ietfa.amsl.com>; Mon, 14 Mar 2016 16:26:22 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 BCA3412D7D8 for <ietf@ietf.org>; Mon, 14 Mar 2016 16:26:21 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qPDQh0sW7z1jQ; Tue, 15 Mar 2016 00:26:20 +0100 (CET)
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id ZLe4H513_c7S; Tue, 15 Mar 2016 00:26:19 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 15 Mar 2016 00:26:19 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 65509603BBA1; Mon, 14 Mar 2016 19:26:18 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 65509603BBA1
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 63C2EA3C7; Mon, 14 Mar 2016 19:26:18 -0400 (EDT)
Date: Mon, 14 Mar 2016 19:26:18 -0400 (EDT)
From: Paul Wouters <paul@nohats.ca>
To: John C Klensin <john-ietf@jck.com>
Subject: Re: dane-openpgp 2nd LC resolution
In-Reply-To: <2A69D7982E2992DED26AE5A6@JcK-HP8200.jck.com>
Message-ID: <alpine.LFD.2.20.1603141918400.830@bofh.nohats.ca>
References: <20160313171101.3215.qmail@ary.lan> <F4DDCAC0-ACDF-4FD9-978E-90F4349A0420@dukhovni.org> <D82585411EE24A700558FD25@JcK-HP5.jck.com> <alpine.LFD.2.20.1603131922060.27864@bofh.nohats.ca> <2A69D7982E2992DED26AE5A6@JcK-HP8200.jck.com>
User-Agent: Alpine 2.20 (LFD 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/4aTAIrDmhBWQHAoGkRx9lEvjESE>
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 23:26:23 -0000

On Mon, 14 Mar 2016, John C Klensin wrote:

> However, consider a different case.  Assume I have a message,
> whose content I consider sensitive, that I need to transmit to a
> party I know but with whom I have not corresponded by email
> before (and, therefore, Doug's "replying to message" case does
> not apply).   Now I don't need to send that by email.  I may
> have the post, fax, assorted courier services, reading it on the
> phone (PSTN or VoIP), transmission it by IM or text message, and
> other methods available to me.   I might even consider semaphore
> flags, not because they are "secret" in the "out of sight" sense
> but because very few people can read them these days and because
> the message information is more transient and volatile than most
> of the above.
>
> In ranking the above for preserving the secrecy of my sensitive
> message and making a choice of method, it is at least as
> important for me to understand just how secure a given method is
> as that it be "secure" in the abstract.

If your information is "sensitive" then hopefully you could tell
your email client that. That email client might try various things,
including looking up an OPENPGPKEY record. When found, it could
look at signatures - maybe even trying to look those up using
OPENPGPKEY or on existing pgp keyservers. It would present you
with the data for you to make an informed decision.

> Now, _in that context_, your second option is a big problem
> because it implies accidental disclosure

The accidental disclosure to a "wrong email address" is not worse
when encrypted than it is now if you send it unencrypted. If you
risk mistyping the username and encrypting it to the wrong user,
this draft cannot help you. It has no powers to mind read the
user.

> So it seems to me that, at least for information perceived by
> the sender as sensitive enough to deserve special treatment, the
> "otherwise the message goes in the clear" case is not applicable
> because the actual case is "otherwise the message doesn't get
> transmitted over Internet email".

I know of no way to codify the user to email agent interaction
based on "user considers content sensitive" other than the user
stating "send this message encrypted only", which something like
enigmail, a thunderbird email client plugin, can already do. You
mistyping the email address again is not something we can protect
against in a protocol. You could have a local policy of saying
"always confirm email address before sending to any address for
the first time" but all of this is completely out of scope for
the document.

> [1] As an aside, if I've got a trusted way to obtain that
> fingerprint without using the DNS, I most likely have another
> way to obtain the key so I don't need this I-D and protocol.

But you cannot tell if pgp.mit.edu is down, or whether an attacker
is actively blocking you from obtaining the target's public key.
With OPENPGPKEY, you can.

Paul