|
This is an excellent question and one for which I'm not sure I have a complete answer. This is certainly not a new requirement, just an long-existing requirement moved to a more visible location. The text requiring support of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA for all implementations that support StartTLS has been present in the authmeth draft since at least the -05 revision (March 2003).
The original text in RFC2829 was: "A client or server that support s TLS MUST support at least TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA."
This seems to imply that a minimum cipher strength was the intent rather than specifying a mandatory-to-implement cipher suite that would guarantee interoperability.
I guess the question really comes down to this: must TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA be required to ensure interoperability, or can we simply specify a cipher that is minimally acceptable in terms of its security properties and allow implementers to choose something stronger if they desire?
Roger
>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 8/24/2004 10:56:04 PM >>> Why is it necessary to support TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA? Surely DSS certificates are thin on the ground? And wasn't the original reason for favouring DSS ciphersuites the fact that RSA was emcumbered, and isn't this no longer the case?
Ron
|