On Thu, June 16, 2016 14:23, Valeri Galtsev wrote:> > On Thu, June 16, 2016 1:09 pm, Gordon Messmer wrote: >> >> I doubt that most users check the dates on SSL certificates, >> unless they are familiar enough with TLS to understand that >> a shorter validity period is better for security. > > Oh, this is what he meant: Cert validity period. Though I agree > with you in general (shorter period public key is exposed smaller > chance secret key brute-force discovered),Like many things that appear to be common-sense these assumptions have no empirical basis. A properly generated RSA certificate and key of sufficient strength -- RSA k>=2048bits -- should provide protection from brute force attacks for decades if not centuries. The usual way a private key gets compromised is by theft or by tampering with its generation. Putting yourself on a hamster wheel of constant certificate generation and distribution simply increases the opportunities for key theft and tampering. Keys issued to individuals certainly should have short time limits on them. In the same way that user accounts on systems should always have a near term expiry date set. People are careless. And their motivations are subject to change. So having a guillotine date on a personal certificate makes sense from an administrative standpoint. One wants to fail safe. But modifying certificates on sealed servers?. Really, unless one has evidence of penetration and theft of the key store, what possible benefit accrues from changing secured device keys on a frequent basis? We mainly use 4096bit keys which will be secure from brute force until the advent of Quantum computing. At which point brute force attacks will become a pointless worry. Not because the existing RSA certificates and keys will withstand those attacks but because the encryption process itself will move onto quantum devices. That development, if and when it occurs, will prove more than the code breakers will ever be able to handle. Of course then one must worry about the people who build the devices. But we all have to do that already. Bought any USB devices from China recently? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrne mailto:ByrneJB at Harte-Lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
On 06/17/2016 08:19 AM, James B. Byrne wrote:> On Thu, June 16, 2016 14:23, Valeri Galtsev wrote: >> Oh, this is what he meant: Cert validity period. Though I agree >> with you in general (shorter period public key is exposed smaller >> chance secret key brute-force discovered), > Like many things that appear to be common-sense these assumptions have > no empirical basis. A properly generated RSA certificate and key of > sufficient strength -- RSA k>=2048bits -- should provide protection > from brute force attacks for decades if not centuries.Yes. The primary concern is theft, not brute forcing. I would imagine that those with the resources to brute-force keys have other ways to intercept traffic.> The usual way a > private key gets compromised is by theft or by tampering with its > generation. Putting yourself on a hamster wheel of constant > certificate generation and distribution simply increases the > opportunities for key theft and tampering.No it doesn't. If your key/cert pair exists only on the host where it is used, then access to that host is required to exfiltrate the key. If an attacker has ongoing access to a host, in order to acquire each key as it is generated, then the expiration of the keys is irrelevant with respect to the opportunities for theft. The opportunities are equal for both cases of short certificate lives and long certificate lives. There is, however, a difference if an attacker has only brief access. If you shut out an attacker who has taken your key, then a short key lifetime returns you to a secure state sooner than a long key lifetime. In fact, you have the logic of the situation entirely backward. The interaction between the opportunity for theft and the lifetime of the certificate is proportional to the remaining lifetime of the certificate at the time of the theft. And remember that theft doesn't necessarily mean the attacker has login access. A recent OpenSSL bug allowed an attacker to read portions of memory, and could be used to acquire key material.> Really, unless one has evidence of penetration and theft of > the key store, what possible benefit accrues from changing secured > device keys on a frequent basis?You aren't always going to have evidence. Be proactive.