[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] TLS & SSL ciphersuite language
I think we should look to the future instead of the past. I suggest AES as the mandatory to implement symmetric algorithm. Specifically: TLS_RSA_WITH_AES_128_CBC_SHA This is described here: http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-05.txt I believe that the IETF Security Working Group has stated the intent to move to AES as quickly as possible. Considering that performance is the most commonly cited reason for NOT USING ENCRYPTION AT ALL, why not move to an algorithm that is six times as fast as 3DES? Hal > -----Original Message----- > From: Jeff Hodges [mailto:jhodges@oblix.com] > Sent: Friday, November 16, 2001 5:10 PM > To: oasis sstc > Subject: [security-services] TLS & SSL ciphersuite language > > > At F2F #5 I took the action to research language other specs > use in expressing > requirements for support of TLS/SSL ciphersuites, as well as security > considerations of various ciphersuites. > > The RFC that most thoroughly explains security considerations > of various > subsets of TLS ciphersuites is RFC2829 (Section 10; see below). > > In terms of mandatory-to-implement ciphersuites, these five > RFCs are the ones I > could find (via grepping for "TLS_") that explicitly state a > MTI for a TLS > ciphersuite.. > > RFC2246 - TLS v1.0 > RFC2595 - Using TLS with IMAP, POP3 and ACAP > RFC2829 - Authentication Methods for LDAP > RFC2910 - IPP/1.1: Encoding and Transport > RFC3195 - Reliable Delivery for syslog > > The first four specify TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA as > MTI. The reasoning > for it being Diffie-Hellman rather than an RSA-based > ciphersuite was apparently > largely due to the "RSA patent", which was effective at the > time. All of the > above RFCs are "standards track". > > The last one, RFC3195, which is quite recent, specifies > TLS_RSA_WITH_3DES_EDE_CBC_SHA as the MTI ciphersuite (in > Section 5.4). However, > it's probably worth noting that it isn't actually an MTI, > rather it's a SHOULD. > > Phill & I chatted yesterday about the Diffie-Hellman/RSA > dichotomy and we think > that specifying TLS_RSA_WITH_3DES_EDE_CBC_SHA as the MTI TLS > ciphersuite for > SAML is the right way to go. In terms of real-world > deployment and use, the RSA > algorithm is what's being overwhelmingly supported and used. > > In terms of SSL -- which of course is widely deployed & used > -- standards track > RFCs haven't referenced it because it is not exactly a > "formally referenceable" > specification. However, RFC2566 "IPP/1.0: Model and Semantics" an > "experimental" RFC, specifies these SSL ciphersuites as MTI.. > > SSL_RSA_WITH_RC4_128_MD5 > SSL_RSA_WITH_3DES_EDE_CBC_SHA > SSL_RSA_WITH_DES_CBC_SHA > SSL_RSA_EXPORT_WITH_RC4_40_MD5 > SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > SSL_RSA_WITH_NULL_MD5 > > So, since we're operating in OASIS rather than the IETF, I > suggest we specify > the following TLS and SSL ciphersuites as MTI.. > > TLS_RSA_WITH_3DES_EDE_CBC_SHA (when using TLS) > SSL_RSA_WITH_3DES_EDE_CBC_SHA (when using SSL) > > > In 2829, we went on to specify specific TLS ciphersuites that > MUST NOT be used, > and others that should be used only with caution. It's > implied that using all > others is OPTIONAL. > > So, I suggest we have two sections, one specifying MTI > ciphersuites, and the > other outlining the security considerations of various subsets of the > ciphersuites. The former likely should go into the bindings > doc proper, and the > latter into the security considerations doc or section(s). > See immediately > below. > > JeffH > ----------------------------------- > Proposed text for MTI ciphersuites, insert in appropriate > place in bindings-xx > doc... > > > x.x.x Mandatory-to-implement Ciphersuite Requirements > > SSL-capable [ref to SSL] implementations MUST implement the > SSL_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. > > TLS-capable [ref to TLS] implementations MUST implement the > TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite. > > Section x.x of [SAML security consderations] specifies > additional requirements > for use of other TLS and SSL ciphersuites. > > > > ----------------------------------- > Proposed text for ciphersuite security considerations, insert > in appropriate > place in security considerations doc... > > > > x.x SSL and TLS ciphersuite considerations > > SSL and TLS provide integrity and/or confidentiality > protection of data > in-transit across a communications channel. Once > communicated, the data IS NO > LONGER PROTECTED by these mechanisms. *Persistent* integrity and/or > confidentiality protection of data objects, e.g. SAML > assertions, MUST be > provided by other means. > > Ciphersuites beginning with "SSL_" are defined in [ref to > SSL]. Ciphersuites > beginning with "TLS_" are defined in [ref to TLS]. > > Use of ciphersuites other than ones explicitly mentioned here, or ones > specified as mandatory-to-implement in [ref to bindings doc], > is OPTIONAL. > > > The following ciphersuites MUST NOT be used for integrity or > confidentiality > protection, or authentication of communicating parties, in > any implementation > of SAML bindings or profiles of SAML: > > TLS_NULL_WITH_NULL_NULL > > SSL_NULL_WITH_NULL_NULL > > > The following ciphersuites MUST NOT be used for > confidentiality protection in > any implementation of SAML bindings or profiles of SAML: > > TLS_NULL_WITH_NULL_NULL > TLS_RSA_WITH_NULL_MD5 > TLS_RSA_WITH_NULL_SHA > > SSL_NULL_WITH_NULL_NULL > SSL_RSA_WITH_NULL_MD5 > SSL_RSA_WITH_NULL_SHA > SSL_FORTEZZA_KEA_WITH_NULL_SHA > > > The encryption provided by the following so-called "40-bit" > ciphersuites can be cracked easily (less > than a week of CPU time on a standard CPU in 1997). The client and > server SHOULD carefully consider the value of data > being protected before using these ciphersuites: > > TLS_RSA_EXPORT_WITH_RC4_40_MD5 > TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > TLS_RSA_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA > TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 > TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA > > SSL_RSA_EXPORT_WITH_RC4_40_MD5 > SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > > > The encryption provided by the following so-called "DES" > ciphersuites uses a > 56-bit key, and is only modestly stronger than the "40-bit" > ciphersuites listed > above. > The client and server SHOULD carefully consider the value of > data being > protected before using these ciphersuites: > > TLS_RSA_WITH_DES_CBC_SHA > TLS_DH_DSS_WITH_DES_CBC_SHA > TLS_DH_RSA_WITH_DES_CBC_SHA > TLS_DHE_DSS_WITH_DES_CBC_SHA > TLS_DHE_RSA_WITH_DES_CBC_SHA > TLS_DH_anon_WITH_DES_CBC_SHA > > SSL_RSA_WITH_DES_CBC_SHA > SSL_DH_DSS_WITH_DES_CBC_SHA > SSL_DH_RSA_WITH_DES_CBC_SHA > SSL_DHE_DSS_WITH_DES_CBC_SHA > SSL_DHE_RSA_WITH_DES_CBC_SHA > SSL_DH_anon_WITH_DES_CBC_SHA > > > The following so-called "anonymous" ciphersuites do not > provide authentication > of communicating parties and are vulnerable to man-in-the-middle > attacks. They SHOULD NOT be used to protect sensitive data, > unless the network > configuration is such that the danger of a man-in-the-middle attack is > tolerable: > > TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 > TLS_DH_anon_WITH_RC4_128_MD5 > TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_anon_WITH_DES_CBC_SHA > TLS_DH_anon_WITH_3DES_EDE_CBC_SHA > > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_WITH_DES_CBC_SHA > SSL_DH_anon_WITH_RC4_128_MD5 > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > > > ============================================================== > ============ > > ----------------------------------- > -------- References -------- > ----------------------------------- > > > RFC2246 - TLS v1.0 ... > > . > . > . > 9. Mandatory Cipher Suites > > In the absence of an application profile standard specifying > otherwise, a TLS compliant application MUST implement the cipher > suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > . > . > . > > > > > ----------------------------------- > > > > RFC2829 - Authentication Methods for LDAP ... > . > . > . > 10. TLS Ciphersuites > > The following ciphersuites defined in [6] MUST NOT be used for > confidentiality protection of passwords or data: > > TLS_NULL_WITH_NULL_NULL > TLS_RSA_WITH_NULL_MD5 > TLS_RSA_WITH_NULL_SHA > > The following ciphersuites defined in [6] can be cracked > easily (less > than a week of CPU time on a standard CPU in 1997). The client and > server SHOULD carefully consider the value of the password or data > being protected before using these ciphersuites: > > TLS_RSA_EXPORT_WITH_RC4_40_MD5 > TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > TLS_RSA_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA > TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 > TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA > > The following ciphersuites are vulnerable to man-in-the-middle > attacks, and SHOULD NOT be used to protect passwords or sensitive > data, unless the network configuration is such that the danger of a > man-in-the-middle attack is tolerable: > > > TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 > TLS_DH_anon_WITH_RC4_128_MD5 > TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA > TLS_DH_anon_WITH_DES_CBC_SHA > TLS_DH_anon_WITH_3DES_EDE_CBC_SHA > > A client or server that supports TLS MUST support at least > TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. > . > . > . > [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC > 2246, January 1999. > . > . > . > > > ----------------------------------- > > SSL 3.0 Ciphersuites from: draft-freier-ssl-version3-02.txt ... > http://www.netscape.com/eng/ssl3/draft302.txt > > SSL_NULL_WITH_NULL_NULL > SSL_RSA_WITH_NULL_MD5 > SSL_RSA_WITH_NULL_SHA > SSL_RSA_EXPORT_WITH_RC4_40_MD5 > SSL_RSA_WITH_RC4_128_MD5 > SSL_RSA_WITH_RC4_128_SHA > SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > SSL_RSA_WITH_IDEA_CBC_SHA > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_RSA_WITH_DES_CBC_SHA > SSL_RSA_WITH_3DES_EDE_CBC_SHA > SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_DSS_WITH_DES_CBC_SHA > SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA > SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_RSA_WITH_DES_CBC_SHA > SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > SSL_DHE_DSS_WITH_DES_CBC_SHA > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DHE_RSA_WITH_DES_CBC_SHA > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_WITH_RC4_128_MD5 > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_WITH_DES_CBC_SHA > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > SSL_FORTEZZA_KEA_WITH_NULL_SHA > SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA > SSL_FORTEZZA_KEA_WITH_RC4_128_SHA > > -------------------------------------------- > > SSL_NULL_WITH_NULL_NULL > SSL_RSA_WITH_NULL_MD5 > SSL_RSA_WITH_NULL_SHA > > > > SSL_RSA_EXPORT_WITH_RC4_40_MD5 > SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > SSL_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA > SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > > > > SSL_RSA_WITH_DES_CBC_SHA > SSL_DH_DSS_WITH_DES_CBC_SHA > SSL_DH_RSA_WITH_DES_CBC_SHA > SSL_DHE_DSS_WITH_DES_CBC_SHA > SSL_DHE_RSA_WITH_DES_CBC_SHA > > > > SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 > SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA > SSL_DH_anon_WITH_DES_CBC_SHA > SSL_DH_anon_WITH_RC4_128_MD5 > SSL_DH_anon_WITH_3DES_EDE_CBC_SHA > > > > SSL_RSA_WITH_RC4_128_MD5 > SSL_RSA_WITH_RC4_128_SHA > SSL_RSA_WITH_IDEA_CBC_SHA > > > SSL_RSA_WITH_3DES_EDE_CBC_SHA > > > SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA > SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA > SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA > SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA > > > > SSL_FORTEZZA_KEA_WITH_NULL_SHA > SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA > SSL_FORTEZZA_KEA_WITH_RC4_128_SHA > > > ---------------------------------------------- > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC