Re: dane-openpgp 2nd LC resolution

[Paul Wouters <[e-mail]>]

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