Nelson B Bolyard wrote: > Ian G wrote, On 2008-10-19 15:17: >> Nelson B Bolyard wrote: > >>> 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. > > Yes, but the users are conditioned to accept all certs upon initial > presentation.
Right. Users are trained to avoid the inconvenience of the security
model. Chernobyl style, as pointed out by Jean-Marc, they'll keep
going until something bad happens. Inconvenience isn't helpful in
this scenario, and adding more inconvenience isn't any more helpful.
So the question right now, assuming the Chernobyl thesis, is not how
inconvenient the Firefox UI can make it, but what is the bad thing
that will happen?
K showed us one possible future.
> I used to think SSH's KCM model was pretty good, until someone (it was
> You, actually) opened my eyes to the fact that users do not attempt to
> verify key correctness, do not attempt to do out-of-band verification of
> key "thumbprints" or any other reasonable verification, but instead merely
> always assume that the key they get is valid, the first time they connect
> to the server. When I learned that, I contacted many people who were SSH
> aficionados, and they all confirmed the truth of that situation that had
> been too horrible for me to even imagine until it was told to me.
I should keep my mouth shut sometimes :) But, really, it is very
important to look at how real users react. Our deep technical
experience makes us absorb and skip over things in very different
ways, which leads us to paint the world rosy. This is why I don't
bother to learn the about: thing, as it takes me away from user-land.
> So, today, I equate KCM with accepting all keys at face value, upon first
> contact. That's just what the victim in bug 460374 did. I would not say
> that it served her well.
Right. However, click-thru syndrome is the same, more or less, for
KCM and for PKI. Users just click through, both.
How it effects the different models varies, of course, but in both
cases, users will click through.
Until Armageddon (minor): you stop offering the click-thru option,
in which case they say "it's broken" and they switch away from
Firefox. Or Armageddon (major), in which case they do get in a
mess, lose their money, say "it's broken", then switch from the
Internet.
Which do you fancy, the devil or the deep blue sea?
>> If the user does not validate, then she has done a bad thing.
>
> Um, er, well, in this case, she would have done a GOOD thing, no?
Well, indeed! We wish that she would decide not to go to that site,
and that we (the browser) have correctly picked the site as evil.
Problem is, there are many possibilities:
User accepts User rejects
recommendation recommendation
Browser correctly
says the site is
evil
Browser incorrectly
says the site is
evil
Depending on our politics, we are arguing over which square we are
in. We would all like the rosy wonderful life of being in top-left.
But, because of the history of the product, we do not really find
ourselves there, but elsewhere.
The problem here is that, depending on which square we find
ourselves, the UI recommendations are radically different.
>>> 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?
>
> Yes. And the 10MB file that SSH users must now drag around containing
> all those bad keys, since there is no service to which they can turn for
> revocation help.
I don't follow that. I don't know if I am doing it. But I do have
to ssh in to a handful of debian machines ... so I'll ask at the
next tech meeting. Maybe I'm just the user! Click-click, lemme in :)
>> 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.
>
> That 10MB file that they all must drag around now is an ongoing cost
> of the solution. It's a back breaker for browsers, more than doubling
> the size of the browser download to include that file.
I guess I'm *not* doing that...
>>> I want to drive a stake through the heart of something, too.
>>> Can you guess what it is?
>
>> This one I can guess [1] :)
>> [1] but I couldn't guess the one in your essay!
>
> I'm quite curious! What would you guess instead?
You wrote:
"It's already part of the TLS standard, and in NSS. Need I name it?"
For me, there are many authentication possibilities that might
relate to TLS:
* passwords over TLS
* secureId tokens over TLS
* client certs
* smartcards
* PSK
* SRP
In approximate order of popularity. They all suck, in their
separate ways. Curiously, one of the things that we had a chance to
experiment with over at CAcert was client certificates. They
"work", but they have some very annoying security weaknesses.
>> If the user does not validate, or validates badly, then the world
>> will eventually drift to failures.
>
> And you have taught me well that users simply do not validate, but
> merely accept all server keys at face value on initial contact.
iang, the messenger!
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
