Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71731
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.170 as permitted sender)
MIME-Version: 1.0
Date: Wed, 29 Jan 2014 11:01:15 -0500
Message-ID: <CAH8Mpnn6KjShXruxYrmhAfSnTT0HZX_Ye-L3fih9Bx25eRfBig@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>, padraic.brady@gmail.com
Content-Type: multipart/alternative; boundary=20cf30223c91f6140004f11e0c5e
Subject: Re: Improved TLS Defaults
From: rdlowrey@gmail.com (Daniel Lowrey)

--20cf30223c91f6140004f11e0c5e
Content-Type: text/plain; charset=ISO-8859-1

> The Mozilla defaults are geared towards achieving perfect forward security
> where possible ...
> The RFC, at a minimum, seems a positive change.

Great! This is the goal.

The settings proposed in the RFC are geared towards disallowing anything
that's unabashedly insecure while still maintaining the broadest possible
support by default (to minimize BC implications). I realize that Padraic
isn't suggesting this but I want to state for the record that I don't
believe it makes sense at this time to try to enforce perfect forward
security as a language-level default. However, it *is* important to move
away from the existing naive default and that's what the RFC proposes.

The nice thing here is that the default cipher setting is *exceedingly*
simple to modify in response to future threats or attack vectors; all we'd
need to do to respond to new information going forward is to modify a
single string.

--20cf30223c91f6140004f11e0c5e--