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
I'm not sure why an I-D announcement hasn't been sent out, but
draft-ietf-ldapbis-authmeth-12.txt is now posted at
This version of the draft is essentially ready for WG last call. Please
review it and give me your comments in the next 1-2 weeks. I expect to post
a version ready for WG last call shortly after this period passes based on
your feedback.
Changes for draft-ldapbis-authmeth-12
General
- Changed refererences from Start
TLS to StartTLS.
- Removed Appendix B: Example
Deployment Scenarios
- Removed Appendix H as all
issues listed in the appendix are
now
resolved.
Section 2
- Added implementation requirement
that server implementations
that
SUPPORT StartTLS MUST support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
Section
3.1.2
- Added wording clarifying that a
client's association is
unaffected
if a non-success resultCode is returned in
the
StartTLS
response.
Section 9.2
-
Final paragraph of this section details requirements
for
serverSaslCreds field when no
challenge value is sent.
Section
10
- Clarified language on uAuthzID
usage.
Section 12
-
Moved entire section into security considerations. New
section
number is
12.1.1.
- Reorganized security considerations by
topic.
- Added several security considerations
based on WG feedback.
Section
13
- Moved section to become section 3.3.
--Roger