On Fri, Mar 28, 2014 at 10:40:33AM -0400, Hubert Kario wrote:
> Because 3DES is required to provide backwards compatibility for
> old clients and received extensive cryptanalysis, it should remain
> in DEFAULT cipher set.
As must RC4-SHA1. There are still considerably many Windows XP
and Windows 2003 systems whose strongest working cipher-suite is
RC4-SHA1, and whose 3DES cipher-suite implements broken CBC padding
(perhaps the breakage is in appications rather than the TLS library,
but this is not important).
> Cipher suites with ciphers that have known weaknesses should be
> moved to LOW set (that means RC4).
Removing cipher-suites from the bottom of the cipherlist is an
exercise in self-righteousness, but generally reduces security,
because opportunistic connections will revert to cleartext when
the TLS handshake fails. Even RC4 is noticeably better than
cleartext, and is required for interoperability with older Microsoft
systems.
> To limit the chances of "unpleasant surprise", the cipher suites in DEFAULT,
> HIGH, MEDIUM or LOW set should not include cipher suites that don't perform
> authentication or encryption.
This is already the case.
> DEFAULT set
> ===========
The cipherlist ordering MUST be consistent between "DEFAULT" and
"ALL". In other-words, the "DEFAULT" cipher-suite MUST NOT revert
to being a manual hack radically different from "ALL". Rather,
the "DEFAULT" ciphersuite should simply be:
DEFAULT := ALL:!COMPLEMENTOFDEFAULT
and furthermore it MUST be the case that:
HIGH := ALL:!MEDIUM:!LOW:!EXPORT
MEDIUM := ALL:!HIGH:!LOW:!EXPORT
LOW := ALL:!HIGH:!MEDIUM:!EXPORT
EXPORT := ALL:!HIGH:!MEDIUM:!LOW
in other words all elementary (non-composite) built-in cipher-suite
classes should have the same relative order of their component
cipher-suites (obtained by applying a suitable filter to the
internall pre-sorted ALL).
Everything below should be either a specification of how to order
"ALL" or what to include in COMPLEMENTOFDEFAULT.
>
> 1. The cipher suites should first be sorted by the key exchange,
> ECHDE first, then DHE, non ephemeral, finally SRP and PSK.
Note, we don't really know that ECDHE is more secure than DHE, but
it is more interoperable, because the curve is negotiated. Also
ECDHE performs better on the server side.
> 2. Then by used cipher, with all ciphers that provide 128 bit security and
> received extensive cryptanalysis treated as equivalent (Camellia, AES),
> other ciphers should be excluded with the exception of 3DES
> which should be placed last.
This essentially requires augmenting the cipher key lengths with
a cipher grade ordinal and changing @STRENGTH to sort on these, or
adding a new @GRADE, which sorts on the new GRADE and does not
distinguish between adequately strong ciphers, but then within each
grade sort by algorithm preference and then bit-strength. (Not
fastest first, see below).
> 3. Equivalent ciphers should be sorted by their performance (faster first).
That's a radical departure from existing practice. If you want to
optimize for performance, allow users to exclude 256-bit cipher-suites
entirely, they all have 128-bit equivalents that are faster. The
DEFAULT ciphersuite should probably not take this step, the
performance cipherlist can be some other cipherlist.
+FAST:-FAST:DEFAULT
where FAST includes all AES128 ciphers first (not CAMELLIA, because
AES256 hardware is faster than CAMELLIA128 software). This does raise
the point that performance is highly platform dependent, and no single
ordering will properly optimize for performance on all platforms.
> 4. Then cipher suites should be sorted by used integrity mechanism: GCM,
> SHA-2, SHA-1
I think you mean AEAD not GCM specifically (GCM is perhaps an
unfortunate choice of AEAD modes, but we're going down that rathole
at this time).
> 3DES ciphers are left in only because of compatibility with old
> implementations that do not support AES ciphers.
Ditto RC4-SHA1, which is much more broadly interoperable.
> kEECDH:+kEECDH+AES256:+kEECDH+CAMELLIA128:+kEECDH+CAMELLIA256:
> kEDH:+kEDH+AES256:+kEDH+CAMELLIA128:+kEDH+CAMELLIA256:
> kECDH:+kECDH+AES256:+kECDH+CAMELLIA128:+kECDH+CAMELLIA256:
> kDH:+kDH+AES256:+kDH+CAMELLIA128:+kDH+CAMELLIA256:
> kRSA:+kRSA+AES256:+kRSA+CAMELLIA128:+kRSA+CAMELLIA256: kPSK:+kPSK+AES256:
> kSRP:+kSRP+AES256: !aNULL:!eNULL:!SSLv2:!RC4:!DES:!EXP:!SEED:!IDEA:+3DES )
- Sort "ALL", not "DEFAULT". Since "ALL" already excludes "eNULL",
obtain DEFAULT from ALL via:
DEFAULT := ALL:!aNULL:!SEED:!IDEA:!EXPORT:!LOW
> HIGH
> ====
>
> This list should contain only ciphers that use AES and Camellia based
> cipher suites (in other words, provide robust 128 bit security).
That just means excluding 3DES, from HIGH.
> It should not contain cipher suites that don't offer authentication
> (aNULL).
SORRY, NO WAY, this breaks applications that do aNULL with channel
binding or want strong passive eavesdropping protection, but can't
authenticate the peer. DO NOT confuse crypto strength with
authentication. To get the "HIGH" you want (no pun intended), use:
HIGH:!COMPLEMENTOFDEFAULT
which is likely the same as:
HIGH:!aNULL
> It should follow the same cipher ordering rules as the DEFAULT cipher list.
Already covered if all ordering is descended from "ALL".
> MEDIUM
> ======
>
> This list should contain only ciphers that don't have obvious shortcomings or
> don't provide 128 bit security.
It MUST include RC4-SHA1, and MUST also include aNULL ciphers where
applicable. That is, like HIGH, it DOES NOT exclude COMPLEMENTOFDEFAULT.
To get the MEDIUM you want, use either of:
MEDIUM:!COMPLEMENTOFDEFAULT
MEDIUM:!aNULL
One might define *new* elementary lists that do this, but don't break
the existing HIGH, MEDIUM, LOW, EXPORT.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
