Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[openssl-dev] Circumstances cause CBC often to be preferred over GCM modes
38 views
Skip to first unread message
Hanno Böck
Dec 15, 2014, 8:26:57 PM12/15/14
to
Hi,
Sorry for crossposting this to three lists but I feel this is a
multi-software-issue and I feel all software involved need to find a
way to resolve this.
I feel the current software setting of tls server configs and browsers
leads to the unoptimal result that often CBC modes are preferred over
authenticated encryption GCM-modes. There seems to be widespread
agreement that TLS-CBC-Modes are not optimal and should be avoided
(Padding oracles, Lucky Thirteen etc.)
Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM
these days. However they have for some reason decided not to support
AES-256 but only AES-128. This is in itself no problem because there is
no reason to believe AES-128 is not safe. But it leads to the probably
unintended consequence that often AES-256-CBC is preferred over
AES-128-GCM.
Take this scenario:
* Server operator uses apache+openssl wiht cipher string
"HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable. Only HIGH
security ciphers and sort them by strength.
* Browser (Chrome or Firefox) will take the first preferred cipher
suite it supports. As it doesn't support AES-GCM-256 it will choose
AES-CBC_256.
What can be done to avoid this?
a) First of all server operators can do more manual work and sort
ciphers on their own. However it's probably not desired that every
server operator needs to know the inner details of TLS.
b) OpenSSL changes so that it considers GCM-modes always more secure
than CBC modes and sorts them to the front.
c) Browsers could start supporting AES-256-GCM
d) Browsers could stop supporting AES-256-CBC
Each of these would solve the issue, they don't exclude each other
(in theory you could do all of them). I feel b) should happen anyway
and probably one of c) or d). If browsers feel AES-128 is "good enough"
they could just remove AES-256 support completely. If they feel they
want AES-256 in the unlikely case that attacks against AES improve by a
great margin then there is no reason not to support AES-256-GCM. It
feels illogical to support AES-256, but only in its less secure mode.
Thoughts?
cu,
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
Sorry for crossposting this to three lists but I feel this is a
multi-software-issue and I feel all software involved need to find a
way to resolve this.
I feel the current software setting of tls server configs and browsers
leads to the unoptimal result that often CBC modes are preferred over
authenticated encryption GCM-modes. There seems to be widespread
agreement that TLS-CBC-Modes are not optimal and should be avoided
(Padding oracles, Lucky Thirteen etc.)
Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM
these days. However they have for some reason decided not to support
AES-256 but only AES-128. This is in itself no problem because there is
no reason to believe AES-128 is not safe. But it leads to the probably
unintended consequence that often AES-256-CBC is preferred over
AES-128-GCM.
Take this scenario:
* Server operator uses apache+openssl wiht cipher string
"HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable. Only HIGH
security ciphers and sort them by strength.
* Browser (Chrome or Firefox) will take the first preferred cipher
suite it supports. As it doesn't support AES-GCM-256 it will choose
AES-CBC_256.
What can be done to avoid this?
a) First of all server operators can do more manual work and sort
ciphers on their own. However it's probably not desired that every
server operator needs to know the inner details of TLS.
b) OpenSSL changes so that it considers GCM-modes always more secure
than CBC modes and sorts them to the front.
c) Browsers could start supporting AES-256-GCM
d) Browsers could stop supporting AES-256-CBC
Each of these would solve the issue, they don't exclude each other
(in theory you could do all of them). I feel b) should happen anyway
and probably one of c) or d). If browsers feel AES-128 is "good enough"
they could just remove AES-256 support completely. If they feel they
want AES-256 in the unlikely case that attacks against AES improve by a
great margin then there is no reason not to support AES-256-GCM. It
feels illogical to support AES-256, but only in its less secure mode.
Thoughts?
cu,
--
Hanno Böck
http://hboeck.de/
mail/jabber: ha...@hboeck.de
GPG: BBB51E42
Hanno Böck
Dec 15, 2014, 9:04:47 PM12/15/14
to
On Mon, 15 Dec 2014 17:36:40 -0800
Ryan Sleevi <rsl...@chromium.org> wrote:
> > > * Server operator uses apache+openssl wiht cipher string
> > > "HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable.
> > > Only HIGH security ciphers and sort them by strength.
> > > * Browser (Chrome or Firefox) will take the first preferred cipher
> > > suite it supports. As it doesn't support AES-GCM-256 it will
> > > choose AES-CBC_256.
> >
>
> This isn't an accurate description of the flow.
Ryan Sleevi <rsl...@chromium.org> wrote:
> > > * Server operator uses apache+openssl wiht cipher string
> > > "HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH". This seems reasonable.
> > > Only HIGH security ciphers and sort them by strength.
> > > * Browser (Chrome or Firefox) will take the first preferred cipher
> > > suite it supports. As it doesn't support AES-GCM-256 it will
> > > choose AES-CBC_256.
> >
>
>
> The client advertises its set of ciphersuites in the client hello. The
> server is responsible for choosing the ciphersuite used, and may take
> either client priority into consideration (e.g. if the client is a
> constrained device, it might intentionally prefer a
> weaker-but-efficient algorithm; this was classically true for 3DES
> and RC4) or it may ignore this and choose at the server level. For
> example, with Apache,
> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder
Ah, sorry, of course you're right.
My analysis of the situation was wrong, however it doesn't really
change the outcome: There are a number of sites probably configured in
good faith with secure settings that result in CBC being preferred over
GCM.
(But good to note that a quick fix is to disable SSLHonorCipherOrder
on affected apache servers)
Hanno Böck
Dec 15, 2014, 9:18:12 PM12/15/14
to
On Mon, 15 Dec 2014 18:07:15 -0800
Ryan Sleevi <rsl...@chromium.org> wrote:
> I fear you may have misread again.
>
> SSLHonorCipherOrder is on by default, and respects the client
> preferences. The mainstream clients generally prefer GCM over CBC,
> ergo, honoring the cipher order is the right thing.
>
> By setting SSLHonorCipherOrder to false (disabling it), you set the
> servers preference. It now becomes the server operator's
> responsibility to configure the ciphersuites correctly, which gets
> into the issues you were wanting to avoid.
Reading apache doc tells me the opposite:
"When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the
client's preference is used. If this directive is enabled, the server's
preference will be used instead."
> As Rich said, have you observed this in practice and looked into why?
I have on my own servers and as I already wrote you can on
see it on www.openssl.org.
Having tested with not setting SSLHonorCipherOrder however causes other
issues - some other browsers won't use FS ciphers then (notably some
older IE versions and all mobile IEs - at least that's what the ssl labs
test says).
To reiterate the above said, I have two apache configs:
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH
Result: GCM in chrome/ff, but no FS in many IE versions (and A- on ssl
labs).
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH
Result: no GCM in chrome/ff, but FS in all ssl labs reference browsers
(and A+ rating).
Ryan Sleevi <rsl...@chromium.org> wrote:
> I fear you may have misread again.
>
> SSLHonorCipherOrder is on by default, and respects the client
> preferences. The mainstream clients generally prefer GCM over CBC,
> ergo, honoring the cipher order is the right thing.
>
> By setting SSLHonorCipherOrder to false (disabling it), you set the
> servers preference. It now becomes the server operator's
> responsibility to configure the ciphersuites correctly, which gets
> into the issues you were wanting to avoid.
Reading apache doc tells me the opposite:
"When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the
client's preference is used. If this directive is enabled, the server's
preference will be used instead."
> As Rich said, have you observed this in practice and looked into why?
I have on my own servers and as I already wrote you can on
see it on www.openssl.org.
Having tested with not setting SSLHonorCipherOrder however causes other
issues - some other browsers won't use FS ciphers then (notably some
older IE versions and all mobile IEs - at least that's what the ssl labs
test says).
To reiterate the above said, I have two apache configs:
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH
Result: GCM in chrome/ff, but no FS in many IE versions (and A- on ssl
labs).
SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2
SSLHonorCipherOrder on
SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL@STRENGTH
Result: no GCM in chrome/ff, but FS in all ssl labs reference browsers
(and A+ rating).
Hanno Böck
Dec 15, 2014, 10:25:32 PM12/15/14
to
On Tue, 16 Dec 2014 03:09:53 +0000
Viktor Dukhovni <openss...@dukhovni.org> wrote:
> On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
>
> > Firefox and Chrome support authenticated encryption via TLS 1.2 and
> > GCM these days. However they have for some reason decided not to
> > support AES-256 but only AES-128.
>
> In which case, they will never use AES-256, and yet:
No, you understood that wrong: They decided to not support AES-256 for
CGM. For CBC they support both 128/256.
> This is a cipherstring with great redundancy and a typo. What you
> meant was:
The cipher string doesn't really matter, it happens with every setting
where you enable AES CBC/GCM ciphers in both 128/256 bit setting.
And yes, my initial mail was a bit confused (server chooses, not
client), still the result is the same: For very common settings it
happens that browsers choose cbc if gcm would be available (just
point chrome to https://www.openssl.org to see it).
Viktor Dukhovni <openss...@dukhovni.org> wrote:
> On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
>
> > Firefox and Chrome support authenticated encryption via TLS 1.2 and
> > GCM these days. However they have for some reason decided not to
> > support AES-256 but only AES-128.
>
No, you understood that wrong: They decided to not support AES-256 for
CGM. For CBC they support both 128/256.
> This is a cipherstring with great redundancy and a typo. What you
> meant was:
The cipher string doesn't really matter, it happens with every setting
where you enable AES CBC/GCM ciphers in both 128/256 bit setting.
And yes, my initial mail was a bit confused (server chooses, not
client), still the result is the same: For very common settings it
happens that browsers choose cbc if gcm would be available (just
point chrome to https://www.openssl.org to see it).
Viktor Dukhovni
Dec 15, 2014, 11:54:57 PM12/15/14
to
On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote:
> > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
> >
> > > Firefox and Chrome support authenticated encryption via TLS 1.2 and
> > > GCM these days. However they have for some reason decided not to
> > > support AES-256 but only AES-128.
> >
> > In which case, they will never use AES-256, and yet:
>
> No, you understood that wrong: They decided to not support AES-256 for
> CGM. For CBC they support both 128/256.
In that case indeed many servers will choose CBC at 256 bits over
> > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
> >
> > > Firefox and Chrome support authenticated encryption via TLS 1.2 and
> > > GCM these days. However they have for some reason decided not to
> > > support AES-256 but only AES-128.
> >
> > In which case, they will never use AES-256, and yet:
>
> No, you understood that wrong: They decided to not support AES-256 for
> CGM. For CBC they support both 128/256.
GCM at 128. This is a browser configuration issue, and should be
addressed there.
> And yes, my initial mail was a bit confused (server chooses, not
> client), still the result is the same: For very common settings it
> happens that browsers choose cbc if gcm would be available (just
> point chrome to https://www.openssl.org to see it).
factors here, and perhaps they have good reasons for the choices
they made.
--
Viktor.
_______________________________________________
openssl-dev mailing list
opens...@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Hubert Kario
Dec 16, 2014, 9:16:10 AM12/16/14
to
On Tuesday 16 December 2014 04:53:11 Viktor Dukhovni wrote:
> On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote:
> > > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
> > > > Firefox and Chrome support authenticated encryption via TLS 1.2 and
> > > > GCM these days. However they have for some reason decided not to
> > > > support AES-256 but only AES-128.
> > >
> > > In which case, they will never use AES-256, and yet:
> > No, you understood that wrong: They decided to not support AES-256 for
> > CGM. For CBC they support both 128/256.
>
> In that case indeed many servers will choose CBC at 256 bits over
> GCM at 128. This is a browser configuration issue, and should be
> addressed there.
>
(...)
> On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote:
> > > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote:
> > > > Firefox and Chrome support authenticated encryption via TLS 1.2 and
> > > > GCM these days. However they have for some reason decided not to
> > > > support AES-256 but only AES-128.
> > >
> > > In which case, they will never use AES-256, and yet:
> > No, you understood that wrong: They decided to not support AES-256 for
> > CGM. For CBC they support both 128/256.
>
> In that case indeed many servers will choose CBC at 256 bits over
> GCM at 128. This is a browser configuration issue, and should be
> addressed there.
>
>
> The browsers need to fix their settings, but there are many competing
> factors here, and perhaps they have good reasons for the choices
> they made.
No, this is problem with OpenSSL cipher order - it prefers key size over other
> The browsers need to fix their settings, but there are many competing
> factors here, and perhaps they have good reasons for the choices
> they made.
factors - it should prefer AEAD and PFS ciphers before ordering on key size,
doubly so that in practice you can't get anywhere near 256 bit level of
security using TLS.
we've talked about this before
preferring AES-256 over AES-128 in Internet setting with Internet CAs just
burns cycles for nought
also, the reason why neither Firefox nor Chrome support AES-256-GCM is because
NSS doesn't support SHA-384 PFS for TLSv1.2 - it's not a case of "just
flipping a switch"
--
Regards,
Hubert Kario
Hanno Böck
Dec 16, 2014, 9:39:45 AM12/16/14
to
On Tue, 16 Dec 2014 15:14:13 +0100
Hubert Kario <hka...@redhat.com> wrote:
> No, this is problem with OpenSSL cipher order - it prefers key size
> over other factors - it should prefer AEAD and PFS ciphers before
> ordering on key size, doubly so that in practice you can't get
> anywhere near 256 bit level of security using TLS.
Agreed, this is one of the things I think that should happen.
Hubert Kario <hka...@redhat.com> wrote:
> No, this is problem with OpenSSL cipher order - it prefers key size
> over other factors - it should prefer AEAD and PFS ciphers before
> ordering on key size, doubly so that in practice you can't get
> anywhere near 256 bit level of security using TLS.
I got a reply on the chromium list that this is already so in
boringssl. Code is in ssl/ssl_ciph.c
If there is consensus that this should be ported I would try to isolate
the neccessary patches from boringssl and submit them.
Hubert Kario
Dec 16, 2014, 9:44:39 AM12/16/14
to
On Tuesday 16 December 2014 15:38:01 Hanno Böck wrote:
> On Tue, 16 Dec 2014 15:14:13 +0100
>
> Hubert Kario <hka...@redhat.com> wrote:
> > No, this is problem with OpenSSL cipher order - it prefers key size
> > over other factors - it should prefer AEAD and PFS ciphers before
> > ordering on key size, doubly so that in practice you can't get
> > anywhere near 256 bit level of security using TLS.
>
> Agreed, this is one of the things I think that should happen.
>
> I got a reply on the chromium list that this is already so in
> boringssl. Code is in ssl/ssl_ciph.c
>
> If there is consensus that this should be ported I would try to isolate
> the neccessary patches from boringssl and submit them.
> On Tue, 16 Dec 2014 15:14:13 +0100
>
> Hubert Kario <hka...@redhat.com> wrote:
> > No, this is problem with OpenSSL cipher order - it prefers key size
> > over other factors - it should prefer AEAD and PFS ciphers before
> > ordering on key size, doubly so that in practice you can't get
> > anywhere near 256 bit level of security using TLS.
>
> Agreed, this is one of the things I think that should happen.
>
> I got a reply on the chromium list that this is already so in
> boringssl. Code is in ssl/ssl_ciph.c
>
> If there is consensus that this should be ported I would try to isolate
> the neccessary patches from boringssl and submit them.
Last time we have discussed it[1], the only voices against were about removal
of RC4 ciphers from default
What is the exact ordering of ALL:COMPLEMENTOFALL in boringssl?
1 - http://openssl.6102.n7.nabble.com/Insecure-DEFAULT-cipher-set-td48995.html
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Hanno Böck
Dec 16, 2014, 10:21:31 AM12/16/14
to
On Tue, 16 Dec 2014 15:42:43 +0100
Hubert Kario <hka...@redhat.com> wrote:
> Last time we have discussed it[1], the only voices against were about
> removal of RC4 ciphers from default
The boringssl patch was quite invasive, so I gave up to try to port
Hubert Kario <hka...@redhat.com> wrote:
> Last time we have discussed it[1], the only voices against were about
> removal of RC4 ciphers from default
their changes.
But in essence it's quite trivial, just re-order stuff a bit. See
attached patch.
Output after my patch of ALL:COMPLEMENTOFALL:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC3-SHA:EDH-DSS-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:AECDH-AES256-SHA:AECDH-AES128-SHA:ADH-AES256-GCM-SHA384:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-AES128-SHA256:ADH-AES256-SHA:ADH-AES128-SHA:AECDH-DES-CBC3-SHA:ADH-SEED-SHA:ADH-CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:ADH-DES-CBC3-SHA:ADH-DES-CBC-SHA:EXP-ADH-DES-CBC-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES256-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:SEED-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA:DES-CBC-SHA:EXP-DES-CBC-SHA:IDEA-CBC-SHA:EXP-RC2-CBC-MD5:DES-CBC3-MD5:DES-CBC-MD5:IDEA-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:EXP-ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-NULL-SHA:ECDHE-ECDSA-NULL-SHA:AECDH-NULL-SHA:ECDH-RSA-NULL-SHA:ECDH-ECDSA-NULL-SHA:NULL-SHA256:NULL-SHA:NULL-MD5
To compare, output of plain openssl:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC3-SHA:EDH-DSS-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:AECDH-AES256-SHA:AECDH-AES128-SHA:ADH-AES256-GCM-SHA384:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-AES128-SHA256:ADH-AES256-SHA:ADH-AES128-SHA:AECDH-DES-CBC3-SHA:ADH-SEED-SHA:ADH-CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:ADH-DES-CBC3-SHA:ADH-DES-CBC-SHA:EXP-ADH-DES-CBC-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES256-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:SEED-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA:DES-CBC-SHA:EXP-DES-CBC-SHA:IDEA-CBC-SHA:EXP-RC2-CBC-MD5:DES-CBC3-MD5:DES-CBC-MD5:IDEA-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:EXP-ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-NULL-SHA:ECDHE-ECDSA-NULL-SHA:AECDH-NULL-SHA:ECDH-RSA-NULL-SHA:ECDH-ECDSA-NULL-SHA:NULL-SHA256:NULL-SHA:NULL-MD5
Salz, Rich
Dec 16, 2014, 10:46:54 AM12/16/14
to
> The boringssl patch was quite invasive, so I gave up to try to port their
> changes.
We're working with the Boring folks to keep closer in sync so maybe something will happen in this area.
> changes.
Hubert Kario
Dec 16, 2014, 11:13:32 AM12/16/14
to
On Tuesday 16 December 2014 16:18:09 Hanno Böck wrote:
> On Tue, 16 Dec 2014 15:42:43 +0100
>
> Hubert Kario <hka...@redhat.com> wrote:
> > Last time we have discussed it[1], the only voices against were about
> > removal of RC4 ciphers from default
>
> On Tue, 16 Dec 2014 15:42:43 +0100
>
> Hubert Kario <hka...@redhat.com> wrote:
> > Last time we have discussed it[1], the only voices against were about
> > removal of RC4 ciphers from default
>
> The boringssl patch was quite invasive, so I gave up to try to port
> their changes.
>
> their changes.
>
> But in essence it's quite trivial, just re-order stuff a bit. See
> attached patch.
>
>
> Output after my patch of ALL:COMPLEMENTOFALL:
<snip>> attached patch.
>
>
> Output after my patch of ALL:COMPLEMENTOFALL:
> To compare, output of plain openssl:
they don't differ...
but comparing that to what Fedora version of openssl outputs, then new order
certainly makes things a bit better.
there are few issues still
- aRSA preferred before aECDSA
- AES256 before AES128 in general
- few export grade ciphers placed before secure ciphers
- 3DES is placed arbitrarily
I'd prefer not only change the order, but also say what was the intent and
what is the preferred ordering (which keys are used for ordering), so that
when new ciphers come, it will be more or less obvious where they should be
placed
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Hanno Böck
Dec 16, 2014, 12:20:22 PM12/16/14
to
On Tue, 16 Dec 2014 17:11:34 +0100
Hubert Kario <hka...@redhat.com> wrote:
> they don't differ...
oh sorry, must've pasted the wrong string.
But please ignore my first patch, I don't think this is optimal. I'll
do another one later.
What I think is a sane approach is to leave the current code mostly as
it is, just add one further sorting step that will bring GCM ciphers in
front of non-gcm ones.
I think that should give the desired result.
Hubert Kario <hka...@redhat.com> wrote:
> they don't differ...
oh sorry, must've pasted the wrong string.
But please ignore my first patch, I don't think this is optimal. I'll
do another one later.
What I think is a sane approach is to leave the current code mostly as
it is, just add one further sorting step that will bring GCM ciphers in
front of non-gcm ones.
I think that should give the desired result.
Viktor Dukhovni
Dec 16, 2014, 12:22:18 PM12/16/14
to
On Tue, Dec 16, 2014 at 05:11:34PM +0100, Hubert Kario wrote:
> there are few issues still
> - aRSA preferred before aECDSA
> - AES256 before AES128 in general
> - few export grade ciphers placed before secure ciphers
> - 3DES is placed arbitrarily
>
> I'd prefer not only change the order, but also say what was the intent and
> what is the preferred ordering (which keys are used for ordering), so that
> when new ciphers come, it will be more or less obvious where they should be
> placed
In particular there MUST NOT be any fragile hand-tuning. All
> there are few issues still
> - aRSA preferred before aECDSA
> - AES256 before AES128 in general
> - few export grade ciphers placed before secure ciphers
> - 3DES is placed arbitrarily
>
> I'd prefer not only change the order, but also say what was the intent and
> what is the preferred ordering (which keys are used for ordering), so that
> when new ciphers come, it will be more or less obvious where they should be
> placed
ordering needs to be based on general principles.
One might for example say that any CBC cipher at 128+ bits gets a
baseline sorting strength of 128 bits. One might then apply either
"@STRENGTH" or "@SPEED" (new), the first of which adds "1" to any
CBC cipher whose key is longer than 128-bits, the second to those
that are equal to "128" bits.
With AES AEAD the baseline could be "129", with similar "STRENGTH"
vs. "SPEED" boosts. Which would ensure that AEAD@128 beats CBC@256.
However, where do we fit ChaCha20/Poly-1305? Again, not hand-placement,
but some extensible algorithm.
--
Viktor.
Hubert Kario
Dec 16, 2014, 12:24:10 PM12/16/14
to
On Tuesday 16 December 2014 18:15:19 Hanno Böck wrote:
> On Tue, 16 Dec 2014 17:11:34 +0100
>
> Hubert Kario <hka...@redhat.com> wrote:
> > they don't differ...
>
> oh sorry, must've pasted the wrong string.
>
> But please ignore my first patch, I don't think this is optimal. I'll
> do another one later.
>
> What I think is a sane approach is to leave the current code mostly as
> it is, just add one further sorting step that will bring GCM ciphers in
> front of non-gcm ones.
> I think that should give the desired result.
> On Tue, 16 Dec 2014 17:11:34 +0100
>
> Hubert Kario <hka...@redhat.com> wrote:
> > they don't differ...
>
> oh sorry, must've pasted the wrong string.
>
> But please ignore my first patch, I don't think this is optimal. I'll
> do another one later.
>
> What I think is a sane approach is to leave the current code mostly as
> it is, just add one further sorting step that will bring GCM ciphers in
> front of non-gcm ones.
> I think that should give the desired result.
to this specific issue, yes, but in general fixing ordering also with relation
to PFS is a good idea
--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
Salz, Rich
Dec 16, 2014, 12:28:11 PM12/16/14
to
> In particular there MUST NOT be any fragile hand-tuning. All ordering needs
> to be based on general principles.
This is not a universally-held view.
> to be based on general principles.
--
Principal Security Engineer, Akamai Technologies
IM: rs...@jabber.me Twitter: RichSalz
Hanno Böck
Dec 16, 2014, 12:30:25 PM12/16/14
to
On Tue, 16 Dec 2014 17:17:01 +0000
Viktor Dukhovni <openss...@dukhovni.org> wrote:
> However, where do we fit ChaCha20/Poly-1305? Again, not
> hand-placement, but some extensible algorithm.
How about this simpler criterion:
Viktor Dukhovni <openss...@dukhovni.org> wrote:
> However, where do we fit ChaCha20/Poly-1305? Again, not
> hand-placement, but some extensible algorithm.
AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
it.
(this doesn't answer whether chacha20-poly1305 or aes-gcm should be
considered "better", but I don't know if there is a clear consensus on
that)
Viktor Dukhovni
Dec 16, 2014, 12:41:19 PM12/16/14
to
On Tue, Dec 16, 2014 at 06:28:03PM +0100, Hanno B?ck wrote:
> > However, where do we fit ChaCha20/Poly-1305? Again, not
> > hand-placement, but some extensible algorithm.
>
> How about this simpler criterion:
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
That does not solve the problem of some folks wanting speed
> > However, where do we fit ChaCha20/Poly-1305? Again, not
> > hand-placement, but some extensible algorithm.
>
> How about this simpler criterion:
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
(preferring AES128 over AES256), and others safety (converse).
> (this doesn't answer whether chacha20-poly1305 or aes-gcm should be
> considered "better", but I don't know if there is a clear consensus on
> that)
consistently (DEFAULT Is subset of ALL in the same relative order),
so this question needs a default answer, if someone wants to tune
that by hand, the rope is there...
--
Viktor.
Viktor Dukhovni
Dec 16, 2014, 12:48:24 PM12/16/14
to
On Tue, Dec 16, 2014 at 06:15:19PM +0100, Hanno B?ck wrote:
> On Tue, 16 Dec 2014 17:11:34 +0100
> Hubert Kario <hka...@redhat.com> wrote:
>
> > they don't differ...
>
> oh sorry, must've pasted the wrong string.
>
> But please ignore my first patch, I don't think this is optimal. I'll
> do another one later.
>
> What I think is a sane approach is to leave the current code mostly as
> it is, just add one further sorting step that will bring GCM ciphers in
> front of non-gcm ones.
> I think that should give the desired result.
We don't need such a "sorting step". If you want "@STRENGTH" to
> On Tue, 16 Dec 2014 17:11:34 +0100
> Hubert Kario <hka...@redhat.com> wrote:
>
> > they don't differ...
>
> oh sorry, must've pasted the wrong string.
>
> But please ignore my first patch, I don't think this is optimal. I'll
> do another one later.
>
> What I think is a sane approach is to leave the current code mostly as
> it is, just add one further sorting step that will bring GCM ciphers in
> front of non-gcm ones.
> I think that should give the desired result.
put AEAD first, then adjust the strength ratings.
We could define a few functions of (algorithm, keylength, mode)
that return an effective strength. Some new keywords would choose
an alternative effective strength function. There should be one
(stable) sorting pass, and no after-the-fact reordering.
Nico Williams
Dec 16, 2014, 12:59:33 PM12/16/14
to
On Tue, Dec 16, 2014 at 12:26:32PM -0500, Salz, Rich wrote:
> > In particular there MUST NOT be any fragile hand-tuning. All ordering needs
> > to be based on general principles.
>
> This is not a universally-held view.
I think the key word is "fragile", not "hand-tuning".
> > In particular there MUST NOT be any fragile hand-tuning. All ordering needs
> > to be based on general principles.
>
> This is not a universally-held view.
Subtracting (in local configuration) algorithms from a keyword denoting
all known-strong algorithms is hand-tuning, but not fragile hand-tuning.
Nico
--
Salz, Rich
Dec 16, 2014, 1:06:27 PM12/16/14
to
> Subtracting (in local configuration) algorithms from a keyword denoting all
> known-strong algorithms is hand-tuning, but not fragile hand-tuning.
Three years ago RC4 was known-strong. Two years ago DES-CBC was known-strong. Now we only have AES-GCM. At what point do we think ChaCha/Poly is known-strong, and who gets to make that call? Dan? Adam?
> known-strong algorithms is hand-tuning, but not fragile hand-tuning.
Who said "these are known-strong" and when did they say it, and are they still correct? And where and how does a system admin find those things out.
Nico Williams
Dec 16, 2014, 1:08:26 PM12/16/14
to
On Tue, Dec 16, 2014 at 05:17:01PM +0000, Viktor Dukhovni wrote:
> In particular there MUST NOT be any fragile hand-tuning. All
> ordering needs to be based on general principles.
+1.
> In particular there MUST NOT be any fragile hand-tuning. All
> ordering needs to be based on general principles.
> One might for example say that any CBC cipher at 128+ bits gets a
> baseline sorting strength of 128 bits. One might then apply either
> "@STRENGTH" or "@SPEED" (new), the first of which adds "1" to any
> CBC cipher whose key is longer than 128-bits, the second to those
> that are equal to "128" bits.
>
> With AES AEAD the baseline could be "129", with similar "STRENGTH"
> vs. "SPEED" boosts. Which would ensure that AEAD@128 beats CBC@256.
>
> However, where do we fit ChaCha20/Poly-1305? Again, not hand-placement,
> but some extensible algorithm.
Any algorithm numeric strength assignments should be baked into the
> but some extensible algorithm.
library, or perhaps configurable in a configuration file. The should
not be known to applications. Ditto for any computaiton of overall
strength of cipher-mode combinations.
Internally using such numeric strength assignments is fine.
In particular I want you to avoid the problem that Cyrus SASL had (and
still has) with the "security strength factor (SSF)", where entire
security mechanisms get boiled down to a single numeric strength factor
even though a mechanism might negotiate cryptographic algorithms, and
where applications end up hardcoding SSF values for things like Kerberos
V5 (which has "SSF" of 56, because initially Kerberos V5 only supported
1DES). This is a horrible problem to have.
Nico
--
Nico Williams
Dec 16, 2014, 1:25:37 PM12/16/14
to
On Tue, Dec 16, 2014 at 01:04:17PM -0500, Salz, Rich wrote:
> > Subtracting (in local configuration) algorithms from a keyword denoting all
> > known-strong algorithms is hand-tuning, but not fragile hand-tuning.
>
> Three years ago RC4 was known-strong. Two years ago DES-CBC was
> known-strong. Now we only have AES-GCM. At what point do we think
> ChaCha/Poly is known-strong, and who gets to make that call? Dan?
> Adam?
Changing the internal relative strength weighings of these requires
> > Subtracting (in local configuration) algorithms from a keyword denoting all
> > known-strong algorithms is hand-tuning, but not fragile hand-tuning.
>
> Three years ago RC4 was known-strong. Two years ago DES-CBC was
> known-strong. Now we only have AES-GCM. At what point do we think
> ChaCha/Poly is known-strong, and who gets to make that call? Dan?
> Adam?
pushing out new code. Something that... happens all the time.
I'm not against local configuration of these things as, say, a temporary
override while waiting for patches. The configuration needs to be
simple and not fragile.
Subtracting from named sets of algorithms and sorting by desired
attributes (speed, strength), is a non-fragile way to specify
administrative preferences.
Assiging numeric algorithm strength in a config file is fragile but
acceptable for emergencies.
> Who said "these are known-strong" and when did they say it, and are
> they still correct? And where and how does a system admin find those
> things out.
strength assessments to _applications_: once those are baked in in the
application they can't be changed.
I realize that there was no proposal to do so. However, any time
numeric algorithm strength assessments are discussed is also a good time
to warn others to avoid the SASL SSF mistake.
Viktor Dukhovni
Dec 16, 2014, 1:28:41 PM12/16/14
to
On Tue, Dec 16, 2014 at 11:55:37AM -0600, Nico Williams wrote:
> Internally using such numeric strength assignments is fine.
>
> In particular I want you to avoid the problem that Cyrus SASL had (and
> still has) with the "security strength factor (SSF)", where entire
> security mechanisms get boiled down to a single numeric strength factor
> even though a mechanism might negotiate cryptographic algorithms, and
> where applications end up hardcoding SSF values for things like Kerberos
> V5 (which has "SSF" of 56, because initially Kerberos V5 only supported
> 1DES). This is a horrible problem to have.
Internally OpenSSL has a multi-dimensional property matrix, and
> Internally using such numeric strength assignments is fine.
>
> In particular I want you to avoid the problem that Cyrus SASL had (and
> still has) with the "security strength factor (SSF)", where entire
> security mechanisms get boiled down to a single numeric strength factor
> even though a mechanism might negotiate cryptographic algorithms, and
> where applications end up hardcoding SSF values for things like Kerberos
> V5 (which has "SSF" of 56, because initially Kerberos V5 only supported
> 1DES). This is a horrible problem to have.
preferences between numerically equal ciphers are based on other
properties. The (stable) numeric sorting just re-arranges blocks
of ciphers already sorted by other means. Thus preference for PFS
already puts kEECDH and kDHE ahead of kRSA for otherwise equally
strong ciphers.
When the user choose a group of ciphers to add to a cipherlist,
the members of the group retain their relative order. However,
there are interesting games that can be played with:
aRSA:-kRSA:ALL:@STRENGTH
(prefers kRSA over PFS).
which perturb the order, because the most recenly removed elements
end up at the top of the list when "ALL" is added. So the relative
preferences of various properties can be changed.
The SASL problem mostly does not bite OpenSSL, However, @STRENGTH
(which is often needed) is not sufficiently tunable, it is not eas
to prefer AES-128 with AEAD over 256 with CBC. For that we need
some new mappings that produce slight different "effective" stengths.
--
Viktor.
Nico Williams
Dec 16, 2014, 1:45:09 PM12/16/14
to
On Tue, Dec 16, 2014 at 06:26:50PM +0000, Viktor Dukhovni wrote:
> Internally OpenSSL has a multi-dimensional property matrix, and
> preferences between numerically equal ciphers are based on other
> properties. The (stable) numeric sorting just re-arranges blocks
> of ciphers already sorted by other means. Thus preference for PFS
> already puts kEECDH and kDHE ahead of kRSA for otherwise equally
> strong ciphers.
>
> When the user choose a group of ciphers to add to a cipherlist,
> the members of the group retain their relative order. However,
> there are interesting games that can be played with:
>
> aRSA:-kRSA:ALL:@STRENGTH
>
> (prefers kRSA over PFS).
>
> which perturb the order, because the most recenly removed elements
> end up at the top of the list when "ALL" is added. So the relative
> preferences of various properties can be changed.
Iterating subtaction and addition seems like a fragile way to indicate
> Internally OpenSSL has a multi-dimensional property matrix, and
> preferences between numerically equal ciphers are based on other
> properties. The (stable) numeric sorting just re-arranges blocks
> of ciphers already sorted by other means. Thus preference for PFS
> already puts kEECDH and kDHE ahead of kRSA for otherwise equally
> strong ciphers.
>
> When the user choose a group of ciphers to add to a cipherlist,
> the members of the group retain their relative order. However,
> there are interesting games that can be played with:
>
> aRSA:-kRSA:ALL:@STRENGTH
>
> (prefers kRSA over PFS).
>
> which perturb the order, because the most recenly removed elements
> end up at the top of the list when "ALL" is added. So the relative
> preferences of various properties can be changed.
preference.
> The SASL problem mostly does not bite OpenSSL, However, @STRENGTH
> (which is often needed) is not sufficiently tunable, it is not eas
> to prefer AES-128 with AEAD over 256 with CBC. For that we need
> some new mappings that produce slight different "effective" stengths.
then specify order of preference via some method other than iteratively
adding and subtracting algorithms. Something like:
DEFAULT:-FOO128:::PFS,AEAD,speed,strength
(Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed,
strength.)
Preferences should affect the order in which cipher suites are
advertised/picked, not which ones are advertised.
Algorithms that are not desired should not be advertised/used.
Nico
--
Viktor Dukhovni
Dec 16, 2014, 1:58:04 PM12/16/14
to
On Tue, Dec 16, 2014 at 12:43:13PM -0600, Nico Williams wrote:
> My preference would be: subtract undesired algorithms from a named set,
> then specify order of preference via some method other than iteratively
> adding and subtracting algorithms. Something like:
>
> DEFAULT:-FOO128:::PFS,AEAD,speed,strength
>
> (Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed,
> strength.)
I agree that iterative add/subtract reording is not for most mortals,
> My preference would be: subtract undesired algorithms from a named set,
> then specify order of preference via some method other than iteratively
> adding and subtracting algorithms. Something like:
>
> DEFAULT:-FOO128:::PFS,AEAD,speed,strength
>
> (Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed,
> strength.)
however, the above is worse. Absolute preference for PFS regardless
of key length seems unwise. Do you *really* want:
ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1
ahead of a non-PFS AES-256? The effective strength MUST come first,
but there need to be a few ways to squash "strong-enough" 128/256
ciphers so that other factors can dominate.
One way to do that is to set an upper-bound on the effective bit
length "MAXEFECTIVE=128", so that nothing is considered stronger
than 128, and then other factors come into play. Thus @SPEED would
sort fastest first which combined with an "@STENGTH" capped at 128,
gives a sensible outcome for those wanting an adequate, but performant
128-bit outcome, with AEAD first, ...
And the browsers should implement SHA-384, and why the hell are we
using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
the SHA256 HMAC construction has adequate strength in this context?
--
Viktor.
Kurt Roeckx
Dec 16, 2014, 2:39:22 PM12/16/14
to
On Tue, Dec 16, 2014 at 12:23:36PM -0600, Nico Williams wrote:
> On Tue, Dec 16, 2014 at 01:04:17PM -0500, Salz, Rich wrote:
> > > Subtracting (in local configuration) algorithms from a keyword denoting all
> > > known-strong algorithms is hand-tuning, but not fragile hand-tuning.
> >
> > Three years ago RC4 was known-strong. Two years ago DES-CBC was
> > known-strong. Now we only have AES-GCM. At what point do we think
> > ChaCha/Poly is known-strong, and who gets to make that call? Dan?
> > Adam?
>
> Changing the internal relative strength weighings of these requires
> pushing out new code. Something that... happens all the time.
It's not because we make a release that everybody is going to
> On Tue, Dec 16, 2014 at 01:04:17PM -0500, Salz, Rich wrote:
> > > Subtracting (in local configuration) algorithms from a keyword denoting all
> > > known-strong algorithms is hand-tuning, but not fragile hand-tuning.
> >
> > Three years ago RC4 was known-strong. Two years ago DES-CBC was
> > known-strong. Now we only have AES-GCM. At what point do we think
> > ChaCha/Poly is known-strong, and who gets to make that call? Dan?
> > Adam?
>
> Changing the internal relative strength weighings of these requires
> pushing out new code. Something that... happens all the time.
switch to it. Some people are still using 0.9.7.
Kurt
Kurt Roeckx
Dec 16, 2014, 2:48:11 PM12/16/14
to
On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> And the browsers should implement SHA-384, and why the hell are we
> using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> the SHA256 HMAC construction has adequate strength in this context?
With GCM the collision resistance is important and SHA-256
> And the browsers should implement SHA-384, and why the hell are we
> using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> the SHA256 HMAC construction has adequate strength in this context?
only provides an 128 bit strength for that.
Yoav Nir
Dec 16, 2014, 2:56:04 PM12/16/14
to
> On Dec 16, 2014, at 7:28 PM, Hanno Böck <ha...@hboeck.de> wrote:
>
> On Tue, 16 Dec 2014 17:17:01 +0000
> Viktor Dukhovni <openss...@dukhovni.org> wrote:
>
>> However, where do we fit ChaCha20/Poly-1305? Again, not
>> hand-placement, but some extensible algorithm.
>
>> hand-placement, but some extensible algorithm.
>
> How about this simpler criterion:
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
>
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
>
> (this doesn't answer whether chacha20-poly1305 or aes-gcm should be
> considered "better", but I don't know if there is a clear consensus on
> that)
> considered "better", but I don't know if there is a clear consensus on
> that)
Agree about AEAD before non-AEAD. As for ChaCha20 vs AES-GCM, as long as we don’t have evidence that on is significantly weaker than the other, I don’t think preferences should depend on security arguments, but on performance. Unfortunately , this is difficult to determine, because AES-GCM is faster on modern Intel processors, but slower on older processors and on ARM. It really depends on the application which is preferable.
If we don’t want preference to be user-determined, I guess AES-GCM is more likely to be the preferred cipher for most servers.
Yoav
Viktor Dukhovni
Dec 16, 2014, 2:58:53 PM12/16/14
to
On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
> On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> > And the browsers should implement SHA-384, and why the hell are we
> > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> > the SHA256 HMAC construction has adequate strength in this context?
>
> With GCM the collision resistance is important and SHA-256
> only provides an 128 bit strength for that.
I've not looked into this, can you elaborate (citation)? Which
> On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> > And the browsers should implement SHA-384, and why the hell are we
> > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> > the SHA256 HMAC construction has adequate strength in this context?
>
> With GCM the collision resistance is important and SHA-256
> only provides an 128 bit strength for that.
attacker controls the SHA2-256 inputs to the TLS PRF? Why are
collisions rather than 2nd preimages the relevant issue?
Though of course with AEAD the PRF is not used for a bulk data
checksum, so its performance is largely irrelevant.
Why aren't the browsers implementing the AESGCM256 + SHA384 variants?
--
Viktor.
Hubert Kario
Dec 16, 2014, 3:52:54 PM12/16/14
to
On Tuesday 16 December 2014 12:43:13 Nico Williams wrote:
> On Tue, Dec 16, 2014 at 06:26:50PM +0000, Viktor Dukhovni wrote:
> > Internally OpenSSL has a multi-dimensional property matrix, and
> > preferences between numerically equal ciphers are based on other
> > properties. The (stable) numeric sorting just re-arranges blocks
> > of ciphers already sorted by other means. Thus preference for PFS
> > already puts kEECDH and kDHE ahead of kRSA for otherwise equally
> > strong ciphers.
> >
> > When the user choose a group of ciphers to add to a cipherlist,
> > the members of the group retain their relative order. However,
> >
> > there are interesting games that can be played with:
> > aRSA:-kRSA:ALL:@STRENGTH
> >
> > (prefers kRSA over PFS).
> >
> > which perturb the order, because the most recenly removed elements
> > end up at the top of the list when "ALL" is added. So the relative
> > preferences of various properties can be changed.
>
> Iterating subtaction and addition seems like a fragile way to indicate
> preference.
>
> > The SASL problem mostly does not bite OpenSSL, However, @STRENGTH
> > (which is often needed) is not sufficiently tunable, it is not eas
> > to prefer AES-128 with AEAD over 256 with CBC. For that we need
> > some new mappings that produce slight different "effective" stengths.
>
> On Tue, Dec 16, 2014 at 06:26:50PM +0000, Viktor Dukhovni wrote:
> > Internally OpenSSL has a multi-dimensional property matrix, and
> > preferences between numerically equal ciphers are based on other
> > properties. The (stable) numeric sorting just re-arranges blocks
> > of ciphers already sorted by other means. Thus preference for PFS
> > already puts kEECDH and kDHE ahead of kRSA for otherwise equally
> > strong ciphers.
> >
> > When the user choose a group of ciphers to add to a cipherlist,
> > the members of the group retain their relative order. However,
> >
> > there are interesting games that can be played with:
> > aRSA:-kRSA:ALL:@STRENGTH
> >
> > (prefers kRSA over PFS).
> >
> > which perturb the order, because the most recenly removed elements
> > end up at the top of the list when "ALL" is added. So the relative
> > preferences of various properties can be changed.
>
> Iterating subtaction and addition seems like a fragile way to indicate
> preference.
>
> > The SASL problem mostly does not bite OpenSSL, However, @STRENGTH
> > (which is often needed) is not sufficiently tunable, it is not eas
> > to prefer AES-128 with AEAD over 256 with CBC. For that we need
> > some new mappings that produce slight different "effective" stengths.
>
> My preference would be: subtract undesired algorithms from a named set,
> then specify order of preference via some method other than iteratively
> adding and subtracting algorithms. Something like:
>
> DEFAULT:-FOO128:::PFS,AEAD,speed,strength
>
The more I think about it, the more I like it.
> then specify order of preference via some method other than iteratively
> adding and subtracting algorithms. Something like:
>
> DEFAULT:-FOO128:::PFS,AEAD,speed,strength
>
BTW: the way the sorting is currently implemented, it would just be a question
of defining (in addition to currently present @STRENGTH) @PFS, @AEAD, @SPEED
sorting orders (maybe also @STRENGTH128 which explicitly assumes any effective
key size above 128 is 128).
That's because if there's one thing I don't like about my proposal from few
months back, is that we essentially have to define one "true" order of
importance, say which is more important: speed, pfs or AEAD.
Let's say, for the sake of argument, that CBC mode is significantly broken,
even in EtM mode (that's another can of worms[1]), then many people will want
to prioritise *non-PFS* versions of AEAD ciphers above any other ciphers. And
they will want to do it for the same reason people currently leave RC4 in.
1 - by another can of worms I mean: what if it's broken only in MtE mode? how
to specify different ciphers depending on presence of this extension, so that
in MtE only AEAD ciphers are available while if EtM is on, the list gains CBC
ciphers? This is similar to the problem with BEAST: ordering with RC4 at the
front for TLS1.0 is sort-of OK, not so much for TLSv1.1 and later...
--
Regards,
Hubert Kario
Nico Williams
Dec 16, 2014, 4:00:37 PM12/16/14
to
On Tue, Dec 16, 2014 at 09:50:32PM +0100, Hubert Kario wrote:
> > My preference would be: subtract undesired algorithms from a named set,
> > then specify order of preference via some method other than iteratively
> > adding and subtracting algorithms. Something like:
> >
> > DEFAULT:-FOO128:::PFS,AEAD,speed,strength
I would add that this would work like one would expect, and that
> > My preference would be: subtract undesired algorithms from a named set,
> > then specify order of preference via some method other than iteratively
> > adding and subtracting algorithms. Something like:
> >
> > DEFAULT:-FOO128:::PFS,AEAD,speed,strength
speed,strength would give [potentially] different results than
strength,speed, as one would expect.
> Let's say, for the sake of argument, that CBC mode is significantly broken,
> even in EtM mode (that's another can of worms[1]), then many people will want
> to prioritise *non-PFS* versions of AEAD ciphers above any other ciphers. And
> they will want to do it for the same reason people currently leave RC4 in.
ciphersuite), but the weak crypto has to go last. Of course, for
one-offs like this hypothetical one might want a way to indicate that
some algorithms are least preferred and others most, not just sets of
algorithms.
> 1 - by another can of worms I mean: what if it's broken only in MtE
> mode? how to specify different ciphers depending on presence of this
> extension, so that in MtE only AEAD ciphers are available while if
> EtM is on, the list gains CBC ciphers? This is similar to the problem
> with BEAST: ordering with RC4 at the front for TLS1.0 is sort-of OK,
> not so much for TLSv1.1 and later...
would help. Specifying in more context-dependent ways would be nice
but now you'd need a way to name/identify the context.
Nico
--
mancha
Dec 16, 2014, 4:02:54 PM12/16/14
to
On Tue, Dec 16, 2014 at 06:28:03PM +0100, Hanno Böck wrote:
> On Tue, 16 Dec 2014 17:17:01 +0000
> Viktor Dukhovni <openss...@dukhovni.org> wrote:
>
> > However, where do we fit ChaCha20/Poly-1305? Again, not
> > hand-placement, but some extensible algorithm.
>
> How about this simpler criterion:
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
Has there been significant cryptanalysis done on ChaCha20-Poly1305? My
> On Tue, 16 Dec 2014 17:17:01 +0000
> Viktor Dukhovni <openss...@dukhovni.org> wrote:
>
> > However, where do we fit ChaCha20/Poly-1305? Again, not
> > hand-placement, but some extensible algorithm.
>
> How about this simpler criterion:
> AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with
> it.
quick scan reveals a dearth of peer-reviewed literature.
--mancha
Salz, Rich
Dec 16, 2014, 4:45:03 PM12/16/14
to
There's clearly only one solution: I'll implement a DWIM keyword in OpenSSL 1.1 Maybe @BEST sorting order.
It's hard. You aren't doing people a service by attempting magic.
It's hard. You aren't doing people a service by attempting magic.
Kurt Roeckx
Dec 16, 2014, 4:50:15 PM12/16/14
to
On Tue, Dec 16, 2014 at 07:57:08PM +0000, Viktor Dukhovni wrote:
> On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
>
> > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> > > And the browsers should implement SHA-384, and why the hell are we
> > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> > > the SHA256 HMAC construction has adequate strength in this context?
> >
> > With GCM the collision resistance is important and SHA-256
> > only provides an 128 bit strength for that.
>
> I've not looked into this, can you elaborate (citation)? Which
> attacker controls the SHA2-256 inputs to the TLS PRF? Why are
> collisions rather than 2nd preimages the relevant issue?
I think the best reference I can find at this time is:
> On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
>
> > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> > > And the browsers should implement SHA-384, and why the hell are we
> > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> > > the SHA256 HMAC construction has adequate strength in this context?
> >
> > With GCM the collision resistance is important and SHA-256
> > only provides an 128 bit strength for that.
>
> I've not looked into this, can you elaborate (citation)? Which
> attacker controls the SHA2-256 inputs to the TLS PRF? Why are
> collisions rather than 2nd preimages the relevant issue?
http://www.ietf.org/mail-archive/web/tls/current/msg13313.html
But I'm sure I can find others if needed.
Kurt
Viktor Dukhovni
Dec 16, 2014, 5:00:10 PM12/16/14
to
On Tue, Dec 16, 2014 at 10:48:08PM +0100, Kurt Roeckx wrote:
> On Tue, Dec 16, 2014 at 07:57:08PM +0000, Viktor Dukhovni wrote:
> > On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
> >
> > > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> > > > And the browsers should implement SHA-384, and why the hell are we
> > > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> > > > the SHA256 HMAC construction has adequate strength in this context?
> > >
> > > With GCM the collision resistance is important and SHA-256
> > > only provides an 128 bit strength for that.
> >
> > I've not looked into this, can you elaborate (citation)? Which
> > attacker controls the SHA2-256 inputs to the TLS PRF? Why are
> > collisions rather than 2nd preimages the relevant issue?
>
> I think the best reference I can find at this time is:
> http://www.ietf.org/mail-archive/web/tls/current/msg13313.html
>
> But I'm sure I can find others if needed.
I believe the author of that message is mistaken.
> On Tue, Dec 16, 2014 at 07:57:08PM +0000, Viktor Dukhovni wrote:
> > On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote:
> >
> > > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote:
> > > > And the browsers should implement SHA-384, and why the hell are we
> > > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely
> > > > the SHA256 HMAC construction has adequate strength in this context?
> > >
> > > With GCM the collision resistance is important and SHA-256
> > > only provides an 128 bit strength for that.
> >
> > I've not looked into this, can you elaborate (citation)? Which
> > attacker controls the SHA2-256 inputs to the TLS PRF? Why are
> > collisions rather than 2nd preimages the relevant issue?
>
> I think the best reference I can find at this time is:
> http://www.ietf.org/mail-archive/web/tls/current/msg13313.html
>
> But I'm sure I can find others if needed.
--
Viktor.
0 new messages