RE: draft-ietf-ldapbis-authmeth-12.txt is posted

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

I believe the RFC 2829/2830 intent was to state a
mandatory-to-implement TLS cipher suite for all LDAP
StartTLS implementations.  I believe it appropriate for
[AuthMeth] to likewise.

It's my view that to change the mandatory-to-implement
TLS cipher suite for all LDAP implementations should only
be done if the present choice is known to be a poor
choice.  It is, in my opinion, inappropriate to change
the mandatory-to-implement simply because there might
now be better choices (there likely are) due to
interoperability problems any change would create
between implementations of RFC 2830 and implementations
of [AuthMeth].

At 06:43 AM 8/26/2004, Roger Harrison wrote:
>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
>-----Original Message-----
>From: owner-ietf-ldapbis@OpenLDAP.org [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Roger Harrison
>Sent: Wednesday, 25 August 2004 14:44
>To: ietf-ldapbis@OpenLDAP.org
>Subject: draft-ietf-ldapbis-authmeth-12.txt is posted
>
>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
><http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-authmeth-12.txt>http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-authmeth-12.txt.
> 
>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