- From: Luis Barriga <luis.barriga@ericsson.com>
- Date: Wed, 17 Oct 2007 17:20:34 +0200
- To: <yngve@opera.com>, <michael.mccormick@wellsfargo.com>, <Anil.Saldhana@redhat.com>, <public-wsc-wg@w3.org>
No, I don't want (WSC) to go there. Let experts do that if possible. That's why I wrote at the end of the same email >>One way forward is to ask Ecrypt folks to produce such TLS suite >>recommendation since the step is not that far using as baseline >>their current crypto recommendations. Thus, I agree that we should provide a reference to authoritative documents recommending ciphers (e.g. IETF, ECRYPT)and cipher suites (if/when available). We should not provide the the cipher recommendations themselves, except for general established security principles such as "the weakest cipher in the suite determines the overal cipher strength" Luis -----Original Message----- From: Yngve Nysaeter Pettersen [mailto:yngve@opera.com] Sent: den 17 oktober 2007 16:09 To: Luis Barriga; michael.mccormick@wellsfargo.com; Anil.Saldhana@redhat.com; public-wsc-wg@w3.org Subject: Re: ISSUE-128: Strong / weak algorithms? [Techniques] On Wed, 17 Oct 2007 15:10:05 +0200, Luis Barriga <luis.barriga@ericsson.com> wrote: > I checked those docs and they are still focused on each cipher > independently. The Ecrypt paper is closer (compared to FIPS) to what I > think we need but still not there. > > The point I'm trying to make is that we need some recommendations not > at the *separate cipher* level, but at the *cipher suite* level so the > combination of public and symmetric is also consistent. Correct me if > i'm wrong... Are you sure you want to go there? It could get messy. There was a quite heavy discussion on the TLS WG last week about this issue. The thing about the suites is that the symmetric cipher and the digest operation are the only fixed size items in the suite. The keyexchange method have no fixed size, save whatever minimum the exchange structure causes the size of the key to be. My approach to the this is to say that the weakest method or keysize (as mapped into an equivalence map) trumps the security evaluation, meaning that a 1024 DHE from 512 bit RSA with 256 bit AES is considered very unsecure, while a similar 1024/1024/256 is (still) considered fairly secure. Then there is the fact that some security parameters are not necessarily part of the ciphersuite selection, but are defined by the keys used in the certificate chain. IMO The best way to phrase a recommendation would be to reference the most up to date version of these documents, and suggest that applications only consider secure IETF defined cipher suites that are composed of methods (and associated keysizes) that are considered secure for at least 10 or 15 years by these documents. We might want to specificall discourage use of some suites, such as the anonymous and authentication/integrity-only suites, just to be on the safe side. What methods that can be considered secure is really a bit to flexible to cast in stone, even with a lot of disclaimers. > For example, the NIST document recommends the following ciphers suites: > TLS_DHE_DSS_WITH_AES_256_CBC_SHA > TLS_DHE_RSA_WITH_AES_256_CBC_SHA > TLS_RSA_WITH_AES_256_CBC_SHA > ... > > One way forward is to ask Ecrypt folks to produce such TLS suite > recommendation since the step is not that far using as baseline their > current crypto recommendations. > > Luis > > -----Original Message----- > From: public-wsc-wg-request@w3.org > [mailto:public-wsc-wg-request@w3.org] > On Behalf Of Yngve N. Pettersen (Developer Opera Software ASA) > Sent: den 17 oktober 2007 13:25 > To: Luis Barriga; michael.mccormick@wellsfargo.com; > Anil.Saldhana@redhat.com; public-wsc-wg@w3.org > Subject: Re: ISSUE-128: Strong / weak algorithms? [Techniques] > > > > Any reason why the result of ACTION-285 doesn't suffice? > > http://www.w3.org/2006/WSC/track/actions/285 > http://lists.w3.org/Archives/Public/public-wsc-wg/2007Sep/0014.html > > On Wed, 17 Oct 2007 13:06:50 +0200, Luis Barriga > <luis.barriga@ericsson.com> wrote: > >> >> FIPS main audience is *crypto* implementors. It seems too low level >> and thus doesn't seem to be the primary document to refer to. >> >> We need to refer to some authoritative document(s) recommending TLS >> suites to web site *security* administrators so they can decide which >> ones to enable/disable when deploying TLS-enabled web sites. I don't >> think administrators would get that much help digging into FIPS. >> >> NIST has such document, but as I mentioned in is for govermental use, >> which excludes RC4, that as far as I know (?) is widely deployed due >> to its high performance. >> >> Luis >> >> -----Original Message----- >> From: public-wsc-wg-request@w3.org >> [mailto:public-wsc-wg-request@w3.org] >> On Behalf Of michael.mccormick@wellsfargo.com >> Sent: den 17 oktober 2007 00:02 >> To: Anil.Saldhana@redhat.com; public-wsc-wg@w3.org >> Subject: RE: ISSUE-128: Strong / weak algorithms? [Techniques] >> >> >> It might be better in a W3C standard to reference the international >> equivalents of FIPS 140. >> >> The FIPS 140-1 equivalent is ISO/IEC FCD 19790 "Security requirements >> for cryptographic modules". >> >> Last I heard, FIPS 140-2 was the US input document to an NP recently >> approved by CS1. At that time it had not yet been assigned an >> ISO/IEC number, but maybe that has changed. >> >> Mike >> >> -----Original Message----- >> From: public-wsc-wg-request@w3.org >> [mailto:public-wsc-wg-request@w3.org] >> On Behalf Of Anil Saldhana >> Sent: Tuesday, October 16, 2007 3:08 PM >> To: Web Security Context Working Group WG >> Subject: Re: ISSUE-128: Strong / weak algorithms? [Techniques] >> >> >> FIPS 140-2 is the defining standard for cryptology (at least in the US). >> >> Maybe we can use that as the frame of reference in the rec doc? >> >> Doyle, Bill wrote: >>> A number of standards bodies that we can point to that note >>> recommended strengths. >>> >>> In the US the National Institute of Standards and Technology (NIST) >>> provides the clearing house for recommended practices. Systems could >>> follow Federal Information Processing Standards (FIPS) or FIPS 140-2 >>> >>> http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf >>> >>> *From:* public-wsc-wg-request@w3.org >>> [mailto:public-wsc-wg-request@w3.org] *On Behalf Of *Hallam-Baker, >>> Phillip >>> *Sent:* Tuesday, October 16, 2007 11:33 AM >>> *To:* Thomas Roessler >>> *Cc:* Luis Barriga; Web Security Context Working Group WG >>> *Subject:* RE: ISSUE-128: Strong / weak algorithms? [Techniques] >>> >>> I would prefer not to make a recommendation here since it is not a >>> document that I would want to keep continuously updated. >>> >>> There is a strong industry consensus here and what we need to do >>> is to ensure that it is widely recognized as such and have a >>> mechanism to alert people when the consensus changes (e.g. the new >>> results on SHA-1). >>> >>> *From:* Thomas Roessler [mailto:tlr@w3.org] >>> *Sent:* Tue 16/10/2007 4:08 AM >>> *To:* Hallam-Baker, Phillip >>> *Cc:* Luis Barriga; Web Security Context Working Group WG >>> *Subject:* Re: ISSUE-128: Strong / weak algorithms? [Techniques] >>> >>> On 2007-10-15 20:26:04 -0700, Phillip Hallam-Baker wrote: >>> >>> > I don't think we should write an exhaustive list olf strong >>> > ciphers. The most we should do is to note that there is a set of >>> > ciphers that the consensus recognizes as being acceptably strong >>> > which should be supported. >>> >>> I'd rather we either reference some known-authoritative document >>> that is being maintained elsewhere (because I don't see us >>> taking >> on >>> that kind of document maintenance role for this particular >> problem). >>> >>> The second-best approach might be to say "these are known bad >> [REF] >>> [REF] [REF], for the rest, please do your due diligence." >>> >>> Regards, >>> -- >>> Thomas Roessler, W3C <tlr@w3.org> >>> >> >> -- >> Anil Saldhana >> Project/Technical Lead, >> JBoss Security & Identity Management >> JBoss, A division of Red Hat Inc. >> http://labs.jboss.com/portal/jbosssecurity/ >> >> >> >> >> > > > -- 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, 17 October 2007 15:20:54 UTC