On Sun, Dec 15, 2013 at 05:10:38PM -0500, James Cloos wrote:
> >>>>> "MK" == Marko Kreen <mark...@gmail.com> writes:
> >>>>> "PE" == Peter Eisentraut <pete...@gmx.net> writes:

> PE> Any other opinions on this out there?
> For reference, see:
>   https://wiki.mozilla.org/Security/Server_Side_TLS
> for the currently suggested suite for TLS servers.
> That is:

This is example of ciphersuite list for people who have special
requirements and care about tracking yearly changes in SSL landscape.
And can deploy config changes relatively fast.

This discussion is about Postgres default suite which cannot and should
not be periodically changed, for people who leave Postgres settings
to defaults and expect setup work well.

We would like to leave as much as possible to OpenSSL, but not more.

Looking at the history of OpenSSL, their default order has been
good, except the 3DES vs. AES128 priority.

Looking into future, I guess following events are likely:

- RC4 gets practially broken and/or removed from TLS

- New ciphersuites: Salsa/Chacha (256-bit key).

- New modes: CCM (RFC6655, draft-mcgrew-tls-aes-ccm-ecc-07),
  other ciphers with GCM, new AEAD constructs.

- CBC mode fixes: pad-mac-encrypt, pad-encrypt-mac.  Those may
  be implemented with TLS extensions, so no new ciphersuites.

RC4 situation - the 'MEDIUM' in my proposal communicates
that not all ciphers are best, and prefer-server-order
makes sure it is selected as last resort.  So that is solved.

New ciphersuites - if we want to select fastest from "secure"
suites we need to change configuration periodically
(RC4->AES128-CBC->AES128-GCM->SALSA) and I don't think Postgres
should bother we that.  So I think it's better to leave ordering
new ciphers to OpenSSL, and people who have special requirements
can worry about best configuration for specific stack they are running.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to