headers
Ed Gerck | 1 Jan 1998 01:22
Picon

Re: Weakening the rigid heirarchical trust model

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
(Continue reading)

Permalink | Reply |
headers
EKR | 1 Jan 1998 04:19

Re: Weakening the rigid heirarchical trust model

Ed Gerck <egerck <at> laser.cps.softex.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.

> -> 
> -> > ->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.
> ->
>
(Continue reading)

Permalink | Reply |
headers
Ed Gerck | 1 Jan 1998 23:45
Picon

Re: Weakening the rigid heirarchical trust model

On 31 Dec 1997, EKR wrote:

-> Ed Gerck <egerck <at> laser.cps.softex.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!

Ok, agreed. But that environment (and protocol) would not be S/MIME any
longer -- otherwise, the non-interoperability specter would appear again.

-> >[snip, already requoted] 
-> > My point was that a protocol weakness cannot be solved by hardware, no
-> > matter how controlled.
-> Yes, but a lot of the things you were complaining about (e.g.
-> bad randomness for key generation,  programs which are willing
-> to give up the key, etc.) are (1) not protocol bugs but
-> implementation bugs and (2) can be fixed by trusted hardware.
-> 

We seem to be moving in circles here because this is NOT what I had in
mind. The difference in understanding may have been caused by myself, when
I poorly explained my objection (out of a desire to be concise). My
objection was NOT to point out that S/MIME has protocol bugs, but I seeked
(Continue reading)

Permalink | Reply |
headers
EKR | 2 Jan 1998 00:31

Re: Weakening the rigid heirarchical trust model

Ed Gerck <egerck <at> laser.cps.softex.br> writes:
> On 31 Dec 1997, EKR wrote:
> 
> -> Ed Gerck <egerck <at> laser.cps.softex.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
(Continue reading)

Permalink | Reply |
headers
Ed Gerck | 2 Jan 1998 16:16
Picon

Re: Weakening the rigid heirarchical trust model

On 1 Jan 1998, EKR wrote:

-> [snip, requoted]
-> 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.
-> 

If the high-security users decide not to depend on unsafe X.509 CRLs in
order to decide if a cert is valid (eg, supose they would use a type of
Kerberos tickets) or if the high-security users decide to use PGP and
X.509 then they would already be non-S/MIME for all practical purposes,
even though they could be both talking MIME.

Thus, what I was calling interoperability is not a MIME-interoperability,
but a S/MIME interoperability. In other words, high-security users will in
general differ from low-security users in more predicates than just
different policies or different root-keys for each user, but in the
protocols for each user. What you mentioned is not that, but a case in
which the protocol is still S/MIME for both users (thus, compatible)  but
the reference frames are incompatible with each other. This case I would
consider not a case of lack of interoperation but simply to be out of
tune. Please note that what I had in mind was a true protocol difference
which cannot be solved by any possible change (or tuning) of parameters.

-> I'd observe that S/MIME already has the capability to produce
(Continue reading)

Permalink | Reply |

Gmane