Nelson B Bolyard wrote:
> Ian G wrote, On 2008-10-19 05:09:
>> Ian G wrote:
>>> Nelson B Bolyard wrote:
>>>> KCM would not have helped.
>>> I agree, KCM would not have helped.  In both cases, the warnings are
>>> delivered, and the user is given the responsibility for the overrides.
>> I was thinking about this, and actually, KCM would have helped here.
> No, it couldn't have.  In fact, it could have been hurtful.
>> If you look at the two cert viewers side by side, then there is a
>> clear difference:
>> Now, this info and the difference is available to the browser, which
>> operating in KCM mode.  It would be an easy thing to display the two
>> certs, and the differences highlighted, perhaps in red or somesuch.
> This was a brand new installation.  Formatted hard drive, reinstalled OS,
> installed browser.  FIRST contact with every https site produced the
> self-signed cert warning.  There simply were no other certs with which
> to compare.

Lol... Yes, you are right, I missed that completely.  KCM can not
use the user's original validation if there was none before.

(I commented on the bug about where our views diverge so I won't
repeat that here.)

>  KCM would have accepted those certs without any complaint.

Ahhh, not exactly!  With KCM, it is not up to it to accept any certs
any time:  unfamiliar certs are passed up to the user for validation.

If the user does not validate, then she has done a bad thing.  Yes,
KCM would be at its weakest at that point, but no software tool is
perfect;  at some stage we have to ask the user, and then by
definition the software is weak, dependent on the user.

> THEN, later, if and when she came upon the REAL server certs from the
> real server, KCM would have warned her away!  It would have said
> "Wait, don't trust this new cert!"

Right, that too !

Although, what I suggested above is a little better than disaster in
this scenario.  It would have presented her both certificates.  If
she had marked the self-signed one as "good" and then noticed that
the new CA-signed "bad" one is superior because it has a brand name
sig on it, this better info displayed would still have given her
enough to deal with her "upgrade" attack.

> And don't forget the Debian key generator.  It showed us that a serious
> flaw in KCM is the complete lack of any revocation mechanism.

Not sure about that one?  Do you mean all the SSH servers that were
exposed to compromise because of the Debian OpenSSL random snafu?

Sure, but the comparison is of chalk and cheese.  In practice, the
SSH community takes what it is given for free, and wouldn't trade
that for all the revocation in the world.  Even the nice low $$$
cost of a Startcom cert -- free! -- isn't going to wrest them away
from their precious KCM, and for good reason:  for that particular
application, revocation isn't worth the costs that it would add to
the solution.

(Funnily enough, I used telnet with SSL support for a year or so
back in 1995 :)

> I want to drive a stake through the heart of something, too.
> Can you guess what it is?

This one I can guess [1] :)

However, bear in mind that KCM still requires:  the user has to
validate the first time.  If the user does not validate, then we
have a potential problem.

Compare and contrast:  CA-signed models ask the user to validate
when the certificates don't make sense to the algorithms.

If the user does not validate, or validates badly, then the world
will eventually drift to failures.

Assuming that there is a requirement to validate, built into the
system, then no tool can protect against a failure to validate.
It's part of the system.


[1] but I couldn't guess the one in your essay!

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

dev-tech-crypto mailing list

Reply via email to