On 2/1/2014 4:35 PM, John C Klensin wrote:
--On Saturday, February 01, 2014 15:34 -0800 Dave Crocker
<dhc@xxxxxxxxxxxx> 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.
Yeah, effectively it was. You suggested activities such as PGP
key-signing. My point is that that has nothing to do with providing
meaningful PM protections for the Internet.
You almost asked whether the PGP/SMIME model and algorithms were still
believed to be sufficient. That, of course, would be useful background
for meaningful technical work on PM, but that's a very focused and very
brief question and not at all the path the rest of your message went down.
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.
Being able to demonstrate that we know how to encrypt the message body
is fine, but in terms of current concerns over PM and the nature of what
needs to be done, it seems like a point working very hard for
triviality, along with being able to say that we can send data reliably.
Essential, but not noteworthy.
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
It isn't, but more significantly, it doesn't matter.
We have plenty of experience with events at the level of catastrophes
that then produced no meaningful change in operator or user behavior.
In other words, the lesson was not learned. I'll point to the study
done a year after the Morris Worm as an early example, in a far more
tech-savvy Internet operations world: No significant change in server
protection.
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;
No.
More specifically, my preferred alternative is that we focus on creating
solutions, rather than worrying about spending energy on mechanisms that
have already failed to scale.
I've more than once registered this preferred alternative generally,
which is to look at this topic in an integrated fashion, identify
system-level requirements and system-level barriers to adoption.
And since earlier this evening a private exchange prompted my fleshing
this out a bit, here's what I mean, in more detail:
1. What information needs to be protected?
"Raw payload" is the least interesting answer. Not that it's
wrong, but it's the most obvious. Saying PGP is a version of saying raw
payload. That's why I pushed back so strongly on that.
I'd expect the interesting discussion to be about
a) Describing information that is used for identity correlation
b) Packaging/header/envelope protection
c) Traffic/activity analysis protection
2. What are the broad strokes of mechanism(s) that will protect
what needs protecting?
This is somewhere between a conceptual requirements statement and a
functional spec. It's most certainly not a detailed statement. The
intent is to define the solution space, to guide the specification effort.
3. On the premise that we already have extensive experience with
all of the relevant component technologies (keys, key management,
encryption, authentication, etc., etc.) then what appears to be the
major barriers for large-scale solutions? In the realm of key
management, it well might be that we do /not/ have sufficient experience
with usable solutions.
4. How do we overcome #3?
That's probably a good, high-level start. If we make progress on these,
we will have quite a bit of guidance for detailed design efforts, or at
least experiments.
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.
When I constantly comment that the IETF needs to stay away from making
assertions that touch on usability topics, it's always nice to get such
solid demonstrations of why.
Such dismissals of mass-market adoption and use realities really does
more to show the IETF community's failings, far more than end users'.
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
Yup.
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".
You appear to be applying a constraint of having to work with what
exists. If we had sufficient solutions available that would be fine,
but we already know we don't.
So wouldn't it be really nice if there were a savvy engineering
community that might actually focus on developing /new/ techniques to
deal with PM?
Where might we look for such a group?
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
Oh. You weren't concerned with the larger Internet. You just wanted
IETF folk to feel more secure (when talking with other IETF folk?)
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
Glad to hear that we can resolve the considerable concerns about PM with
some applicability statements and no actual engineering.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net