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

Looks mostly OK to me.

One thing that _might_ be added separately, or implied by an "additional  
defintions that define what strong encryption is may exist", is that not  
all lengths for the public key encryption method in the suite may be  
considered strong. The strength of this key is not implied in the  
ciphersuite defintion, unlike for symmetric ciphers.

For example, I definitely do not consider 512 bit RSA to be considered  
strong, and Opera actually does not consider any RSA/DH/DSA key shorter  
than 1000 bits in the certificate chain or the server key exchange step to  
considered strong (and the 1000 bit limit is a pragmatic accomodation to  
the continued use of one particular root).

In fact, when you have a serious AV vendor actively considering starting a  
distributed computing keybreak effort for a 1024 bit RSA key (used by  
malware) which apparently happened today, you can start wondering how  
secure 1024 bit RSA keys really are.


On Wed, 11 Jun 2008 19:18:33 +0200, Thomas Roessler <tlr@w3.org> wrote:

> (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
> TLS".
>
> Instead of just taking Bill's text, I suggest we do something else:
>
> 1. Put the following text (based on Bill's) into
> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#def-strong-algos:
>
>>>>
>
> 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.
>
> Cheers,



-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		                 Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Wednesday, 11 June 2008 17:34:17 UTC