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

From: "Roger Harrison" <[email-masked]>
Date: Thu, 26 Aug 2004 07:43:36 -0600

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" <[email-masked]> 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: [email-masked]
[mailto:[email-masked]]On Behalf Of Roger Harrison
Sent: Wednesday, 25 August 2004 14:44
To: [email-masked]
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.
 
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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 26 Aug 2004 18:10:51 -0700

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
>
>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
>From: [email-masked] [mailto:[email-masked]]On Behalf Of Roger Harrison
>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.
>