--On Sunday, March 13, 2016 19:28 -0400 Paul Wouters
<paul@xxxxxxxxx> wrote:
> Note again that the "risks" are:
>
> 1) email being sent to the intended user in the clear like it
> happens now.
> 2) email being sent to the wrong user encrypted to the wrong
> user's key,
> which is not as bad as being sent in the clear like it
> happens now.
We don't quite agree about the "not as bad" part. Let me try
once more to explain why. I understand that you may not agree
with the analysis but I should probably add that I don't find
statements like "it isn't as bad" persuasive by themselves.
Again, this appears to me to be about different attack and data
protection models and perhaps different priorities. If were is
no such thing as a highly sensitive message and the only reason
for encryption was to protect against casual snooping (or
pervasively gathering up everything in case it might prove to be
of interest), I would completely agree with your risk summary
above.
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 one ignores my
earlier comment about protective methods imposed by
ISPs/Carriers and mail relay operators, "email sent in clear" is
a non-starter: I need to either modify the message so it isn't
sensitive, use a well-protected code rather than relying on
cryptography, or, more likely than either, make a different
choice about transmitting the message.
Now, _in that context_, your second option is a big problem
because it implies accidental disclosure, possibly to an
attacker who has deliberately acquired a confusable address
(note similarities to phishing and confusable domain names here)
in an environment in which I had reason to believe that the
message transmission was fully secure. If I understand the
risks, I do one of two things:
(i) I get super-careful about checking the identifier in the key
to make sure it matches an email address I want to send to
and/or check the key against a fingerprint that I've obtained in
some other way and trust [1]. Probably I do that if I prefer
email. Typical users don't, as we know from other experiences.
(ii) I use some other mechanism, one that I consider more
secure, to transmit the message.
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". And the second case is
either a real and significant risk due to the sender believing
that she has a level of protection that doesn't actually exist,
or is nearly impossible because the sender makes checks for
which the I-D does not spell out the necessity.
best,
john
[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.
When that argument is reversed, some of the advantages of Doug's
suggestion (somewhat similar to that of others, earlier) to put
fingerprint (and maybe other) information in the DNS rather than
the key itself become obvious. But, if we are really committed
to letting a thousand experiments bloom, that is not relevant.