Jonathon and others,
I for one view this IETF forum as narrowly technical. But I think this
debate is raising issues that threaten the integrity of the process,
so a fullsome and noisy debate on open-pgp is unavoidable. Hence I am
responding in a political fashion where otherwise I wouldn't.
For those that dissagree - stop reading now, and apologies for the length.
To declare my colours at this early point, I have read some, hopefully
enough, of the posts on the subject and I think PGP 5.5 CMR features are
a bad design from the privacy point of view. For that reason I hope to
concentrate any IETF open-pgp debate on the narrow issue of whether to
accomodate these new features.
Jonathan Seybold wrote:
Adam, one aspect of your suggestion puzzles me:
One thing which concerns me most is KNOWING when a message I send
(or receive) could be read by someone else. The PGP CMR scheme makes this
very clear: if there is an extra CMR key, the message may be read by
whomever controls that key, if not, only the recipient may decrypt the
message.
If, however, the message is secretly re-encrypted to a corporate
storage key AFTER it is received, I will never know that.
If I send you a message, encrypted to your key, then I know that only
your key can be used to decrypt it. This is like saying, if I send you
a fax, then only your fax machine can print it out (ignoring line snoops).
Whoever has your key can read the encrypted message - hence, CAK.
Or, whoever has your fax machine can see your incoming faxes. Hence
all-powerful mailroom employees.
Whoever acquires the cleartext from whoever decrypted the message has
the message - hence CMR. And common policies to take a corporate copy
of all incoming and outgoing faxes.
I know that I have no control over what you do with that message, be it
pass it to the recovery entity or destroy it.
If you are receiving a message in a corporate context, then I always
know there is a reasonable risk of a corporate storage requirement for
any message I send. As I cannot audit the processes of your corporate
operation, I have no easy way of turning that risk into a fact.
Adding a CMR key adds no real information to this. It was always a risk
that you would share your assets - keys or messages - and now the risk
is somewhat solidified, but not much. The same goes for any fax or mail
item, and any phone call. You can share the information, or not. The
corporate body can listen in, open mail, take copies of faxes, or not.
What PGP 5.5 could have done was added facilities to CC outgoing messages
to a CMR, and to forward incoming ones. At the client level. This is,
IMHO, legitimate data storage, under the control of the user, who is
*always* capable of subverting central controls, or of disregarding any
well-meaning advice embedded within the super-privacy of PGP 2.6.
To add a central point of control to *enforce* some policy is to
misunderstand the processes of the modern office and the behaviour
of modern information workers. Notwithstanding the efforts of PGP
to address real corporate concerns, I cannot avoid thinking that the
introduction of central policy servers is definately dangerous from
a strategic point of view and probably misdirected from a technical
point of view.
The reality is that:
1) Organizations have a legitimate need to recover information.
I would accept this as a reasonable working premise, within some unstated
caveats. I think most people in this debate do accept this.
However, the existance of this need does not automatically justify
any desired attempt to meet this need, much less any given policy or
practice. LEOs are often cited as having a legitimate need to search
for information. This need does not generally justify them meeting
their needs in whatever way they see fit. Sometimes we just say no.
That is to say, a 'need' does not change snooping into good behaviour.
To implement some attempt to meet the need of corporates to recover
information requires a sensitivity to many different issues.
You
can argue about this as much as you want. A great many organizations will
simply NOT INSTALL systems which do not accommodate this. If businesses,
law firms and many other organizations will not use PGP, we will not have a
viable standard.
This may be to confuse principles of privacy with methods for corporate
data recovery with the market objectives of PGP. Such a posture is
not really helpful.
We need to find ways to satisfy this need which are as
flexible as possible, which are easy to use and administer, which balance
the rights of the individual against those of the organization, and which
do not mislead people inside OR OUTSIDE of the organization.
This means, I believe, that they should NEVER INVOLVE HIDDEN BACK
DOORS THAT USERS ARE NOT AWARE OF.
( Uh, sorry, uppercase is normally indicative of shouting. )
It also means, I believe, that we should provide systems which
provide as much flexibility and granularity as possible, and which do not
require a central key recovery infrastructure -- or, even worse, a
"trusted" third party key recovery infrastructure.
Not requiring these things is good. There are many other dangers - it
has often been pointed out that security software is difficult because
the attacker only has to find one weakness, whilst the developer has to
cover all modes of failure.
In analogous sense, those that support GAK need only find one way to
acquire the messages they want. Putting in a system that supports
corporate message recovery whilst opposing other uses is no easy task.
Some very experienced people have analysed the PGP 5.5 system and found
it wanting. These are people who have been working with complex security
systems for many years. I am somewhat concerned that their central
points are going unanswered, and for this reason I want to understand
very clearly what this forum - open-pgp - intends to do concerning
these proposed new "features."
2) Handling privileges, access and policies is going to get very
sophisticated and very complicated.
Yes, I too can see difficulties in the PGP 5.5 scheme that relate to
policy.
The keys need to be flexible enough to contain the kinds of
information people are going to want to put in them. But I believe that
most of the agents which make use of this information will operate at the
server level, not the client level.
I would advise *not* adding any of these key features into the first
working draft produced by this forum. Stick to PGP 5.0. This forum
is a standards forum, not a development forum, and necessarily follows
behind any practice in the field, especially when there is a hint of
contention.
PGP Inc. has tried to work through these issues in a new way. I think that
we have agonized through a lot of trade-offs and come up with something
that will really work -- and work well.
I would humbly suggest that the market might be a better determinate of
workability, and the vibes have not been favourable. I would hope that
the open-pgp forum can concentrate on the basic formats and avoid including
any contentious features such as those present in PGP 5.5, at least until
the market and the security analysts on the various security groups have
come to some good understanding as to their desireability.
[...]
I am very interested in seeing criticism and suggestions for
improvement and would like to see this discussed and debated as openly as
possible.
This is an issue. PGP Inc. has released a product that does something
that is not respected by some vocal critics. I wonder how debate in an
open fashion is to be handled at this point?
There appears to be only one decision - whether the IETF forum should
take on board these features as being proposed or not.
In particular, I would be interested in how one could reconcile
your scheme of separate transmission and storage keys with my concern that
everyone party to an exchange always be informed about who might be able to
read that exchange.
That's already covered, see above.
For the record - any email exchanged with me might be sent to
friends I elect to send it to. I, or my employer, may elect to
impose a secret corporate message recovery system. I may elect
to send your messages to an unfriendly government, without your
knowing. No version of PGP is going to stop me.
The only choice you have left is whether you wish to favour me by
an exchange of messages.
However, I think that some of this discussion should be separated from the
Open PGP discussion. NO ONE wants to build any sort of mandatory message
recovery scheme into the base Open PGP specification. PGP Inc itself is
committed to always providing a base client software product which does not
implement message recovery keys.
In the end, the issue we need to focus on is what should go into the Open
PGP specification. There are going to be many different organizations
(including PGP Inc.) which build different implementations and services on
top of this.
This is the current issue. In fact this is a burning issue - we need to
get this spec out there to immunise the world against any outbreak of GAK
from wheresoever it derives.
The key structure needs to be flexible enough to accommodate all
kinds of uses we cannot now envisage. Yes, I believe that CMR keys should
be supported -- as should a lot of other things we need to talk about.
I believe that the first draft - as being worked on by some - should
strictly conform to the PGP 5.0 (that's five point zero) with *no*
inclusion of any sensitive features. CMR key should not be supported,
insofar as they are anything more than additional keys, which is
something that is supported in all popular PGP variants - 2.6 through
to 5.0. ( Here I am guessing that this is what 5.0 does. )
This is even to the extent that the security enforcer of PGP Inc. might
be deemed non-conformant because it refuses correct messages. So be it.
This forum is not here for the narrow purposes of matching PGP Inc. product
releases.
If anyone wishes to propose features that might or might not make
the CMR or GAK mission easier, then it should be proposed only as
modifications to the first draft - here I am assuming this is possible.
I say this because I believe that team producing the draft spec (who
are you, BTW?) should *not* be distracted by the current debate, which
is likely to need far greater analysis and much more time.
Also, no open forum of this nature should be dependant on the product
line of of PGP Inc. or any other commercial organisation.
Finally, let's dispense with the non-productive PGP Inc- bashing. We
founded this company to take something which was going to die because it
had no company behind it, and push it forward. PGP Inc was the first step
in that process. Open PGP is the next step.
The issue is not the "bashing of PGP Inc." but the bashing of the design
in PGP 5.5. If some of the mud sticks, then so be it - PGP Inc. designed
this system, using some internal review process. An external review
process was always to be expected.
I also have to strongly disagree with the implication that the founding
of PGP Inc was needed for some sort of a revival of a moribund format.
That sort of sales message is out of place here, and offensive to the
many hundreds (and I mean hundreds) of independant developers of PGP
core code and PGP products around the world who are not currently on
the payroll of PGP Inc.
PGP - the international defacto standard - was quietly building up a
user base that, last I heard, was in the order of a few million. That
isn't something that "was going to die" through lack of attention. This
was a user base that was surviving and growing even in the face of such
alternatives as the commercially supported S/MIME and other mailer
crippleware.
I grant that PGP development was quiet for a number of years, apparently
advancing little because of two factors: the PRZ harrassment case and
the international development of PGP 3.0 that was conducted in what might
have been well-meaning secrecy, but was eventually counterproductive.
PGP was not "going to die," it simply needed some leadership or opening up.
I concede that there was a need for an effort that could lead PGP on, and
PGP Inc., with the authority that Phil lends, could fill that role. So could
many other potential models, and it is not clear that PGP Inc. have yet
earned any rights to that role, burnt midnight oil and fine efforts by
many programmers notwithstanding.
Most companies are very ambivalent about "open" standards. Most of
the time, "open" to them means something which they control and everyone
else adheres to. PGP Inc, on the other hand, is very committed to the
spirit of open standards. We understand very well that we will only be
successful if there is an open and completely interoperable international
standard.
I also want to assure you that all of the things we do get
extensively debated within PGP. Thus far, we have always been able to work
out consensus decisions which, I believe, are more sophisticated and better
thought-out for that debate. In all of this I have never heard ANYONE at
PGP Inc. suggest that the company add any feature or capability to the
software in order to appease any government agency. GAK is just as scary to
us as it is to you.
I wonder if PGP Inc. has made a mistake in conducting the review
of CMR design within the internal body, and not tapping into the
millenia of combined security experience out on the mailgroups?
Or maybe the difficulty lies in the committed approach of the
company to the design of the product - without any thought that
the market will find it wanting. There is no real shame in going
out with a beta that has a range of features to try out - although
certainly with the vitriolic crypto market one needs to be very careful
not to upset the various participants. This is a market where ones
corporate mindset needs to be more than normally flexible.
Certainly a committment to open standards means that any review
process is best conducted in an appropriate open forum, perhaps before
committing any new features to launch. At the best, products will be
criticised by the community, at worst, these products may be deemed
non-conformant to the Open PGP standard, if released without regard to
the various stakeholders.
This of course raises another interesting debate: has anyone considered
the ramifications of what will happen if the IETF Open PGP forum declares
that a product of PGP Inc. is non-conformant? If indeed there is a
difference of technical standards, does the brand of PGP remain with the
open forum or with the company? Knowing what value a good brand and a
nice company name is, I wonder if these are questions now on the table,
given the possibility, however remote, that determination of conformance
or otherwise is an open forum issue.
Of course, PGP Inc. would probably think that the brand is worth more
in their hands, I imagine that it is their decision and theirs alone
to discuss it. This would raise the issue of developing another name
for the international standard, so that conformance to that standard
would allow some differentiation between the two entities.
Nor has there ever been any any "shareholder pressure" for any
feature or set of features. Everyone who has invested in this company knows
what we stand for.
That's good to hear. There is however an uncomfortable dillema between
making money by being first to market with a PGP for business, and
maintaining that which the PGP spirit stands for. Being first to
market means compromises in all directions. Unfortunately complexities
within the security and crypto world mean that such compromises,
normally fair practice for other companies, are not often so easy to
accept nor so quick to reward.
Jonathan Seybold
Chairman, PGP Inc.
BTW: PGP Inc. currently employs NO "PR flaks." Press releases are usually
drafted by the people directly involved in the product or project and
reviewed informally by anyone else who would like to contribute.
Fine, I think PGP Inc. is also benefiting from a certain amount of
understanding because of this. You are not hearing a universal cry
of "burn the witch" or "snake-oil" yet. This is serious debate by
committed stakeholders to the PGP format.
--
iang
iang(_at_)systemics(_dot_)com