On Wed, Oct 28, 2009 at 09:09:59PM +0300, Victor B. Wagner wrote:
> > > But for some setups, especially in OpenSSL 1.0, which supports EC
> > > ciphersuites, dh parameters are not neccessary.
> >
> > This is not entirely accurately, one still needs to designate an ECDH
> > curve for ECDHE ciphers. Postfix code for this:
>
> curve is not DH parameters. It is quite different dataset.
> (and often expressed as just OID, not actual curve data).
Yes, of course, in a strictly technical sense. From a user perspective,
however, both are the same sort of thing, something one needs to configure
to enable kEDH or kEECDH ciphers. When neither set of parameters is provided,
one gets just
- kRSA, kECDHr, kECDHe (no forward secrecy)
- kPSK (no significant adoption)
So users or applications that want to support ephemeral key-exchange with
forward secrecy, need to configure DH parameters and/or an EECDH curve
(yes just an OID).
> > More precise is "!kEDH", and IIRC OpenSSL does not offer kEDH ciphers
> > on the wire, when no parameters are provided by the application.
>
> Question is - should we make user immediately aware of this restriction
> during parsing the configuration?
Not sure what you mean by "during parsing".
> If user specifies DSA key only it is fatal.
> If user specifies RSA key only half of otherwise available suites
> are left.
It is OK if the user cipher selection string designates more ciphers
(e.g. DEFAULT) than actually compatible with the available with the
available certificates and/or parameters, so long as a non-empty
set of usable cipher-suites remains.
> > DTRT! When no parameters are provided, don't include kEDH ciphers in
> > the list of available ciphers, regardless of the user-specified cipherlist.
>
> I think that is not very good idea to SILENTLY cut off lot of good
> ciphersuites.
I strong disagree. Most users (I've talked to users trying to select
appropriate cipher lists) have no idea what the various ciphers are,
and are much better off with either DEFAULT or DEFAULT:!SSLv2:!EXPORT:!LOW
than anything they are likely to come up with on their own.
In both of the "sensible" cipherlists above, there are a lot more ciphers
than typically compatible with the rest of the configuration. This is fine.
> And obvoisly a fatal configuration error if some of these ciphersuites
> were explicitely specified by user in the cipher list.
This would be bad. It is specifically documented that unknown cipherlist
elements are ignored, and for good reason.
If you want a "lint" tool for configurations, by all means, that would
be a good idea. But, making cipherlists incompatible with libraries
that don't support every cipher on the list, is bad, one can't use
a single list whose elements include features from "future" releases
on legacy systems or build code that is intended to support "future"
versions of SSL whose features are known at development time, but
not yet available in the field.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
