Hi Robert,
thanks for the reply.
I think there are two major misconceptions, at least one of them my fault:
* I am not proposing to mandate that the private key stays the same
(contrary to what my original bullet list said). I am merely
proposing that the new key is signed by the old one, to authorize
the new one by the owner.
* I am not proposing to get rid of CAs, not proposing an SSH model.
KCM is in *addition* to current requirements.
Most of the discussion below can be explained with that.
On 09.01.2009 02:10, Robert Relyea wrote:
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
I hope to see some reasons for that bold statement below, as most crypto
systems which are considered very secure use long-lasting or not
expiring keys.
That includes both SSH and PGP, which are both widely considered very
secure when fingerprints are verified correctly. The CAs are not a
threat to the security of *existing* relationships. This vector is
exactly what we propose to remove.
All the rest stays the same.
Note that I later said that the keys *can* be changed, if you consider
that better. The old one merely needs to sign the new one, to ensure
continuity.
Debian-weak SSH keys never expire. The risk these keys pose to PKI
based apps are small and shrinking.
Yes, that was a major screw-up.
However, fixing it is not a major problem for a responsible admin - he'd
just replace them. I don't think I was affected, but I changed the keys
of the systems which might have been affected anyways.
Also, the CA still can revoke the keys, even with this proposal.
(I think the fact that the CAs didn't do that was also a major screw-up
on their part. Any admin which didn't exchange the key himself would
quickly have noticed and replaced the cert. When waiting for expiry,
they were vulnerable for a year and didn't notice it.)
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).
Sure. You're very welcome to replace the key in 5 years, when it's time
to do so.
--------------------------
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.
Exactly.
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.
(Note: You're speaking of a KCM system without CA and without key
verification on first sight in practice. That's not the proposal here.)
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....
FWIW:
I use SSH only for a few third-party machines, including the Mozilla CVS
and hg servers. When/If the key changed there, I asked or even filed bugs.
I use SSH mostly for my own machines, and I didn't have unexplainable
key changes so far. And the keys of machines at home are of course
exchanged at first sight by a direct wire inside my home. And I know
that if there is no way (apart from software bugs) for a third party
like a CA to introduce himself between me and my machines without an
alert (which I never had). That combination (and some trust in the
openbsd/openssh team and open source in general) makes me fairly
confident in the system. I can't have that confidence in solely
PKI-based systems, because I get no warning (or lots of spurious
warnings) in the same situation. That's why I propose to *add* KCM in
addition to PKI.
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.
We all are less competent than we think, esp. in security, yes.
(I'm *not* pointing to you.)
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.
There would be no warning when the user first encounters a host with a
cert and he's never seen the host (as far as the profile goes) - we rely
on CAs as we currently do for the first connection. Only on the second
connection, the KCM kicks in and verifies that it's the same key, or the
new key is signed by the old key, the old one authorizing the new one
(if you prefer to change private keys, which is fine). So, in normal
scenario, there are no warnings for users, and we lose no security that
we currently have. We only add restrictions, namely that the admin signs
the new key with the old one. (I hope I explained in previous posts what
that is good for.)
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
