3 ms·

What about a way to sign the new key with the old key? If the host presents a new key, plus a signature from the old key which you already trusted, then your s

What about a way to sign the new key with the old key? If the host presents a new key, plus a signature from the old key which you already trusted, then your system switches to trusting the new key? I can see that there are problems in that if you don't attempt to log in between when the new key is issued and the old key expires, then you won't be able to trust the switch and will have to re-authenticate via external means. That might be a problem, but it might be easier for some groups of people to manage than figuring out a whole new CA model?

mjg59 4y ago
That's fine for orderly transitions, but if you're worried that your private host keys have been compromised then (a) you can't trust any new transitions and (b) if the new private keys are already on the systems then have they also been compromised?
- tialaramex 4y ago
  However, we don't need to have the new private keys in order to tell people about the new public keys using our old private keys. If a valid emergency private key lives in the safe, realistic bad guys (who don't do black bag jobs, they just read bug lists and act quickly) can't have that key until you put it into use. So you could have a situation where say, you schedule key replacement every 12 months, you always immediately generate and announce the next key, but it lives in the safe until the rotation happens or something goes wrong and you use it immediately.
- firstlink 4y ago
  The automatic transition would not cause additional harm in the compromise scenario and would in fact marginally help. A client which has not got an out-of-band revocation/update of the host key is subject to complete mitm'ing and impersonation either way: tricking it into accepting a new fraudulent host key doesn't actually make this scenario worse, it only means the first attacker locks out his competition :). (An out-of-band key update still fixes the client.) OTOH, if the client happens to connect to the authentic host first, then it is saved. So, no net harm, marginal net benefit.

mjg59 4y ago

That's fine for orderly transitions, but if you're worried that your private host keys have been compromised then (a) you can't trust any new transitions and (b) if the new private keys are already on the systems then have they also been compromised?

tialaramex 4y ago
However, we don't need to have the new private keys in order to tell people about the new public keys using our old private keys. If a valid emergency private key lives in the safe, realistic bad guys (who don't do black bag jobs, they just read bug lists and act quickly) can't have that key until you put it into use. So you could have a situation where say, you schedule key replacement every 12 months, you always immediately generate and announce the next key, but it lives in the safe until the rotation happens or something goes wrong and you use it immediately.
firstlink 4y ago
The automatic transition would not cause additional harm in the compromise scenario and would in fact marginally help. A client which has not got an out-of-band revocation/update of the host key is subject to complete mitm'ing and impersonation either way: tricking it into accepting a new fraudulent host key doesn't actually make this scenario worse, it only means the first attacker locks out his competition :). (An out-of-band key update still fixes the client.) OTOH, if the client happens to connect to the authentic host first, then it is saved. So, no net harm, marginal net benefit.