Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71713
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZbEOtBq1hA4mqgo6bpMYXm3CLNMptMTZHNo67XF2tmQA@mail.gmail.com>
References: <CAH8MpnngUXdq5=7F2p64hRoogp=31E2p5oaJMZVvKLTD1H_qUw@mail.gmail.com>
	<CAGa2bXZbEOtBq1hA4mqgo6bpMYXm3CLNMptMTZHNo67XF2tmQA@mail.gmail.com>
Date: Tue, 28 Jan 2014 23:20:49 -0500
Message-ID: <CAH8MpnnZZV8TeyA5TQeCrPqLdkYj2pE3eJ5qJDMBo84Vg4MaqA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=90e6ba2121f503a98c04f1144452
Subject: Re: [PHP-DEV] [RFC] Improved TLS Defaults
From: rdlowrey@gmail.com (Daniel Lowrey)

--90e6ba2121f503a98c04f1144452
Content-Type: text/plain; charset=ISO-8859-1

> I haven't read the RFC carefully yet, but it's great proposal!

Thanks!


> You probably reviewed this page already.
> https://wiki.mozilla.org/Security/Server_Side_TLS
>

Yes I have! The cipher list proposed in the RFC was gathered from disparate
research sources that did not include the Mozilla site. However you'll see
that the excluded ciphers in the RFC actually match up directly with those
in Mozilla's "Mandatory discards" section.

Is your recommendation from OpenSSL project or else?
> I couldn't find a page with quick search.
>

This is not surprising: the OpenSSL documentation is fairly outdated in
most areas. However, I've made an effort to provide references for my
reasoning with regard to the individual ciphers listed in the RFC. In
response to your question, I've added more links (including references to
the relevant Mozilla project page) and updated some of the relevant
information in the RFC text. These changes are marked in the revision
history at the top of the wiki page and I've incremented the RFC's version
number from v0.1 to v0.2 to reflect the updates.

@STRENGTH orders cipher as mozilla recommend? It seems this option is for
> this and/or similar purpose.
>

The @STRENGTH element simply allows us to prefer algorithms with longer key
lengths (e.g.256-bit ciphers preferred to 168-bit preferred to 128-bit).
Because TLS clients will negotiate the cipher according to their preference
order it's sensible to add this annotation. The exception to this rule is
when a server specifies the "Honor Cipher Order" option (also proposed for
addition as part of the RFC). For these cases the @STRENGTH specification
still applies because as servers we still should prefer stronger ciphers by
default.

--90e6ba2121f503a98c04f1144452--