Re: authmeth TLS ciphersuites
"Roger Harrison" <[email protected]> Tue, 07 Feb 2006 11:43:53 -0700
| Newsgroups | gmane.ietf.ldapbis |
|---|---|
| Message-ID | <[email protected]> |
This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5072F679.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I am fine with the suggested new text. Roger >>> "Kurt D. Zeilenga" <[email protected]> 2/7/2006 11:23:38 am >>> The IESG raised some concerns regarding the WG's choice of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA as LDAP's mandatory-to-implement TLS ciphersuite. It was noted that the TLS 1.1 specification requires TLS_RSA_WITH_3DES_EDE_CBC_SHA where the application protocol doesn't explicitly state a different mandatory-to-implement TLS ciphersuite. For this and likely other reasons, TLS_RSA_WITH_3DES_EDE_CBC_SHA appears to more widely supported in TLS implementations. In subsequent discussions, it was noted that TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA support is new to some LDAP implementations. I noted that the choice was made many years ago by LDAPEXT WG during the engineering RFC 2830. The IETF had IPR concerns with RSA-based ciphersuites. These concerns appear to evaporated with the expiration of certain patents and time. Please consider whether the text: Implementations supporting TLS MUST support the TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite. should be replaced with: Implementations supporting TLS MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the latter ciphersuite is recommended to encourage interoperability with implementations conforming to earlier LDAP StartTLS specifications. or otherwise modified (if so, please state how). Please comment as soon as possible. It is hoped that direction can be given to the Editor later this week. Kurt, LDAPbis co-chair --=__Part5072F679.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=windows-1252"> <META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD> <BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma"> <DIV>I am fine with the suggested new text.</DIV> <DIV> </DIV> <DIV>Roger<BR><BR>>>> "Kurt D. Zeilenga" <[email protected]> 2/7/2006 11:23:38 am >>><BR>The IESG raised some concerns regarding the WG's choice<BR>of TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA as LDAP's<BR>mandatory-to-implement TLS ciphersuite. It<BR>was noted that the TLS 1.1 specification requires<BR>TLS_RSA_WITH_3DES_EDE_CBC_SHA where the application<BR>protocol doesn't explicitly state a different<BR>mandatory-to-implement TLS ciphersuite. For this<BR>and likely other reasons, TLS_RSA_WITH_3DES_EDE_CBC_SHA<BR>appears to more widely supported in TLS implementations.<BR>In subsequent discussions, it was noted that TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA support is new<BR>to some LDAP implementations.<BR><BR>I noted that the choice was made many years ago<BR>by LDAPEXT WG during the engineering RFC 2830. The IETF<BR>had IPR concerns with RSA-based ciphersuit es. These<BR>concerns appear to evaporated with the expiration of<BR>certain patent! s and time.<BR><BR>Please consider whether the text:<BR> Implementations supporting TLS MUST support the<BR> TLS_DHE_DSS_WITH_3DES_EBE_CBC_SHA ciphersuite.<BR><BR>should be replaced with:<BR> Implementations supporting TLS MUST support the<BR> TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and<BR> SHOULD support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA<BR> ciphersuite. Support for the latter ciphersuite<BR> is recommended to encourage interoperability with<BR> implementations conforming to earlier LDAP<BR> StartTLS specifications.<BR><BR>or otherwise modified (if so, please state how).<BR><BR>Please comment as soon as possible. It is hoped that<BR>direction can be given to the Editor later this week.<BR> <BR>Kurt, LDAPbis co-chair<BR><BR><BR><BR><BR><BR><BR><BR><BR ></DIV></BODY></HTML> --=__Part5072F679.0__=--