On Tue, 2015-04-28 at 10:15 -0400, Russell Doty wrote: > > == Scope == > > * Proposal owners: The crypto-policies package has to be updated to accommodate the new policies. > > * Other developers: Should verify that their package works after the change. That is that their package doesn't require only SSL 3.0, or only the RC4 ciphersuites. If their package requires these options due to design, they should consider contacting upstream to update the software. If that is not possible, or this support is needed to contact legacy servers, they should consider not using the system wide policy, and make that apparent in the package documentation. > > * Release engineering: This feature doesn't require coordination with release engineering. > > * Policies and guidelines: The packaging guidelines do not need to be changed. > For clarification: This is only changing the default - SSL 3.0 is still > available if specifically enabled? If so, we need to include > documentation on enabling it. The plan is to allow re-enabling by switching the system to legacy crypto policy. That would work for RC4. For SSL 3.0, since OpenSSL doesn't provide knobs to enable or disable on runtime, that will not be possible. However, according to Tomas Mraz openssl already disables SSL 3.0 in F22, and there were no major issues reported so that would be no issue. > Bigger question - should we deprecate SSL 3.0 and plan to remove it in > F25? (F25 gives people a year to prepare after being notified of > deprecation in F23.) Do you mean remove from the default settings in F25? I believe due to the high publicity of the various attacks with SSL 3.0 and RC4, administrators are already informed about the need to deprecate the algorithms, so there will not be much benefit postponing that issue for so long. > We are looking at deprecating and ultimately removing a larger set of > ciphers: > /* 56-bit DES "domestic" cipher suites */ > TLS_DHE_RSA_WITH_DES_CBC_SHA, [...] > Should these ciphers be included in this proposal? These are not enabled by default so they are not really a concern of that proposal. regards, Nikos -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
