[Cryptography] ratcheting DH strengths over time

[Perry E. Metzger]

On Mon, 16 Nov 2015 10:57:12 -0500 "Perry E. Metzger"
<perry at piermont.com> wrote:
> On Mon, 16 Nov 2015 00:10:09 +0000 ianG <iang at iang.org> wrote:
> > [Suggests that software should up key sizes, DH group sizes,
> > etc. automatically with time, taking the decision to do so out of
> > user hands.]
[...]
> So, I suppose my overall comment is: this is an interesting idea,
> but I suspect it will not be entirely easy to make work, especially
> in the places where it is most needed (that is, hardware being kept
> around way past the point where it should be retired.)

Oh, and an addendum: you can up your DH primes all you like, but if
the key exchange is then driving RC4 or 1DES for the actual
communications or what have you, you lose. Cryptographic protocols
like TLS depend on several moving parts -- key exchange, hashes,
symmetric ciphers, etc.

The NSA's policy seems to be that you set all of these to be more or
less of equivalent security and there's no point in having a steel
wall with a paper door, and that seems to make some sense. Keep all
your parts in balance. Another overlooked lesson from Logjam was that
one should never have allowed the use of DH primes that were "too
weak" for the chosen symmetric system in the first place -- selecting
a strong symmetric cipher should force the use of an equivalently
strong DH or EDH group. Of course, using DH primes that are much
stronger than the symmetric system in use doesn't help much
either. The attacker will go after the weakest point regardless. You
want all the parts balanced.

So, how does one automatically upgrade not only the strength of the
asymmetric subsystem but also the symmetric ciphers and hashes in use?
I'm not sure one does -- so perhaps the auto upgrade point is
moot. Perhaps you just make sure you never use a "bad mix" where the
key strengths are out of line with each other and beyond that you hope
that people aren't stupid about their engineering decisions for long
lived hardware.

Or, perhaps there's a cleverer idea possible here that I'm not seeing.

Perry
-- 
Perry E. Metzger		perry at piermont.com