Ed Gerck <egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br> writes:
On 31 Dec 1997, EKR wrote:
-> Ed Gerck <egerck(_at_)laser(_dot_)cps(_dot_)softex(_dot_)br> writes:
-> > 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.
-> I absolutely agree. I was simply observing that it's quite possible
-> to create a profile of S/MIME that is usable in a high security
-> environment.
->
First of all, a Happy New Year!
Indeed.
Ok, agreed. But that environment (and protocol) would not be S/MIME any
longer -- otherwise, the non-interoperability specter would appear again.
I agree with the second part of this statement but not the first.
If you desire to have a secure environment, you can't place trust
in entities which don't take similar security measures. So, true,
high security S/MIME users won't interoperate with low security
S/MIME users -- in the sense that the high security users (by policy)
don't trust the low security users. That doesn't mean that they're
not both speaking S/MIME any more than the fact that the NSA won't
tell me classified information means we don't both speak English.
I'd observe that S/MIME already has the capability to produce
noninteroperability because of different security requirements,
simply because different users may choose to have different
lists of root keys.
Thus, what I also observed was simply that you can't push S/MIME beyond
the specs and there would no gain in pushing for stricter procedures than
needed. To exemplify, I provided examples of application behaviors which
are NOT defined in the S/MIME specs and which may cause problems in a
higher-security environment as a function of the implementation, even
though the application is 100% S/MIME compliant and perfectly acceptable
in a lower-security environment.
Therefore, these security concerns cannot be considered as implementation
bugs of a spec -- because the specs are moot on that. Rather, they reflect
implementation freedom allowed by the specs. Of course, if you get an
out-of-the-box S/MIME application you may rightly expect it to conform to
the S/MIME standard -- targeting a pre-defined security level for which
the concerns I exemplified are simply non-existent.
Now, if we agree that the problems I exemplified (out of a larger list)
are not in the S/MIME wish-list then we must also agree that they are
neither protocol bugs nor implementation bugs. They are just features that
someone may need but will NOT find in S/MIME -- by design.
To further clarify the issue (and following your numbers above):
(1) No, the examples I supplied reflect neither protocol bugs nor
implementation bugs in S/MIME, because they belong to a security class
beyond the S/MIME specs. In such a higher-security reference frame, they
may be called protocol weaknesses in S/MIME and just reflect the fact that
you are using a tool beyond its design assumptions. This does not impair
the use of S/MIME for the bulk of Internet e-mail messages, for which it
is obviously designed.
(2) Such protocol weaknesses cannot be solved by a "band-aid" type
solution with some sort of hardware that carries some amount of trust,
because a system is usually as strong as its weakest part. In the open
environment of the Internet, it is very risky to consider that the
solution of a protocol weakness would be guaranteed by a hardware
limitation.
I think I see what you're saying, but I disagree with the conclusion.
S/MIME is a messaging spec. In and of itself, however, it's not a
specification for a complete system. I don't consider this to be a
weakness. It's simply out of scope. But, I guess this is pretty much
a philosophical issue.
I read the article some time ago and enjoyed it, because even though I
entirely agree with its line of thought I also entirely disagree with its
main conclusion: "You can't trust code that you did not totally create
yourself." (But, discussing this would certainly be off-topic -- however,
I would gladly explain my reasonings privately though).
Fair enough. I think this is at the root of our disagreement wrt
trapdoors.
-Ekr
--
[Eric Rescorla Terisa Systems, Inc.]
"Put it in the top slot."