Hubert Kario <hka...@redhat.com> writes: >also, if it really is supposed to be Long Term Support, why it doesn't say >anything about implementation explicitly being able to handle big key sizes? >both RSA and DHE?
I've deliberately avoided getting into that because it's such a rathole, you've got everything from the NIST numerologists at one extreme to the "good enough for now" folks at the other, and you'll never get any consensus because there are completely different worldviews involved. A possible median is: Implementations SHOULD choose public-key algorithm key sizes that are appropriate for the situation, weighted by the value of the information being protected, the probability of an attack, and the ability of the hardware to deal with large keys. For example a SCADA system being used to switch a ventilator on and off doesn't require anywhere near the keysize-based security of a system used to transfer classified information. One way to avoid having to use very large public keys is to switch keys periodically. This can be done by regenerating DH parameters in a background thread and rolling them over from time to time, or if this isn't possible, by pre-generating a selection of DH parameters and choosing one at random for each new handshake, or again rolling them over from time to time. >I might have missed, but where is the specification of the acceptable >signature algorithms (hash especially) on Server and Client Key Exchange >messages? That's implicit in the cipher suites, RSA or ECDSA + SHA256. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
