On 31 Dec 1997, EKR wrote:
-> [snip, already requoted]
-> That doesn't mean that S/MIME can't be used for high security
-> purposes. It merely means that it can be used in situations where
-> those requirements aren't met as well. On the other hand, if you
-> want to meet requirements like that, you can do so using S/MIME.
While it is true that the laissez-faire philosophy can be very disastrous
when applied to security protocols and indeed S/MIME is managing to steer
away from open statements, we must also not interpolate lines when we read
the protocol specs -- especially when I understand by the above that you
intend to say to non-cryptographers (ie, the public at large) that the
protocol can be used for high security purposes (such as for banking or
company-critical messages). I prefer Paul's assesment, when he wrote about
S/MIME: "This is a mail spec, not a banking spec.", in this thread.
By allowing low-security procedures to be 100% S/MIME compliant, you must
agree that an application that is 100% S/MIME compliant does not say more
than guaranteeing that low-security level -- which defines its security
level for the public. A member of a class must be defined by the class's
properties, no?
On the other hand, if you still want to imagine a situation where two
applications are equally 100% S/MIME compliant while one offers a higher
security level, then you must also agree that these two applications are
incompatible in that high-security level -- though both are S/MIME
compliant, which would be a contradiction by itself *if* S/MIME would be a
high-security protocol. After all, the primary purpose of a standard is to
guarantee interoperability -- which would be utterly destroyed in your
example. This is not the case and S/MIME must guarantee interoperation at
its intended security level -- which is whatever the standard mandates by
its MUST and MUST NOT clauses.
The bottom line is that S/MIME aims at a security level which is not
critical, while it can be perfectly operational for the bulk use of the
Internet today. A honest and correct appraisal of this fact must be more
useful than snake-oil, here too.
->
-> > ->S/MIME the protocol is perfectly usable in
-> > -> high security situations. As always, the implementation has to
-> > -> be secure. (Incidentally, all the security holes you mention with
-> > -> the exception of self-signed certs are easily solved by using a
-> > -> secure hardware token for one's own private keying material.)
-> >
-> > I must again disagree. It is a common misconception that a third-party
-> > manufactured hardware token would magically infuse trust into the final
-> > result of a cryptographic calculation. As we know, trapdoors can be easily
-> > inserted into the calculation of keys or signatures, arguably more
-> > stealthly in a hardware token with concealed and secret source code.
->
-> This misses the point entirely. I'm not suggesting that a hardware
-> is a magic bullet. I'm merely observing that suitably designed
-> hardware tokens (of which several are available) can solve the
-> implementation problems you were complaining about. In fact,
-> hardware is quite a common requirement in certain environments
-> for precisely that reason.
->
My point was that a protocol weakness cannot be solved by hardware, no
matter how controlled. The points I complained about (a few, from a larger
list) cannot be solved for the average international user (non-US) by a
hardware token either, mainly because: (i) cost, (ii) export controls,
(iii) the current servers do NOT let you do that for S/MIME, (iv) the
current export-version browsers do NOT let you do that for S/MIME, (v)
the CAs do NOT let you do that for S/MIME, (vi) there are serious
questions on possible cryptographic proofs that you actually signed the
message and which message was signed if you lose or destroy your hardware
token, (vii) the datestamp and clock synchronization questions, (viii)
fairness of the hardware token, etc.
Of course, going further in this Gedankenexperiment, if (instead of
keeping to its turf) an Internet protocol requires the use of a special
and expensive hardware token in order to cope with added security
promises, then ... we may count several additional benefits, such as: (i)
adding a secondary market, (ii) restricting access to export-controlled
technology (read, restricting access to higher security) in a much better
way, (iv) adding buzzword "smart" devices, etc.
Here, if we pursue it even further, we see that the 40-bit limitation of
S/MIME may be even dwarfed by this issue, were S/MIME to make the claim it
is a high-security protocol when used with hardware tokens.
<clarification>
As we can see around us, the Internet is not any longer a parochial
network. Competing businesses, competing countries and competing economic
blocks are present in the Internet. Recently, a world renowned and
respected car manufacturer was found guilty and fined US$ 1.1 billion
because of industrial espionage on another world renowned and respected
car manufacturer. The companies: GM and VW (guilty). The surprise: VW
publicly declared (previously) that the information had already saved it
US$ 500 million in a few months (so, the fine was not excessive after all
and may have been less than the benefit). The conclusion: we live in a
"hostile" environment where the Internet is no exception, even when
household and "trusted" names are involved, because it pays off.
The information leverage is such today that one person (from GM to VW)
could cause a damage of more than one billion dollars in less than one
year.
Thus, information gathered from e-mail can mean a large leveraged bounty
to an eavesdroper on the Internet -- even among well-known and otherwise
respected companies. So, in the same way that S/MIME does not aim to allow
a security level suitable to a bank, it is also not suitable for critical
messages such as highly-competitive corporate e-mail information
(finances, engineering, patents, liabilities, employee records, sales,
marketing, etc.) because even small bits of information may be
detrimentaly used nowadays for a large effect in a leveraged competitive
context.
</clarification>
-> That said, the issue of trapdoors is a red herring. Ultimately
-> you have to trust your vendor not to intentionally compromise your
-> security--or do it all yourself. Read "Reflections On Trusting Trust"
-> for an example that makes this point quite clearly.
First, "not intentionally compromised" is difficult to disprove,
especially when you bear the burden of proof in a tamper-proof device, no?
(Further, as you may remember from the case of Stac vs Microsoft, Stac
proved by reverse assembly of MS's code that DoubleSpace used substantial
code from Stac, but Stac was also found guilty of "invading" MS's code.)
Second, as above, no vendors or third-parties can be trusted in today's
competitive environment-- not even Volkswagen vis-a-vis General Motors.
What the international Internet community needs is not some immaterial
trust on a foreign government or company or, even, on a domestic
government or company -- but open knowledge and fail-safe procedures.
After all, if trust would be such a safe "blank check" then the whole
issue of key-escrow, TTP legislation and CAs would be moot.
BTW, "Trusting Trust" reflects the wrong assumption that trust is
transitive -- which it is not. You can only really trust in first order --
if you trust your brother this does not mean that you must trust your
brother's friends (e.g., trusting his trust). This is a common
misconception when understanding PGP, because PGP does not allow trust to
be transitive (thus, the maximum depth of a Web of Trust is one when
signing certs and could never be seven as postulated recently here in an
anti-PGP example by Phillip, which also invalidates his example).
<reference>
Trust can be modelled as given in http://mcg.org.br/trustprop.txt which
allows one to view trust as a transformation. With this model, it is
possible to consider trust as it may depend on each of its attributes
(transitive, distributive, symmetric), domains, agents and, time (yes,
trust is not a time-invariant property either). Thus, direct or "hard"
trust would be modeled as (t=0,d=0,s=0) for totally nontransitive,
nondistributive, and nonsymmetric, whereas "soft" trust would allow
nonzero values for (t,d,s) -- albeit with a corresponding decrease in
trust transfer when correlating between different agents, events, etc.
</reference>
Cheers,
Ed
______________________________________________________________________
Dr.rer.nat. E. Gerck
egerck(_at_)novaware(_dot_)cps(_dot_)softex(_dot_)br
http://novaware.cps.softex.br
--- Visit the Meta-Certificate Group at http://mcg.org.br ---