--On Saturday, February 01, 2014 15:34 -0800 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:
On 2/1/2014 3:18 PM, John C Klensin wrote:
(1) Other than a probably-appropriate level of general
paranoia, do we have
any reason to believe that PGP (Symantec and/or GNUPG
versions) has been
sufficiently compromised to not provide a good defense against
either
pervasive surveillance or general snooping?
1. It has demonstrated unacceptable usability for average
users.
Agree completely, but that wasn't the question.
Noting the email systems with which we are both familiar as
examples and the history of attacks (whether technical or
legal-judicial) on intermediate systems (relays and otherwise),
if we are asked today what our best end to end technology
options are, those are it. The acceptability part is, at least
IMO, a combination of a "not needed enough to be worth the
trouble" and the difficulties of managing public, and especially
private, keys. For the first, I suspect that there are a lot
more people in the world who care enough to go to extra trouble
than was the case a year or so ago. We could debate whether "a
lot" is actually large enough to be a significant number, but
even if I agreed that it was not, I would rather tell a
concerned user "the best technology we have is annoying and
will require you and your correspondents to learn more, and fuss
more, than you would probably like" than "if you can't trust
your email provider, its choice of relays, and any relevant
governments, you are screwed and the IETF is ok with that".
2. It does not protect the header or the envelope, to the
extent anyone cares about divulging the Subject or other
message meta-data...
Extending from and building on my comments above, is your
preferred alternative "sending email is hopeless; if you don't
want to be monitored, you should go back to something secure
like smoke signals (uh, whoops)". For many purposes, if one has
a choice between solid content protection with no or weak
envelope protection and no protection at all, the answer is
obvious. Conversely if one had good envelope protection that
provided only hop-by-hop content protection, the two sets of
methods could be combined if that were felt to be needed.
3. It's packaging in the body is ugly. (See #1)
Yep. And if one didn't want to tolerate ugly in order to get
more privacy, then one doesn't need the privacy enough. See
above.
For sufficiently motivated and technical individuals, it's
clear the technology is extremely useful as a discrete
capability.
However any focus on PGP or S/MIME in their current forms will
be a distraction that well might seduce the IETF community
into thinking it's doing something useful for the Internet
that actually isn't.
Because of my concerns about compromised mail system operators,
relay servers and even submission and delivery servers, plus the
vast majority of users who do not control the domains they user
for email, I could say much the same thing about all of the work
that is going on about hop-by-hop methods, especially
domain-dependent ones. But I don't feel that way: I don't think
there are any completely effective methods out there (in terms
of, e.g., protection of both envelope and content against
attackers with legal authority). So, for me, the choice is
between deploying a variety of mechanisms, understanding and
being clear about the applicability and limitations of each, and
saying things that amount to "hopeless".
All of that said, I wasn't proposing a "focus on PGP or S/MIME"
or anything like it. I was proposing a convenience and enabler
for those members of our community who felt like using those
methods or, if the techniques we have standardized are actually
defective, that we either fix them or, depending on the level of
risk, either generate Applicability Statements or deprecate the
things. Certainly having IETF standardized security-related
protocols out there that we consider unacceptable without doing
something about it is inconsistent with our claimed interest in
mitigating pervasive surveillance. And that is really all I
said.
regards,
john