ACTION-426: strong and weak TLS algorithms (incorporate ISSUE-128 text)

(I'd like review from those to whom this message is explicitly
addressed - Stephen, Phill, Johnath, Yngve, Will.)

I've looked closely at ISSUE-128 again, and it appears as though we
aren't coming up with hard and fast rules there; Bill's material
from ACTION-370 is essentially saying "use the latest version of

Instead of just taking Bill's text, I suggest we do something else:

1. Put the following text (based on Bill's) into


The ability to provide privacy and secure the connection between a
user agent and web server is in part determined by the strength and
capabilities of the TLS protocol and underlying cryptographic
mechanisms. The TLS protocol is versioned to keep pace with protocol
features and cipher suites that are available. Cipher suites are
grouped according to algorithms and the key length used by
cryptographic functions to provide cipher strength.

When this document speaks of [Definition: Strong TLS algorithms],
then the following must hold:

   1. No version of the TLS protocol that suffers known security
   flaws has been negotiated. At the point of writing of this
   document, no versions of SSL prior to SSLv3 [SSLv3] are
   considered strong.

   2. A cipher suite has been selected for which key and algorithm
   strengths correspond to industry practice. At the time of writing
   of this document, the "export" cipher suites explicitly forbidden
   in appendix A.5 of [TLSv11] are not considered strong.


In other words, let's call out a number of known bad algorithms, but
leave open what's still good when the specification is applied.

My plan would be to complement this by saying "when claim
conformance to this spec, you need to say which algorithms you
consider strong, and which ones you support, but consider weak".
I'll throw that into the conformance model section, on which I'm
going to work next.

Stay tuned.

Thomas Roessler, W3C  <>

Received on Wednesday, 11 June 2008 17:19:07 UTC