Ben Bucksch wrote:
On 08.01.2009 23:15, Nelson B Bolyard wrote:
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly
"me too")
Esp. because the first are from you (and are dissenting, and therefore
important, while agreeing comments are just "me too", right?).
* Require website owners to continue using the same private key.
This flies in the face of best current practices.
I think the current practices, of the whole PKI system on many levels,
are extremely bad.
Please be specific and rational in your arguments. "This is how we're
doing things so far" or "This is how this system was defined" is not
an argument.
Oh, so let's replace it with something that is definately less secure!
Allowing the same private key over an extended time is a question of CA
policy. Such allowances are already questionable *CRYPTO* (not PKI)
policy. A system that requires the same key is a non-starter. This is
crypto 101, right up there with not signing data passed to you in mass
by an attacker, or encrypting 2 different streams of data with the same
key in a stream cipher.
Certs expire for the same reason that credit cards do. Do you
understand why that is?
No, quite frankly, I do not.
First off, my credit cards (VISA, MasterCard) are valid until Jan 1,
2013.
My GPG key expires in 10 years or something, and it hasn't been any
problem. My SSH keys also never expire, and that's good. The CA root
certs don't expire for 20 years.
Several of these are problem. Debian-weak SSH keys never expire. The
risk these keys pose to PKI based apps are small and shrinking. SSH has
to depend on actively detecting those keys proactively. Those that
weren't detected slowly expire out of the system. It's the built-in
safety valve that adds robustness even with a weak revocation model.
Debian-weak SSH keys will plague the backwaters of the internet for a
long time.
If the private key on the server is secure, all is fine. If somebody
breaks into the server and the private key gets known to the attacker,
it's being revoked.
The security value of a private key degrades over time. The rate of
this effective degradation depends on the usage of the key, the
strength, etc. 10-20 years for an RSA 1024 bit key issued today is
definitely too long (independent on how it's used). A private key that's
stored on a hard drive on a machine should be treated as having a
smaller potential life than one stored in secured hardware. A key which
many potential people may have access to (including administrators) will
have a smaller potential life than one that doesn't.
Re: Revocation
Revocation in any Key system is a hard and expensive problem. PKI's have
tools and infrastructures in place to allow this, but even today it's
not really turned on everywhere.
--------------------------
There's a more fundamental problem here, though. KCM is popular among
people who "know a little security" because it puts the burden of
security in the users own hands. It makes sense. I want to control my
own destiny. The big secret is few (and I mean a lot fewer than people
think) of us are sufficiently diligent enough to use such a scheme on a
regular basis.
KCM is good for a single pipe between to fixed and seldom changing
computers, which are set up by a conscientious, knowledgeable person. In
the day to day operations it is an accident waiting to happen. I use ssh
daily. The only way I've found to keep myself honest is to use 'client
auth' to make up for the risk posed by using KCM for a many to many
connection scenario. In the many to many or the one to many case, KCM
trains the user to ignore the warning messages. Machines get reloaded
with new operating systems, events cause rekeying, I visit new machines
that I don't deal with every day. The whole burden is placed on me to
decide if I'm being attacked. 99.9% of the time I get a warning that is
benign That .1 % when it's not, I'm now trained to ignore it.... and I
know what I'm doing. I know what is going on under the covers. I keep
myself safe by never typing a password in an SSH pipe. If I can't make a
connection with a cert, it means I'm probably not connecting to the
machine I thought.
Mozilla is the same. Users are making lots of connections, often to new
sites that they have never visited before. They trash their profiles.
They reload their machines. They visit sites from their mom's computers.
Even if you could get every website to follow the (poor security)
practice of never changing their keys, you are generating so much noise
that users will ignore key change warnings.
The only use that I see of KCM is for a small community of users that
have some security training and believe that they can manage this system
themselves. For those users we have a solution today.... rm
{firefox_bin_dir}/nssckbi.dll and add each site as a security exception.
bob
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
